Skip to main content
Glama
deenesjakoruzh
mlava

Scholar Sidekick

by mlava
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Scholar Sidekick MCP Server

MCP server for Scholar Sidekick — catch AI-fabricated citations, one at a time or across a whole bibliography, from any AI assistant. It also checks retraction and open-access status, and resolves any scholarly identifier (DOI, PMID, PMCID, ISBN, arXiv, ISSN, NASA ADS bibcode, WHO IRIS URL) into 10,000+ CSL styles or nine export formats.

Highlights

  • Citation-fabrication detection — verifyCitation cross-checks a claimed citation against the resolved record at its identifier, detecting the dominant AI-driven fabrication pattern documented by Topaz et al. (Lancet 2026) — real DOI + invented title — that simple identifier resolution cannot catch. Long-form explainer at scholar-sidekick.com/citation-integrity.

  • 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.

  • Retraction & open-access checks — checkRetraction surfaces retractions, corrections, and expressions of concern (Crossref / Retraction Watch); checkOpenAccess returns OA status and the best legal landing or PDF URL (Unpaywall). Both accept any identifier type and resolve it to a DOI under the hood.

  • 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.

  • Provenance metadata on every response — formatted output is followed by a metadata block (requestId, formatter, styleUsed, warnings) so the assistant can show users which engine produced each citation.

  • No key required — works anonymously against the public Scholar Sidekick API (rate-limited free tier); add a free first-party ssk_ key for higher limits, or a RapidAPI key for paid/managed tiers.

  • Hosted HTTP endpoint (no install) — prefer not to run a local stdio server? Connect any HTTP-capable MCP client straight to https://scholar-sidekick.com/api/mcp (Streamable HTTP, same 7 tools). See Hosted HTTP endpoint.

  • REST API twin — the same endpoints are available as the Scholar Sidekick REST API for non-MCP integrations.

Related MCP server: cite-mcp

Tools

Tool

Description

verifyCitation

Verify a claimed citation against the resolved record at its identifier. Detects the Topaz et al. (Lancet 2026) fabrication pattern — real DOI + invented title — that resolveIdentifier alone cannot catch. Returns one of four verdicts (matched / mismatch / ambiguous / not_found) plus per-field similarity scores and the resolved record so the user can see where the cited title and the actual paper diverged. Optional Stage 3 LLM screen rescues informal-abbreviation false positives (paid plans / first-party authentication only). One citation per call.

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 pre-parsed claims[] array; returns a per-entry verdict table and a corpus summary. Capped at 25 entries per call.

resolveIdentifier

Resolve DOIs, PMIDs, PMCIDs, ISBNs, arXiv IDs, ISSNs, ADS bibcodes, and WHO IRIS URLs to structured bibliographic metadata (CSL JSON). Accepts a single identifier or a comma/newline-separated batch.

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 citations plus a provenance metadata block.

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 disk or hand to a reference manager.

checkRetraction

Check whether a single work has been retracted, corrected, or had an expression of concern raised. Sourced from Crossref updated-by (Retraction Watch). Resolves DOI/PMID/PMCID/arXiv/ADS inputs to a DOI before lookup. One identifier per call.

checkOpenAccess

Check whether a single work is openly accessible and where to find the best legal version. Sourced from Unpaywall. Returns OA status (gold/green/hybrid/bronze/closed), best landing/PDF URL, license, and version. Resolves DOI/PMID/PMCID/arXiv/ISBN/ADS inputs to a DOI before lookup. One identifier per call.

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.

Setup

