Scholar Sidekick MCP Server

Most developer tooling work still happens through a UI a human drives. Scholar Sidekick MCP MCP server moves it into the conversation instead. MCP server that catches AI-fabricated citations: verifies a claimed title against the real record at its DOI or PMID (the Topaz et al. Lancet 2026 pattern), audits whole bibliographies, and checks retraction and open-access status — plus.

The short version

All seven tools are read-only (readOnlyHint: true, destructiveHint: false). The exact tools/list payload — descriptions, JSON Schemas, and annotations — is committed as tools.json and ships in the npm tarball, so you can review the full tool surface without running anything.

• Whole-bibliography audit — — auditBibliography runs that same check plus a retraction lookup across an entire reference list in one call, taking raw BibTeX, RIS, or CSL JSON and returning a per-entry verdict table with a corpus summary
• Eight identifier types out of the box — — DOIs, PMIDs, PMCIDs, ISBNs, arXiv IDs, ISSNs, NASA ADS bibcodes, and WHO IRIS URLs (rare in citation tooling)
• Batch-friendly resolve / format / export — — each accepts a single identifier or a comma- or newline-separated list; the server normalises the list and resolves them in one round trip
• 10,000+ citation styles — — five hand-tuned builtins (Vancouver, AMA, APA, IEEE, CSE) plus any CSL style ID, with alias and dependent-style resolution
• Nine export formats — — BibTeX, RIS, CSL JSON, EndNote (XML/Refer), RefWorks, MEDLINE, Zotero RDF, CSV, plain text
• Composable workflow — — chain resolveIdentifier → formatCitation → exportCitation in one prompt for an end-to-end "raw IDs → exportable bibliography" pipeline

Getting it running

Because this one is hosted, setup is mostly authentication — you point your client at the endpoint and approve access. Nothing runs on your machine, so there is no runtime to keep patched.

The tools it exposes

The server publishes 7 tools. What each one is for:

• verifyCitation — Verify a claimed citation against the resolved record at its identifier. Detects the Topaz et al. (Lancet 2026) fabrication pattern — real DOI +
• auditBibliography — Run the verifyCitation check plus a retraction lookup across a whole bibliography in one call. Accepts raw BibTeX, RIS, or CSL-JSON text, or a
• resolveIdentifier — Resolve DOIs, PMIDs, PMCIDs, ISBNs, arXiv IDs, ISSNs, ADS bibcodes, and WHO IRIS URLs to structured bibliographic metadata (CSL JSON). Accepts a
• formatCitation — Format one or many identifiers into Vancouver, AMA, APA, IEEE, CSE, or any of 10,000+ CSL styles. Output as text, HTML, or JSON. Returns formatted
• exportCitation — Export one or many identifiers to BibTeX, RIS, CSL JSON, EndNote (XML/Refer), RefWorks, MEDLINE, Zotero RDF, CSV, or plain text — ready to write to
• checkRetraction — Check whether a single work has been retracted, corrected, or had an expression of concern raised. Sourced from Crossref updated-by (Retraction
• checkOpenAccess — Check whether a single work is openly accessible and where to find the best legal version. Sourced from Unpaywall. Returns OA status

What it needs from you

Configuration is passed through the environment: SCHOLAR_API_KEY, RAPIDAPI_KEY, RAPIDAPI_HOST, SCHOLAR_SIDEKICK_URL. Treat anything key-shaped as a real credential — scope it to the minimum the server needs, and rotate it if it ever lands in a shared config.

Things to watch

• Your data travels to the provider's service, so the usual questions apply about what you send and what they retain.
• Missing credentials fail quietly in some clients — if no tools show up, check the environment block first.
• Keep per-call confirmation enabled while you learn its behaviour; it is the cheapest safeguard you have.

How it compares

Plenty of developer tooling servers cover similar ground. The differences that matter in practice are scope of access and how much setup stands between you and a working tool call. Scholar Sidekick MCP's toolset — verifyCitation, auditBibliography, resolveIdentifier and 4 more — is a fair guide to whether it matches your workflow. It is maintained by mlava; worth a glance at recent repository activity before you build anything load-bearing on it.

SyncDev reviews every entry in this directory against the project's own documentation before publishing, and revisits them as servers change.