TGGET Niche Research vs Scholar Sidekick MCP | AllMCPs
TGGET Niche Research vs Scholar Sidekick MCP
A side-by-side look at the TGGET Niche Research and Scholar Sidekick 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 Sidekick 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 Sidekick MCP tools 7
verifyCitationVerify a claimed citation against the resolved record at its identifier. Detects the dominant AI-driven fabrication pattern documented by Topaz et al. (Lancet 2026): a real, resolvable identifier (DOI / PMID / PMCID / arXiv / etc.) paired with a title that does NOT correspond to the paper at that identifier. Use when the user pastes a citation and asks 'is this real?' or 'check this DOI' — most fabricated citations resolve cleanly under doi.org but their cited title and the resolved title disagree. Single citation per call. Required: `title` plus exactly one identifier (doi, pmid, pmcid, isbn, arxiv, issn, ads, or whoIrisUrl). Optional refinements: author (first-author family name), year, container (journal). Set `screenWithLlm: true` to invoke the Stage 3 LLM screen on low-confidence mismatches (catches informal-abbreviation false positives); LLM access is gated to authenticated first-party keys and paid RapidAPI tiers — anonymous callers get 400 LLM_SCREEN_FORBIDDEN. Returns: { verdict: 'matched' | 'mismatch' | 'not_found' | 'ambiguous', confidence: 'high' | 'medium' | 'low', matched: <resolved record or null>, mismatches: [{field, claimed, resolved, similarity}], candidates: [{item, registries, score}] (when title-search ran), _provenance: {stages_run, resolved_via, registries_searched, llm_screen} }. Verdict semantics: 'matched' = claim agrees with resolved record; 'mismatch' = identifier resolves but title does not match (Topaz fabrication pattern); 'ambiguous' = identifier resolves to one paper but the claimed title matches a DIFFERENT paper found via title-search (CITADEL 'citation error' subtype — wrong identifier for a real paper); 'not_found' = neither the identifier nor the title resolves anywhere. No sibling tool overlaps: resolveIdentifier returns metadata for a known-good identifier; verifyCitation is the only tool that cross-checks claimed title vs resolved metadata. Read-only and idempotent — safe to retry. Works anonymously for the non-LLM path; the Stage 3 LLM screen requires authentication — set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) or use a paid RapidAPI tier. SCHOLAR_API_KEY also raises your rate limit.
auditBibliographyVerify a WHOLE bibliography in one call — the batch counterpart to verifyCitation. Each entry runs the same fabrication check (real, resolvable identifier paired with a title that does NOT match the resolved paper; Topaz et al., Lancet 2026) plus a retraction lookup, and the tool returns a per-entry verdict table and a corpus summary. Use when the user pastes a reference list, a .bib / .ris file, or asks to 'check all these citations at once' / 'audit my bibliography' / 'which of these references are fake or retracted'. Input: EITHER `bibliography` (raw BibTeX / RIS / CSL-JSON text — format auto-detected) OR `claims` (an array of pre-parsed {title + identifier} objects), not both. Capped at 25 entries per call; excess is dropped and reported via `truncated`. `checks` defaults to ['retraction'] (pass [] to skip); `screenWithLlm` opt-in per entry (same auth gating as verifyCitation). Returns: { format, entries: [{ index, sourceKey?, status: 'ok'|'error', verdict: 'matched' | 'mismatch' | 'not_found' | 'ambiguous', confidence, matched, mismatches, retraction: { checked, doi, isRetracted, hasCorrections, hasConcern, notices } | null, _provenance }], parseErrors: [{ index, error, message }], truncated, summary: { total, matched, mismatch, ambiguous, not_found, errored, retracted } }. Reading the result: `index` is 1-BASED (entry 1 is the first reference) — do not add 1 again when reporting it. `sourceKey` is the entry's own key in the source file (BibTeX cite key, RIS `ID`, CSL-JSON `id`) and is the reliable way to point a user at the offending reference; it is absent on the claims[] path. `entries` and `parseErrors` share one index space, so a given input position appears in exactly one of them — report parseErrors as UNCHECKED, never as clean. `summary.total` counts verifiable entries only, excluding parseErrors and anything past the cap; `summary.retracted` is a separate axis from the verdict counts (an entry can be both matched and retracted), so never sum those fields. A non-zero `truncated` means the audit is incomplete — split the bibliography and call again. Per-entry leniency: one entry that fails to resolve becomes status:'error' without failing the batch. This audits citation IDENTITY (does each identifier resolve to the claimed work, and is it retracted) — it does NOT check whether a source supports the claim it is cited for. Read-only and idempotent. Works anonymously for the non-LLM path; SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) or a paid RapidAPI tier raises rate limits and enables the optional LLM screen.
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 Sidekick MCP belongs to Research and uses a local stdio subprocess. Pick TGGET Niche Research for research work and Scholar Sidekick 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 Sidekick MCP is listed as free. 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 mlava-scholar-sidekick-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 Sidekick MCP has 60/100 (Good) with 4 views, 0 installs and 11 GitHub stars.
checkRetractionCheck whether a single scholarly work has been retracted, corrected, or had an expression of concern raised. Use when the user asks 'has this paper been retracted?' or wants to verify a paper's standing before citing it (clinical, regulatory, evidence-synthesis contexts). For multi-paper bibliography audits (clinical guidelines, systematic reviews), loop one call per identifier — the tool intentionally rejects batch input to keep retraction-status results unambiguous per work. Sourced from Crossref `updated-by` (which mirrors Retraction Watch). Resolves DOI/PMID/PMCID/arXiv/ADS inputs to a DOI before lookup; ISBN inputs always return doi=null and reason='no_doi' since books are not in the retraction graph. Single identifier per call — does NOT accept comma/newline batches; loop one call per identifier for multiple papers. Returns: { doi, resolvedFrom?, reason?, result } where result has isRetracted, hasCorrections, hasConcern (booleans), notices (array of {type: 'retraction'|'correction'|'expression-of-concern', label, doi, date, source}), and title; result is null when no DOI could be resolved and reason explains why ('no_doi'). No sibling tool overlaps this — resolveIdentifier returns metadata but not retraction status. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier; Crossref is queried server-side with its own caching.
checkOpenAccessCheck whether a single scholarly work is openly accessible and where to find the best legal version. Use when the user asks 'is this open access?', 'where can I read this for free?', or wants the OA license/version before reusing or redistributing. Sourced from Unpaywall. Resolves DOI/PMID/PMCID/arXiv/ISBN/ADS inputs to a DOI before lookup; inputs that don't map to a DOI return doi=null and reason='no_doi'. Single identifier per call — does NOT accept comma/newline batches; loop one call per identifier for multiple papers. Returns: { doi, resolvedFrom?, reason?, result } where result has isOa (boolean), oaStatus ('gold' | 'green' | 'hybrid' | 'bronze' | 'closed'), title, bestLocation ({url, hostType: 'publisher' | 'repository', license, version: 'submittedVersion' | 'acceptedVersion' | 'publishedVersion'} or null), and locations (array of the same shape); result is null when no DOI could be resolved and reason explains why ('no_doi'). No sibling tool overlaps this — resolveIdentifier returns metadata but not OA status. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier; Unpaywall is queried server-side with its own caching.
resolveIdentifierResolve scholarly identifiers to structured CSL JSON metadata (title, authors, journal, year, identifiers). Use when the user wants raw bibliographic data to inspect, transform, or feed into another tool — not a formatted citation. Common single-shot conversions: PMID → PMCID, arXiv → DOI, ISBN → CSL JSON, WHO IRIS URL → structured metadata. Accepts DOI, PMID, PMCID, ISBN, arXiv ID, ISSN, NASA ADS bibcode, or WHO IRIS URL, with or without prefixes (PMID:, arXiv:, ISBN hyphens, https://doi.org/...). Pass a single identifier or a comma/newline-separated batch — one round trip per call. Returns: a JSON array of CSL items, each with id, type, title, author[], issued.date-parts, container-title, DOI/PMID/PMCID/ISBN/ISSN/URL when available. Use formatCitation instead when the user wants a finished citation string in a specific style; use exportCitation when they want a downloadable bibliography file. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier; the underlying REST API caches repeated identical requests and surfaces cache state in the x-scholar-cache response header.
formatCitationFormat scholarly identifiers into a finished citation in a specific style. Use when the user wants a paste-ready citation string for a manuscript, slide, message, footnote, or in-line reference. Style defaults to vancouver if unspecified; ask the user before defaulting if any ambiguity exists (e.g. 'Harvard' and 'Chicago' have multiple variants — confirm which one). Supports five hand-tuned builtins (vancouver, ama, apa, ieee, cse) plus any of 10,000+ CSL style IDs (chicago-author-date, harvard-cite-them-right, modern-language-association, nature, bmj, the-lancet, etc.). Alias and dependent-style resolution apply, so 'harvard' resolves to 'harvard-cite-them-right' and the canonical ID is reported back as styleUsed. Output defaults to text; pass output=html for marked-up HTML or output=json for structured CSL items. Accepts the same identifier formats as resolveIdentifier (DOI/PMID/PMCID/ISBN/arXiv/ISSN/ADS/WHO IRIS, prefixes tolerated), single or comma/newline-separated batch — one round trip per call. Returns: one of { text, html, items } depending on the output parameter, followed by a metadata block ({formatter: 'builtin' | 'csl', styleUsed, requestId, warnings?}) appended as a second text content item — surface this to the user when they care about reproducibility. Use resolveIdentifier instead when the user wants raw metadata to inspect or transform; use exportCitation when they want a downloadable bibliography file. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier.
exportCitationExport scholarly identifiers to a bibliography file format ready to write to disk or paste into a reference manager. Use when the user wants a file (.bib, .ris, .nbib, .xml, .rdf, .csv) for Zotero, Mendeley, EndNote, RefWorks, BibTeX/LaTeX, Pandoc, or Excel. Format parameter is required: bib (BibTeX — LaTeX), ris (RIS — most widely supported by reference managers), csl (CSL JSON — Pandoc/Quarto), endnote-xml, endnote-refer, refworks, medline (NBIB — PubMed round-trips, clinical workflows), zotero-rdf, csv (spreadsheet-friendly), or txt (plain-text bibliography rendered with the optional style parameter — txt is the only format that uses style; the others have their own structured shape and ignore it). Accepts the same identifier formats as resolveIdentifier (DOI/PMID/PMCID/ISBN/arXiv/ISSN/ADS/WHO IRIS, prefixes tolerated), single or comma/newline-separated batch — one round trip per call. Returns: { content: string, format: string } where content is the entire bibliography in the requested format as a single string — write it to a file (.bib/.ris/.nbib/etc.) or paste it directly into the target tool. Use formatCitation instead when the user wants in-line citation text (manuscript, slide); use resolveIdentifier when they want raw structured metadata. Read-only and idempotent — safe to retry. Works anonymously against the public Scholar Sidekick API (rate-limited free tier); set SCHOLAR_API_KEY (a free ssk_ key from https://scholar-sidekick.com/account) for higher limits, or RAPIDAPI_KEY for paid RapidAPI tiers. Rate limits follow your tier.