TGGET Niche Research vs Scholar Feed MCP | AllMCPs
TGGET Niche Research vs Scholar Feed MCP
A side-by-side look at the TGGET Niche Research and Scholar Feed MCP MCP servers: transport, auth, tools, quality signals, and the config to install either one in Claude, Cursor, Windsurf or VS Code.
Verdict: choose TGGET Niche Research for research work; choose Scholar Feed MCP for research as a local process. You can also run both side by side in one mcpServers block.
Which MCP server should you choose?
T
Choose TGGET Niche Research when
You need dedicated capabilities in the Research domain.
Its auth model fits you: API key required.
You have the keys it needs: TGGET_TOKEN.
You want tools like start_research, get_research, get_report.
start_researchStarts a niche research from a short search phrase or a plain-language description of an app or service idea. A phrase is scanned directly (demand, sub-topics, competitors, signals); a description is first turned into real search queries, the best one is then scanned automatically. Demand is measured in one country and one language: `country` and `language` when given, otherwise the country and the language of the phrase (English: United States, Spanish: Spain, Portuguese: Brazil); write the phrase in the language people search in there. `country` and `language` of the answer tell how the numbers were measured. Returns the research id to poll with get_research. Counts as one research of the plan allowance, whether the data comes from the sources or from the shared cache.
get_researchReturns the current state and findings of a research by id: status, `country` and `language` the demand was measured in (null where a source does not measure by country), headline numbers, ranked candidate phrases, competitor overview, child researches (sub-topics, competitor checks, signals) with their ids, and skipped stages. Call repeatedly until status is completed and pending is 0.
get_reportReturns the final niche report of a finished scan (or the report research itself) as Markdown: verdict, what product to build (customer pains with evidence and severity, positioning, MVP with the pain each feature relieves, platform, monetization, competitor matrix), napkin economics (price hypothesis, acquisition cost from the cost per click in paid search, revenue per customer, whether it adds up, assumptions), SEO plan for the site (clusters, pages with title/H1/description, content plan, FAQ), ASO for App Store and Google Play, name options with domain and App Store availability, landing page draft, distribution channels by type with a first step, effort and priority, validation steps and risks. Pass format "json" for structured data (keys: verdict, product, economics, seo, aso, names, landing, channels, validation, risks).
list_researchLists the researches the account started itself, newest first: niche scans of a phrase and descriptions of an idea, without the checks they spawned. Use it to find the id of an earlier research before get_research, get_report, compare_research or follow_niche, or to see what is still running. Each item has `id`, `kind`, `phrase`, `status` (queued, running, completed, failed), `mode`, `country` and `language` the demand was measured in, `created_at`, `url` of its page and `total_count`: monthly searches of the phrase, null for a description. `quota` tells how many researches the plan has left. Reads only; spends nothing.
run_signalAdds one check to a finished research and returns the id of the new child research. Use it when the scan skipped a stage, when a person asks about one phrase in particular, or to rebuild the report after new checks. A niche scan already runs the usual checks by itself, so this tool is for what is missing. Checks added this way are free: they do not spend researches of the plan.
Checks of a demand research (`kind`):
- `competitors`: who holds the search results for a phrase of the research; pass the phrase in `phrase`.
- `dynamics`: two years of demand history.
- `appstore`: App Store apps for the phrase with ratings and freshness.
- `wiki`, `radar`, `youtube`: public interest and community signals.
- `paid`: paid search for the phrase and its strongest candidates: volume, advertiser competition, cost per click.
- `insight`: a summary of the findings written by the language model.
- `report`: the final niche report, written anew from the current data; needs a finished niche scan.
Checks of a child research:
- `fingerprint`: product sites found by a competitors check, with pricing and app links; the parent is that competitors check.
- `reviews`: recent App Store reviews of the leaders; the parent is an App Store research.
- `insight` also accepts a competitors check as the parent.
The parent must be completed and belong to the account. The check runs in the background: poll get_research with the returned `id` every 20-30 seconds until `status` is `completed`. `insight` and `report` are rebuilt at most once an hour.
compare_researchPuts two to five finished niche scans side by side to help choose between ideas. `items` are the niches with their numbers, the report's positioning and napkin economics, and `wins`: in how many rows the niche holds the better value. `rows` are the ranked measures (verdict, demand, trend, cost per click, weak search results, competitor sites, App Store apps, fresh community signals) with the value of every niche and `best`, the indexes of the items that hold the better value; `better` says which way is better (max or min), null when the row is shown but not ranked. Every item names the `country` and the `language` its demand was measured in; demand and cost per click are not ranked across different markets, countries or languages (`mixed_markets`). The marks are computed from numbers, not written by a language model. Every scan needs a finished report. `share_url` is a read-only link to this comparison that works without signing in: give it to the person only when they want to share the comparison, it shows the numbers and the conclusions of their researches to whoever holds it.
list_projectsLists the niches the account follows. A followed niche (a project) is scanned anew once a month and compared with its previous check. For each project: status, whether the plan serves it, the date of the next check, the latest numbers (verdict, demand, cost per click, competitor sites, App Store, community signals) and what changed at the latest monthly check, as structured `changes` and as `digest` lines of text. Also returns how many niches the plan follows.
get_projectReturns a followed niche with the history of its checks, newest first: the first measurement (`baseline`) and the monthly checks, each with its numbers, what changed since the previous check and the id of the research it came from. Pass that `research_id` to get_report to read the fresh report of a check. Changes are computed from numbers and lists, not written by a language model.
follow_nicheStarts following the niche of a finished scan that has a report: the scan becomes the first measurement and the niche is scanned anew every month, with a digest of what changed sent to the account. Monthly checks do not spend researches; the plan limits how many niches are followed (FREE 1, Starter 2, Pro 10). Following a niche that is already followed returns its project. The niche is followed in the country and the language its scan was measured in (`country` and `language` of the project), so every monthly check measures the same audience.
update_projectPauses a followed niche (`paused`: no monthly checks, its place in the plan is freed), follows it again (`active`, needs a free place in the plan) or stops following it (`deleted`: the project with its checks and digests is removed for good, the researches stay in the history). Ask the person before deleting.
Scholar Feed MCP tools 27
search_papersSearch Scholar Feed's 600k+ CS/AI/ML paper corpus. Semantic (embedding) search by default, so it finds conceptually related work even when the wording differs. EVERY PARAMETER DOCUMENTS ITS OWN BEHAVIOUR AND COVERAGE LIMITS — read the ones you intend to use; this description covers only what no single parameter can tell you. RETRIEVAL LIMIT: semantic ranking favours recent, stylistically-matched papers and routinely MISSES the old high-citation anchor of a field (H2O for KV eviction, GRIT for unified embedding+generation). To reach a field's canonical work, read the top-5 abstracts for repeated baseline mentions ('we compare against X') and look that name up directly, or call get_foundational_lineage. THREE UNRELATED NOTIONS OF IMPACT, easily confused: proven citations (sort='impactful', min_citations) | a ~90-day forecast percentile that is NULL on older papers and therefore excludes them (sort='trending', impact_min) | GitHub adoption (sort='community', min_stars). YOUR LIBRARY IS MARKED INLINE on authenticated calls: each hit carries is_saved and is_read, and a hit you previously annotated carries note_text — your own earlier verdict. Read note_text INSTEAD of re-deriving a conclusion from the abstract; re-judging a paper you already ruled on is the most common way an agent wastes a research session. is_saved=false is a real measurement; on anonymous calls these keys are absent entirely, so never read a missing is_saved as false. Papers new to you are ranked exactly as before — nothing is demoted for being unseen.
get_paperGet full details for one or more papers by arXiv ID. Pass a single-element array for one paper; pass multiple IDs to batch-fetch up to 50 papers in one call. Pass format='bibtex' to get a .bib citation entry (bibtex is single-paper only; for multi-paper bibtex, call repeatedly). Default returns a lean 13-field shape (arxiv_id, title, authors, year, categories, has_code, github_url, citation_count, venue_name, llm_summary, llm_significance, llm_novelty_score, impact_pct — where impact_pct is the ML-forecast impact percentile 0-100 computed WITHIN the paper's own arXiv-category cohort, so it is a cohort-relative rank rather than an absolute score, and is NULL on older papers outside the recent ~90-day scoring window). Pass verbose=true for the full shape with structured extraction (method_name, contribution_type, task_category, datasets, baselines) and institution_tags. Use fields='arxiv_id,title,abstract' to select an exact subset, or fetch_fulltext with sections='all' for the full paper.
get_citationsGet the citation graph for a paper, sorted by citing-paper rank_score (highest-impact first). 'citing' = outgoing references this paper cites; 'cited_by' = incoming citations from other papers. Default response is a lean 12-field shape per paper — pass verbose=true for the full 28-field shape.
Ready-to-paste client configs
Paste either block (or both) into your client config, e.g. claude_desktop_config.json or ~/.cursor/mcp.json. We only show a config when the install command is confirmed.
TGGET Niche Research
No confirmed install command for TGGET Niche Research yet — follow the setup steps linked from its listing page rather than a guessed package name.
TGGET Niche Research is categorized under Research and uses an install path we have not confirmed yet. Scholar Feed MCP belongs to Research and uses a local stdio subprocess. Pick TGGET Niche Research for research work and Scholar Feed MCP for research.
Copy the mcpServers block from the config section on this page into your client's config (for example claude_desktop_config.json or ~/.cursor/mcp.json), then fully restart the client. TGGET Niche Research has no confirmed install command yet — follow its own setup instructions.
TGGET Niche Research has no declared pricing — check the project's own site. Auth: api key required. Scholar Feed MCP is listed as freemium — a free tier with paid plans. Auth: api key required. If a server needs environment variables such as API keys, define them under the env key in your client's MCP config.
Yes. MCP clients support multiple servers: add tgget-niche-research and ygao2005-scholar-feed-mcp as separate keys in the same mcpServers object, and your assistant will call tools from either one.
On AllMCPs, TGGET Niche Research has a quality signal of 53/100 (Good) with 0 views, 0 installs and 0 GitHub stars. Scholar Feed MCP has 61/100 (Good) with 2 views, 0 installs and 12 GitHub stars.
fetch_fulltextRead arXiv papers' actual text, by section. Section selection controls context cost: ask for the one or two you need, not whole papers — 'all' is ~13.5KB a paper, 8 of them ~108KB. Section labels are inferred: check `low_confidence_sections` before calling one the paper's own. Sourced from arXiv's section-tagged HTML, then LaTeX, then PDF; a 404 means all three failed.
find_authorTwo-mode author tool. Provide exactly one of q or id. Q-MODE (q=...): search for researchers by topic or name — uses embedding similarity for topics ('efficient LLM inference'), fuzzy matching for names ('Yann LeCun'). Returns a list of matching authors with author_id, name, h_index, total_papers, primary_field, research_topics. ID-MODE (id=...): look up a single author profile by author_id (obtained from a previous q-mode call or from co_author_graph results). Returns h-index, total citations, global rank, primary field, novelty score distribution, research topics, code/venue scores, years active, and their top 10 papers by rank score.
co_author_graphFind the co-authorship neighborhood of one or more authors. Given a list of author_ids, returns edges {from, to, papers_count, last_collab_year} where 'from' is one of the input authors and 'to' is any co-author appearing on a shared paper within the window. Use for AC reviewer triage (find conflicts), disambiguating researchers (who do they actually work with?), or expanding an author seed into a research community. window_years defaults to 10. Result is capped at 500 edges, sorted by papers_count DESC.
embed_textEmbed a text string into a 768-dim Gemini Flash vector. Use for HyDE-style retrieval: (1) write a hypothetical short paper that would perfectly answer the user's query, (2) embed it with task_type='RETRIEVAL_DOCUMENT' (default — matches the corpus embedding side), (3) pass the resulting embedding back through search-style tools to find real papers nearest to the hypothetical. task_type='RETRIEVAL_QUERY' matches the query side and is useful for direct user-query embedding without HyDE. Pro-only — requires an SF_API_KEY on a Pro account; anonymous and free callers get a 403 pro_required. Cost: ~$0.0001/call; rate-limited at 30/minute per API key.
get_field_orientationReturns CANDIDATE FOUNDATIONAL PAPERS for a research topic — cheap retrieval only, no synthesis. Ranks papers by a blend of citation count (0.6 weight, captures importance) and semantic similarity to your topic (0.4 weight). Use this to bootstrap a literature survey or get a fast sense of the landscape. For a synthesized orientation report (key concepts, open problems, reading order), use the /field-guide skill which calls this tool internally. Does not require a Pro API key — no LLM calls are made.
get_foundational_lineageReturns the FOUNDATIONAL WORK FOR A PAPER'S NICHE via the citation graph — the relative question ('what is foundational for THIS paper's specific sub-field', often itself only modestly cited) rather than the obvious global landmarks. Anchors on the paper, takes its embedding neighbourhood as the niche, and ranks what the niche cites into three tiers: `niche_roots` (the niche-specific foundations, ranked by how specifically the neighbourhood builds on them — surfaces canonical anchors that semantic search misses), `field_level` (broader secondary foundations), and `discipline` (universal landmarks like Attention Is All You Need, collapsed out of the way). Each paper carries `cited_by_in_niche` evidence so the claim is grounded, not asserted. Use this to trace prior art / lineage for a paper, or to find the canonical methods a niche is built on. Complements get_field_orientation (which is topic-anchored and retrieval-only). No Pro key and no LLM calls required.
save_paperSave a paper to the authenticated user's Scholar Feed library (bookmark). MUTATES the library and feeds the user's personalization — saved papers are the strongest signal in the For You feed and the email digest. Idempotent: calling it again on an already-saved paper leaves it saved. Requires SF_API_KEY. To file it into a named collection in one step, use add_to_collection (that also saves).
unsave_paperRemove a paper from the authenticated user's Scholar Feed library. MUTATES the library. Idempotent: removing a paper that isn't saved leaves it unsaved. Note: the saved library is a superset of all collections, so un-saving a paper ALSO removes it from every collection it was in. To keep it filed in a collection, use remove_from_collection instead (that leaves the paper saved). Requires SF_API_KEY.
like_paperLike a paper — a 'more like this' calibration signal that tunes the user's For You feed toward similar work. INSERT-only and idempotent (liking twice is a no-op, never un-likes). Distinct from save_paper: like expresses taste for ranking; save bookmarks for later reading. Requires SF_API_KEY.