No key required. The server works anonymously against the public Scholar Sidekick API (https://scholar-sidekick.com) at a rate-limited free tier — just install and go. To raise your limits, create a free first-party ssk_ key at scholar-sidekick.com/account and set SCHOLAR_API_KEY. For paid/managed tiers, subscribe on RapidAPI and set RAPIDAPI_KEY (which routes calls through the RapidAPI gateway).

Prefer zero install? There's also a hosted HTTP endpoint at https://scholar-sidekick.com/api/mcp (Streamable HTTP) — connect any HTTP-capable MCP client directly, no npx needed. See Hosted HTTP endpoint below. The stdio package documented here is the local-install alternative (and the path for RapidAPI-keyed users).

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or %APPDATA%\Claude\claude_desktop_config.json (Windows). No key, no env block:

{
  "mcpServers": {
    "scholar-sidekick": {
      "command": "npx",
      "args": ["-y", "scholar-sidekick-mcp@latest"]
    }
  }
}

Only if you want higher rate limits, add an env block with a free ssk_ key from scholar-sidekick.com/account:

"env": { "SCHOLAR_API_KEY": "ssk_your-first-party-key" }

Claude Code

# Anonymous (no key):
claude mcp add scholar-sidekick -- npx -y scholar-sidekick-mcp@latest

# With a free first-party key for higher limits:
claude mcp add scholar-sidekick \
  -e SCHOLAR_API_KEY=ssk_your-first-party-key \
  -- npx -y scholar-sidekick-mcp@latest

Claude Code plugin (server + skill in one step)

This repo is also a Claude Code plugin marketplace. Installing the plugin wires up the MCP server and the companion agent skill together — no separate claude mcp add, no env block:

/plugin marketplace add mlava/scholar-sidekick-mcp
/plugin install scholar-sidekick@scholar-sidekick

The plugin runs the server anonymously (no key). For higher rate limits, add a free ssk_ key from scholar-sidekick.com/account via claude mcp add as shown above, or use the hosted endpoint below.

Cursor / VS Code / Windsurf

Add to .cursor/mcp.json or .vscode/mcp.json. No key needed:

{
  "mcpServers": {
    "scholar-sidekick": {
      "command": "npx",
      "args": ["-y", "scholar-sidekick-mcp@latest"]
    }
  }
}

For higher rate limits, add "env": { "SCHOLAR_API_KEY": "ssk_your-first-party-key" }.

Run in a container (sandboxed)

The server speaks MCP over stdio and needs outbound HTTPS to the Scholar Sidekick API and nothing else — no filesystem access, no shell. If your policy is that MCP servers don't get host access, build the image in this repo and run it isolated:

docker build -t scholar-sidekick-mcp .
{
  "mcpServers": {
    "scholar-sidekick": {
      "command": "docker",
      "args": [
        "run", "-i", "--rm",
        "--read-only", "--cap-drop", "ALL", "--security-opt", "no-new-privileges",
        "scholar-sidekick-mcp"
      ]
    }
  }
}

-i is required — that's the stdio pipe. Add "-e", "SCHOLAR_API_KEY", to the args only if you are passing a key for higher limits. No image is published to a registry; build it locally so you're running a bundle you built from source you can read.

Agent skill (optional)

Install a companion Agent Skill that teaches Claude Code, Cline, and other agents when and how to use these tools — it complements the server config above:

npx skills add mlava/scholar-sidekick-mcp

Hosted HTTP endpoint (no install)

Don't want to run a local stdio server? Scholar Sidekick is also a hosted Streamable HTTP MCP at https://scholar-sidekick.com/api/mcp — the same seven tools, no npx, no local process. It works anonymously (rate-limited free tier); add an Authorization: Bearer ssk_… header (a free key from scholar-sidekick.com/account) for higher limits.

Point any HTTP-capable MCP client at it:

{
  "mcpServers": {
    "scholar-sidekick": {
      "type": "http",
      "url": "https://scholar-sidekick.com/api/mcp"
    }
  }
}

In Claude Desktop, use Settings → Connectors → Add custom connector (or "Add HTTP server") and paste the URL. Add the bearer token in the client's header/auth field if you have one.

Discovery: /.well-known/mcp.json (SEP-1649 server card) lists this endpoint plus the no-auth ChatGPT Apps endpoint at /api/apps/mcp. The stdio package above remains the local-install alternative and the path for RapidAPI-keyed users.

Environment Variables

Variable

Required

Description

SCHOLAR_API_KEY

No

Free first-party ssk_ key from scholar-sidekick.com/account; raises rate limits and enables the verifier's LLM screen. Sent as Authorization: Bearer.

RAPIDAPI_KEY

No

RapidAPI subscription key for paid/managed tiers; when set, calls route through the RapidAPI gateway.

RAPIDAPI_HOST

No

RapidAPI host (defaults to scholar-sidekick.p.rapidapi.com)

SCHOLAR_SIDEKICK_URL

No

Override the API base URL (defaults to https://scholar-sidekick.com, or the RapidAPI gateway when RAPIDAPI_KEY is set).

SCHOLAR_SIDEKICK_TIMEOUT_MS

No

Request timeout in milliseconds (default: 30000)

No key at all → anonymous, rate-limited free tier. With both SCHOLAR_API_KEY and RAPIDAPI_KEY set, RapidAPI takes precedence.

Supported Citation Styles

Scholar Sidekick supports 10,000+ CSL styles, including all major formats used in academic publishing:

Style

Keyword

Vancouver

vancouver

APA (7th ed.)

apa

AMA

ama

IEEE

ieee

CSE

cse

Chicago (author-date)

chicago-author-date

Harvard

harvard-cite-them-right

MLA

modern-language-association

Turabian

turabian-fullnote-bibliography

Nature

nature

BMJ

bmj

Lancet

the-lancet

Any CSL style ID can be passed as the style parameter.

Example Usage

Once connected, ask your AI assistant:

Single identifier

  • "Format 10.1056/NEJMoa2033700 in Vancouver style"

  • "Resolve PMID:30049270 and export as BibTeX"

  • "Give me a Chicago citation for arXiv:2301.08745"

Batch input (comma- or newline-separated — every tool handles it)

  • "Format these as APA: 10.1056/NEJMoa2033700, PMID:30049270, ISBN:9780192854087"

  • "Resolve all of these and tell me which are journal articles vs books: 10.1056/NEJMoa2033700, ISBN:9780192854087, PMC7793608"

End-to-end workflow (the assistant chains resolveIdentifier → formatCitation → exportCitation in one prompt)

  • "Resolve these three identifiers, format each in AMA, and export the set as BibTeX: 10.1056/NEJMoa2033700, PMID:30049270, ISBN:9780192854087"

  • "Build me a Nature-style bibliography from this list and give me a .bib file at the end: PMID:30049270, arXiv:2301.08745, 10.1038/s41586-021-03819-2"

Retraction & open-access checks (one identifier per call)

  • "Has 10.1016/S0140-6736(20)31180-6 been retracted?" → returns isRetracted: true with the retraction notice and date

  • "Is the NumPy paper (10.1038/s41586-020-2649-2) open access? Where can I read it for free?" → returns OA status plus the best legal PDF URL with license and version

  • "Check whether arXiv:2301.08745 has any corrections or expressions of concern." → resolves arXiv → DOI, then queries Retraction Watch

Supported Identifiers

  • DOIs (e.g. 10.1056/NEJMoa2033700)

  • PubMed IDs (e.g. PMID:30049270)

  • PubMed Central IDs (e.g. PMC7793608)

  • ISBNs (e.g. ISBN:9780192854087)

  • arXiv IDs (e.g. 2301.08745)

  • ISSNs and eISSNs

  • NASA ADS bibcodes

  • WHO IRIS URLs

Provenance & Determinism

Every formatCitation and exportCitation response is followed by a metadata block so the assistant — and the user — can see exactly which engine produced each citation:

  • formatter — builtin (one of Vancouver, AMA, APA, IEEE, CSE — hand-tuned in TypeScript) or csl (citeproc-js with a CSL stylesheet).

  • styleUsed — the canonical style ID after alias and dependent-style resolution (e.g. asking for harvard resolves to harvard-cite-them-right).

  • requestId — for support, reproducibility, and log correlation.

  • warnings — populated when a fallback was used or the requested style was a dependent of another.

Identifier resolution is deterministic given the same inputs and pinned upstream metadata. Repeated identical requests are cache-hit on the underlying REST API and surface that via the x-scholar-cache header.

REST API

For programmatic access outside of MCP clients, the same capabilities are available as a REST API at scholar-sidekick.com — anonymously, with a free first-party ssk_ key (Authorization: Bearer), or via RapidAPI for paid tiers. Whichever credential you use here works there too.

Development

npm install
npm run build    # Bundle to dist/mcp-server.mjs
npm test         # Run tests
npm run typecheck

License

MIT

MCP Badge M8ven Verified

Available Tools

7 tools
auditBibliographyAudit BibliographyA
Read-onlyIdempotent
Inspect

Verify 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); semanticTitle opt-in per entry (any tier; catches one-word title swaps, flagged → 'ambiguous' for review); 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
checksNoPer-entry enrichment checks. Defaults to ['retraction'] (flags retracted / corrected / expression-of-concern works via Crossref + Retraction Watch, keyed on each resolved DOI). Pass [] to skip.
claimsNoPre-parsed citations to audit — an alternative to `bibliography` for agents that already hold structured references. Each needs a `title` plus whatever identifiers the citation carries.
formatNoOverride format auto-detection for `bibliography`.
bibliographyNoRaw bibliography text to parse and audit — BibTeX, RIS, or CSL-JSON. Provide EITHER this or `claims`, not both. Format is auto-detected; override with `format`. Capped at 25 entries per call (excess dropped, reported via `truncated`).
screenWithLlmNoOpt-in Stage 3 LLM screen applied per entry (same gating as verifyCitation). Default false.
semanticTitleNoOpt-in semantic title check applied per entry (any tier; see verifyCitation). Default false.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover readOnly/idempotent/destructive, but the description adds substantial beyond them: the 25-entry cap with truncation reporting, per-entry error leniency, anonymous vs SCHOLAR_API_KEY rate-limit behavior, the auth gating on screenWithLlm, and the meaning of truncated for audit completeness. This is rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose, then usage triggers, then input contract, then result-reading guidance. It is long, but nearly every sentence carries operational weight (index base, sourceKey semantics, index space sharing, summary field caveats). Minor density that could be trimmed without loss.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex batch tool with no output schema, the description fully specifies the return shape, explains how to read index/sourceKey/parseErrors/truncated, warns against double-adding 1 and against summing overlapping summary fields, and states the scope boundary. An agent has everything needed to call and interpret it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description still adds value by clarifying the either/or relationship of `bibliography` vs `claims`, the default of `checks` and that [] skips it, and that `semanticTitle`/`screenWithLlm` are per-entry opt-ins with tier/auth implications. Slightly above baseline because it explains interactions the schema only implies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Verify a WHOLE bibliography') and immediately differentiates from the sibling verifyCitation as its batch counterpart. Names the exact checks performed (fabrication, retraction) and the input forms accepted. An agent can distinguish this from verifyCitation without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit trigger conditions ('user pastes a reference list, a .bib/.ris file, or asks to check all these citations at once'). Also states an exclusion: it audits citation IDENTITY, NOT whether a source supports its claim. This is a model when-to-use section.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

checkOpenAccessCheck Open AccessA
Read-onlyIdempotent
Inspect

Check 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesA single scholarly identifier to check. 1–500 characters. Non-DOI inputs are resolved to a DOI server-side before the lookup; if no DOI can be derived, the tool returns doi=null with reason='no_doi'. Pass exactly one identifier — comma/newline batches are NOT accepted by this tool; loop one call per identifier for multiple papers. Accepted: DOI (including a shortDOI alias such as 10/aabbe), PMID, PMCID, arXiv ID, ISBN, or NASA ADS bibcode (with or without prefixes).

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds substantial behavioral context beyond annotations: identifier resolution to DOI, the doi=null/reason='no_doi' failure mode, rejection of batches, full return shape, rate limits, API key options, and server-side Unpaywall caching.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but densely informative; each sentence earns its place. It is front-loaded with purpose and usage triggers before diving into resolution behavior, return structure, and API details. Minor redundancy with the schema's parameter description prevents a perfect score.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity and absence of an output schema, the description covers everything: return format, error handling, accepted identifier types, rate limits, auth setup, sibling differentiation, and idempotency. An agent has enough information to select, call, and interpret results correctly without further lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already has 100% coverage with a detailed description of the id parameter. The description adds further meaning by explaining how non-DOI identifiers are resolved, how resolution failures surface in the response, and how the return object relates to the parameter.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource ('Check whether a single scholarly work is openly accessible') and further clarifies it finds the best legal version. It also explicitly differentiates from siblings by stating 'No sibling tool overlaps this — resolveIdentifier returns metadata but not OA status.'

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives concrete trigger phrases ('is this open access?', 'where can I read this for free?') and when to use it (wanting OA license/version before reuse). It also explicitly names resolveIdentifier as the non-overlapping alternative, providing clear when-to-use and when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

checkRetractionCheck RetractionA
Read-onlyIdempotent
Inspect

Check 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). To check a WHOLE reference list for retractions (e.g. 'check all these citations for retractions' at the end of a literature review, a guideline or a systematic review), use auditBibliography instead — one call runs the retraction check plus the fabrication check on up to 25 entries. 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; for a handful of papers loop one call per identifier, for a bibliography use auditBibliography. 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'). resolveIdentifier returns metadata but not retraction status; auditBibliography includes this check for every entry of a bibliography. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesA single scholarly identifier to check. 1–500 characters. Non-DOI inputs are resolved to a DOI server-side before the lookup; if no DOI can be derived, the tool returns doi=null with reason='no_doi'. Pass exactly one identifier — comma/newline batches are NOT accepted by this tool; loop one call per identifier for multiple papers. Accepted: DOI (including a shortDOI alias such as 10/aabbe), PMID, PMCID, arXiv ID, or NASA ADS bibcode (with or without prefixes). ISBN inputs are accepted but always return doi=null since books are not in the retraction graph.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantial behavior beyond them: the Crossref `updated-by` data source, single-identifier-only enforcement, ISBN always yielding doi=null with reason='no_doi', anonymous free-tier access with SCHOLAR_API_KEY/RAPIDAPI_KEY auth paths, tier-based rate limits, and server-side Crossref caching. This is exactly the extra context the annotations do not carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but well front-loaded: purpose, trigger, and the sibling alternative come first, with mechanics and return shape after. It is on the long side and the no-batch rule is repeated in both description and schema, but nearly every sentence carries operational information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by spelling out the return shape ({doi, resolvedFrom?, reason?, result} with isRetracted/hasCorrections/hasConcern/notices/title) and the null-result case. It also covers auth, rate limits, and input resolution, so nothing needed for a correct call is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the `id` field is documented exhaustively in the schema itself (accepted identifier types, length bounds, no-batch rule, ISBN caveat). The description largely restates that same material, so it adds little beyond the schema. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb+resource (check whether a single scholarly work is retracted/corrected/under concern) and scopes it to one identifier, explicitly contrasting with auditBibliography for whole bibliographies. An agent can distinguish it from verifyCitation, resolveIdentifier, and auditBibliography without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives concrete triggering user phrasings ('has this paper been retracted?'), the motivating contexts (clinical, regulatory, evidence synthesis), and an explicit when-not/alternative rule: whole reference lists up to 25 entries go to auditBibliography. It even prescribes the workaround (loop one call per identifier) for a handful of papers.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

exportCitationExport CitationA
Read-onlyIdempotent
Inspect

Export 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoBCP-47 locale tag (e.g. 'en-US') — used only when format='txt' and style is set. Ignored by structured formats.
textYesOne or more scholarly identifiers to process — DOI (with or without https://doi.org/; a shortDOI alias such as 10/aabbe is also accepted and expanded to the full DOI), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip.
styleNoCitation style ID — used only when format='txt'. Same vocabulary as formatCitation's style parameter (vancouver, apa, ama, ieee, cse, or any CSL style ID). Ignored by all other formats.
formatYesExport format. 'bib' (BibTeX/.bib for LaTeX), 'ris' (RIS — most widely supported by reference managers), 'csl' (CSL JSON for Pandoc/Quarto), 'endnote-xml' (EndNote XML import), 'endnote-refer' (EndNote Refer/tagged), 'refworks' (RefWorks tagged), 'medline' (NBIB for PubMed round-trips), 'zotero-rdf' (Zotero RDF), 'csv' (spreadsheet-friendly), or 'txt' (plain-text bibliography rendered with the optional `style` parameter).

TDQS

A5/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations provide readOnlyHint and idempotentHint, and the description reinforces these while adding extra context: one round trip per batch call, return shape {content, format}, anonymous vs. keyed rate limits, and the fact that 'txt' is the only format that uses style. This goes well beyond what annotations alone convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but every sentence earns its place. It is front-loaded with purpose, then usage, alternatives, behavior, and auth details in a logical order. The format list is dense but necessary to disambiguate otherwise cryptic enum values.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with 4 parameters, no output schema, and a broad format enum, the description covers everything an agent needs to invoke it correctly: return shape, format-specific behavior, identifier handling, batch semantics, auth/rate limits, and clear routing relative to sibling tools. Nothing critical is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description significantly adds semantics by explaining identifier prefix tolerance, batch separators (comma/newline), shortDOI expansion, the exact behavior of each format enum, and the interaction between style, lang, and format. This exceeds what the schema alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Export scholarly identifiers to a bibliography file format...'. It explicitly lists the target use cases (Zotero, Mendeley, EndNote, etc.) and names sibling tools (formatCitation, resolveIdentifier) that serve different needs, leaving no ambiguity about what this tool does.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear when-to-use guidance ('Use when the user wants a file...'), specifies which formats map to which reference managers, and explicitly contrasts with alternatives ('Use formatCitation instead...'). It also covers batching, API key tiers, and rate-limit behavior, so the agent knows exactly when and how to select this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

formatCitationFormat CitationA
Read-onlyIdempotent
Inspect

Format 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
langNoBCP-47 locale tag for formatting (e.g. 'en-US', 'en-GB', 'fr-FR'). Defaults to the locale embedded in the chosen CSL style, typically en-US.
textYesOne or more scholarly identifiers to process — DOI (with or without https://doi.org/; a shortDOI alias such as 10/aabbe is also accepted and expanded to the full DOI), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip.
styleNoCitation style: 'vancouver' (default), 'ama', 'apa', 'ieee', 'cse', or any of 10,000+ CSL style IDs from citation-style-language/styles (e.g. 'chicago-author-date', 'harvard-cite-them-right', 'modern-language-association', 'nature', 'bmj', 'the-lancet'). Aliases and dependent styles resolve automatically — 'harvard' → 'harvard-cite-them-right'.
outputNoOutput format: 'text' (plain text, default), 'html' (marked-up HTML for web rendering), or 'json' (structured CSL items, equivalent to resolveIdentifier).
footnoteNoWhen true, render as a footnote/note-style citation rather than a bibliography entry. Only meaningful for note-style CSL styles (chicago-note-bibliography, turabian-fullnote-bibliography); ignored by author-date and numeric styles.

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already carry readOnlyHint, idempotentHint, and destructiveHint=false; the description confirms these ('Read-only and idempotent — safe to retry') and adds substantial context beyond them: vancouver defaulting with an explicit ask-before-defaulting policy, alias resolution reporting styleUsed, batch processing in one round trip, the metadata block appended as a second text content item, rate-limit tiering, and API-key auth requirements (SCHOLAR_API_KEY, RAPIDAPI_KEY). No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long (~230 words) but dense — nearly every sentence carries operational information an agent needs (defaults, auth, return shape, sibling routing). It is front-loaded with purpose and usage before diving into details. Slight redundancy exists (identifier formats partially echoed in the schema's text parameter description), but no filler sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description fully specifies the return shape ('one of { text, html, items } depending on the output parameter, followed by a metadata block... appended as a second text content item') and tells the agent to surface it for reproducibility. It covers auth setup, rate-limit behavior, batch semantics, defaults, and all sibling tool boundaries — nothing an agent needs to call this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3; the description adds value on top by disclosing default behavior (vancouver if unspecified), the disambiguation instruction when style is ambiguous, alias resolution semantics ('harvard' → 'harvard-cite-them-right'), and the output default of text. It also cross-references resolveIdentifier for identifier formats instead of redundantly repeating them, which is efficient enrichment rather than restatement.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb+resource+outcome: 'Format scholarly identifiers into a finished citation in a specific style.' It then explicitly distinguishes itself from siblings — resolveIdentifier (raw metadata) and exportCitation (downloadable bibliography file) — so an agent can tell them apart without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States exactly when to use it ('Use when the user wants a paste-ready citation string for a manuscript, slide, message, footnote, or in-line reference') and names the alternatives with their selection conditions ('Use resolveIdentifier instead when the user wants raw metadata to inspect or transform; use exportCitation when they want a downloadable bibliography file'). It even adds an ask-the-user rule for ambiguous style variants, which is actionable usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resolveIdentifierResolve IdentifierA
Read-onlyIdempotent
Inspect

Resolve 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
textYesOne or more scholarly identifiers to process — DOI (with or without https://doi.org/; a shortDOI alias such as 10/aabbe is also accepted and expanded to the full DOI), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip.

TDQS

A4.9/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, and the description reinforces them with 'Read-only and idempotent — safe to retry.' It then goes beyond the annotations by disclosing authentication options (anonymous free tier, SCHOLAR_API_KEY, RAPIDAPI_KEY), rate-limit behavior, and server-side caching surfaced via x-scholar-cache header. This is rich behavioral context the agent would not otherwise know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is long but tightly packed: every sentence carries distinct information—purpose, usage triggers, accepted formats, output shape, alternatives, safety, auth, and rate limits. It is front-loaded with the most decision-relevant facts and avoids filler or tautology.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite having no output schema, the description fully specifies the return format (JSON array of CSL items with listed fields). It also covers identifier variants, prefixes, batch handling, auth, rate limiting, and sibling routing. Nothing an agent needs to invoke this tool correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents the text parameter thoroughly. The description adds value with concrete conversion examples (PMID → PMCID, arXiv → DOI, ISBN → CSL JSON) and clarifies that a batch resolves in one round trip, which aids interpretation beyond the schema's formal listing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Resolve scholarly identifiers to structured CSL JSON metadata.' It enumerates accepted identifier types and names the two most relevant sibling alternatives (formatCitation, exportCitation) to disambiguate. An agent can immediately understand what the tool does and how it differs from the other rendering-oriented siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is front-loaded: 'Use when the user wants raw bibliographic data to inspect, transform, or feed into another tool — not a formatted citation.' It also states when not to use it, naming formatCitation and exportCitation as alternatives. The batch behavior and single-round-trip claim give operational clarity.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

verifyCitationVerify CitationA
Read-onlyIdempotent
Inspect

Verify 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 semanticTitle: true (any tier) to add a semantic same-work check that catches one-word title swaps string similarity misses (a flagged match becomes 'ambiguous' for review, never 'mismatch'; not byte-deterministic). 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: , mismatches: [{field, claimed, resolved, similarity}], candidates: [{item, registries, score}] (when title-search ran), provenance: {stages_run, resolved_via, registries_searched, llm_screen, semantic_title} }. 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.

ParametersJSON Schema
NameRequiredDescriptionDefault
adsNoNASA ADS bibcode (19 chars).
doiNoDOI as cited (with or without https://doi.org/ prefix; a shortDOI alias such as 10/aabbe is accepted here too and expanded to the full DOI). Provide whichever identifier(s) the cited reference carries; the verifier uses the first one in priority order doi > pmid > pmcid > arxiv > ads > isbn > issn > whoIrisUrl.
isbnNoISBN (10- or 13-digit, hyphens tolerated).
issnNoISSN for journal-level resolution.
pmidNoPubMed ID as cited (digits only, or with 'PMID:' prefix).
yearNoPublication year as cited. Wrong year alone does not flip the verdict, but >=2-year gap from the resolved record lowers confidence.
arxivNoarXiv ID (e.g. '2301.08745' or 'arXiv:2301.08745'; old-style 'hep-ph/0501023' accepted).
pmcidNoPubMed Central ID (e.g. 'PMC1234567' or 'PMCID:1234567').
titleYesThe title as it appears in the cited reference. This is the field the verifier cross-checks against the resolved record at the supplied identifier. Required.
authorNoFirst-author family name as cited. Refines the verdict — a title-vs-resolved-title match plus an author mismatch raises suspicion of fabrication. Pass only the family name (e.g. 'Topaz', not 'Topaz, Maxim').
containerNoJournal or container name as cited (e.g. 'The Lancet', 'Neuroscience'). Soft signal — surfaced as a mismatch field but does not gate the verdict.
whoIrisUrlNoWHO IRIS URL (https://iris.who.int/...).
screenWithLlmNoOpt-in Stage 3 LLM screen. Fires only when the pre-LLM verdict is mismatch with low confidence (the informal-abbreviation false-positive bucket). Gated: requires an authenticated first-party API key or a paid RapidAPI tier; anonymous / free callers receive 400 LLM_SCREEN_FORBIDDEN. Default false.
semanticTitleNoOpt-in semantic title check (any tier, no key needed). On a string-level matched verdict, a calibrated model judges whether the claimed and resolved titles describe the same work and whether a word in one reverses the other; catches one-word swaps in long titles that string similarity misses. A flagged title moves matched → ambiguous (review), never mismatch. Not byte-deterministic — _provenance.semantic_title carries the probabilities. Default false.

TDQS

A4.6/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover safety (readOnly, idempotent, non-destructive) but the description adds substantial context beyond them: anonymous vs authenticated paths, the 400 LLM_SCREEN_FORBIDDEN gate, rate-limit benefits of SCHOLAR_API_KEY, non-determinism of semanticTitle, and full verdict semantics. This is richer than the annotations alone.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core purpose and the Topaz fabrication pattern before details. It is long and dense, but nearly every sentence (verdict semantics, provenance fields, auth gating) carries information an agent needs; minor redundancy in restating return fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description enumerates the return shape (verdict, confidence, matched, mismatches, candidates, _provenance) and defines each verdict value. Combined with auth and error-code disclosure, an agent has everything needed to call and interpret this 14-parameter tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented in the schema, including the identifier priority order. The description adds the 'exactly one identifier' constraint and the role of optional refinements, but largely restates what the schema already carries. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Verify a claimed citation against the resolved record at its identifier') and immediately names the failure mode it targets. It also explicitly distinguishes itself from the sibling resolveIdentifier, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit trigger ('when the user pastes a citation and asks is this real? or check this DOI'), states the input contract (title plus exactly one identifier), and names the non-overlapping alternative (resolveIdentifier). When-to-use and when-not-to-use are both covered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.8.13
    • ChangedauditBibliography1 field changed
      • addedInput schema / properties / semanticTitle
        Added value: +{
+  "description": "Opt-in semantic title check applied per entry (any tier; see verifyCitation). Default false.",
+  "type": "boolean"
+}
    • ChangedverifyCitation1 field changed
      • addedInput schema / properties / semanticTitle
        Added value: +{
+  "description": "Opt-in semantic title check (any tier, no key needed). On a string-level matched verdict, a calibrated model judges whether the claimed and resolved titles describe the same work and whether a word in one reverses the other; catches one-word swaps in long titles that string similarity misses. A flagged title moves matched → ambiguous (review), never mismatch. Not byte-deterministic — _provenance.semantic_title carries the probabilities. Default false.",
+  "type": "boolean"
+}
  2. 7 tool updatesv0.8.11
    • ChangedauditBibliography12 fields changed
      • addedInput schema / properties / claims / items / properties / ads / description
        Added value: +"NASA ADS bibcode, e.g. '2019A&A...625A.135L'."
      • addedInput schema / properties / claims / items / properties / arxiv / description
        Added value: +"arXiv ID, e.g. '2301.00001' or 'arXiv:2301.00001'."
      • changedInput schema / properties / claims / items / properties / author / description
        Previous value: -"First-author family name as cited."New value: +"First-author family name as cited. Refines the comparison; a disagreement here can downgrade a verdict to 'ambiguous'."
      • addedInput schema / properties / claims / items / properties / container / description
        Added value: +"Journal or book title as cited. Refinement only, same role as `year`."
      • addedInput schema / properties / claims / items / properties / doi / description
        Added value: +"DOI as cited, with or without a prefix ('10.1038/nphys1170' or a doi.org URL)."
      • addedInput schema / properties / claims / items / properties / isbn / description
        Added value: +"ISBN-10 or ISBN-13; hyphens are tolerated."
      • addedInput schema / properties / claims / items / properties / issn / description
        Added value: +"ISSN of the containing journal. Identifies a container, not a paper, so it cannot resolve an entry on its own — supply it alongside another identifier."
      • addedInput schema / properties / claims / items / properties / pmcid / description
        Added value: +"PubMed Central ID, e.g. 'PMC1234567'."
      • addedInput schema / properties / claims / items / properties / pmid / description
        Added value: +"PubMed ID, digits only or 'PMID:' prefixed."
      • changedInput schema / properties / claims / items / properties / title / description
        Previous value: -"Title as cited. Required for each claim."New value: +"Title exactly as the citation claims it. Required — the audit compares this against the title of the record the identifier actually resolves to, and that comparison is the fabrication check."
      • addedInput schema / properties / claims / items / properties / whoIrisUrl / description
        Added value: +"WHO IRIS publication URL."
      • addedInput schema / properties / claims / items / properties / year / description
        Added value: +"Publication year as cited. Refinement only — it never decides a verdict alone."
    • ChangedcheckOpenAccess1 field changed
      • changedInput schema / properties / id / description
        Previous value: -"A single scholarly identifier to check. 1–500 characters. Non-DOI inputs are resolved to a DOI server-side before the lookup; if no DOI can be derived, the tool returns doi=null with reason='no_doi'. Pass exactly one identifier — comma/newline batches are NOT accepted by this tool; loop one call per identifier for multiple papers. Accepted: DOI, PMID, PMCID, arXiv ID, ISBN, or NASA ADS bibcode (with or without prefixes)."New value: +"A single scholarly identifier to check. 1–500 characters. Non-DOI inputs are resolved to a DOI server-side before the lookup; if no DOI can be derived, the tool returns doi=null with reason='no_doi'. Pass exactly one identifier — comma/newline batches are NOT accepted by this tool; loop one call per identifier for multiple papers. Accepted: DOI (including a shortDOI alias such as 10/aabbe), PMID, PMCID, arXiv ID, ISBN, or NASA ADS bibcode (with or without prefixes)."
    • ChangedcheckRetraction1 field changed
      • changedInput schema / properties / id / description
        Previous value: -"A single scholarly identifier to check. 1–500 characters. Non-DOI inputs are resolved to a DOI server-side before the lookup; if no DOI can be derived, the tool returns doi=null with reason='no_doi'. Pass exactly one identifier — comma/newline batches are NOT accepted by this tool; loop one call per identifier for multiple papers. Accepted: DOI, PMID, PMCID, arXiv ID, or NASA ADS bibcode (with or without prefixes). ISBN inputs are accepted but always return doi=null since books are not in the retraction graph."New value: +"A single scholarly identifier to check. 1–500 characters. Non-DOI inputs are resolved to a DOI server-side before the lookup; if no DOI can be derived, the tool returns doi=null with reason='no_doi'. Pass exactly one identifier — comma/newline batches are NOT accepted by this tool; loop one call per identifier for multiple papers. Accepted: DOI (including a shortDOI alias such as 10/aabbe), PMID, PMCID, arXiv ID, or NASA ADS bibcode (with or without prefixes). ISBN inputs are accepted but always return doi=null since books are not in the retraction graph."
    • ChangedexportCitation1 field changed
      • changedInput schema / properties / text / description
        Previous value: -"One or more scholarly identifiers to process — DOI (with or without https://doi.org/), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip."New value: +"One or more scholarly identifiers to process — DOI (with or without https://doi.org/; a shortDOI alias such as 10/aabbe is also accepted and expanded to the full DOI), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip."
    • ChangedformatCitation1 field changed
      • changedInput schema / properties / text / description
        Previous value: -"One or more scholarly identifiers to process — DOI (with or without https://doi.org/), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip."New value: +"One or more scholarly identifiers to process — DOI (with or without https://doi.org/; a shortDOI alias such as 10/aabbe is also accepted and expanded to the full DOI), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip."
    • ChangedresolveIdentifier1 field changed
      • changedInput schema / properties / text / description
        Previous value: -"One or more scholarly identifiers to process — DOI (with or without https://doi.org/), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip."New value: +"One or more scholarly identifiers to process — DOI (with or without https://doi.org/; a shortDOI alias such as 10/aabbe is also accepted and expanded to the full DOI), PMID (with or without 'PMID:' prefix), PMCID (e.g. PMC7793608), ISBN (10 or 13 digit, hyphens tolerated), arXiv ID (with or without 'arXiv:' prefix; old-style hep-ph/0501023 also accepted), ISSN, NASA ADS bibcode (19 chars), or WHO IRIS URL. Pass identifiers verbatim — do not strip prefixes. Multiple identifiers may be separated by newlines or commas; mixed types in one batch are supported and resolved in a single round trip."
    • ChangedverifyCitation1 field changed
      • changedInput schema / properties / doi / description
        Previous value: -"DOI as cited (with or without https://doi.org/ prefix). Provide whichever identifier(s) the cited reference carries; the verifier uses the first one in priority order doi > pmid > pmcid > arxiv > ads > isbn > issn > whoIrisUrl."New value: +"DOI as cited (with or without https://doi.org/ prefix; a shortDOI alias such as 10/aabbe is accepted here too and expanded to the full DOI). Provide whichever identifier(s) the cited reference carries; the verifier uses the first one in priority order doi > pmid > pmcid > arxiv > ads > isbn > issn > whoIrisUrl."
  3. 7 tool updatesv0.8.3
    • AddedauditBibliography
    • ChangedcheckOpenAccess1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • ChangedcheckRetraction1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • ChangedexportCitation1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • ChangedformatCitation1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • ChangedresolveIdentifier1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
    • ChangedverifyCitation1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
  4. 6 tool updatesv0.7.3
    • AddedcheckOpenAccess
    • AddedcheckRetraction
    • AddedexportCitation
    • AddedformatCitation
    • AddedresolveIdentifier
    • AddedverifyCitation
  5. 6 tool updatesv0.7.1
    • RemovedcheckOpenAccess
    • RemovedcheckRetraction
    • RemovedexportCitation
    • RemovedformatCitation
    • RemovedresolveIdentifier
    • RemovedverifyCitation
  6. 6 tool updatesv0.7.0
    • AddedcheckOpenAccess
    • AddedcheckRetraction
    • AddedexportCitation
    • AddedformatCitation
    • AddedresolveIdentifier
    • AddedverifyCitation
  7. 3 tool updatesv0.6.1
    • RemovedexportCitation
    • RemovedformatCitation
    • RemovedresolveIdentifier
  8. 3 tool updatesv0.3.4
    • First observedexportCitation
    • First observedformatCitation
    • First observedresolveIdentifier
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.6/5.0

Scored across 7 tools

Disambiguation4/5

Each tool has a clearly distinct core purpose (single vs batch fabrication check, retraction, OA status, and three output forms of identifier resolution), and the descriptions explicitly cross-reference siblings to delineate boundaries. The only minor friction is between formatCitation and exportCitation with format=txt, which both produce a plain formatted citation string.

Naming Consistency5/5

All seven tools use a consistent camelCase verb_noun pattern: verifyCitation, auditBibliography, checkRetraction, checkOpenAccess, resolveIdentifier, formatCitation, exportCitation. There are no mixed conventions or vague verb choices.

Tool Count5/5

Seven tools is well-scoped: verification (single + batch), retraction, open access, resolution, and two output formats. Each tool earns its place with little redundancy for the citation/identifier domain.

Completeness4/5

The surface covers the citation lifecycle well: fabrication verification, retraction, OA lookup, metadata resolution, formatting, and export, with single/batch variants for the core checks. Minor gaps remain, such as no title-based discovery/search tool and no batch mode for checkRetraction/checkOpenAccess (must loop), though auditBibliography mitigates the batch retraction case.

Maintenance

ActivityMaintained
ResponsivenessUnresponsive

Resources

Related MCP Connectors

Related MCP Servers

  • cite-mcp

    ndchikin
    A
    license
    B
    quality
    D
    maintenance
    Retrieve citation data effortlessly from CiteAs and Google Scholar. Get BibTeX-formatted citations for your resources with just a few commands. Enhance your research workflow by integrating citation retrieval directly into your applications.
    2
    14
    MIT

  • genpark-canonical-doi-bibtex

    alphaparkinc
    F
    license
    Not graded
    quality
    B
    maintenance
    Enables resolving academic DOIs to canonical identifiers and generating BibTeX records via CrossRef, and can be integrated into MCP-compliant clients for automated research workflows.
    8
    -

  • mcp-crossref

    algonacci
    A
    license
    A
    quality
    C
    maintenance
    Enables searching roughly 170 million scholarly works and resolving DOIs into normalized metadata, complete with citation formatting in any style, reference and citing-work snowballing, and author, journal, funder and topic profiles. It also extracts and verifies DOIs from messy text and exports bibliographies as BibTeX, RIS or CSL-JSON.
    11
    MIT