Skip to main content
Glama
mlava

Scholar Sidekick

by mlava
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Check Retraction

checkRetraction
Read-onlyIdempotent

Verify whether a scholarly paper has been retracted, corrected, or flagged with an expression of concern before citing it. Resolves DOI, PMID, PMCID, arXiv, or ADS to check Crossref notices.

Instructions

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.

Input Schema

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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.8.11
    • 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."
  2. Changed1 schema field changedv0.8.3
    • addedInput schema / additionalProperties
      Added value: +false
  3. Addedv0.7.3
  4. Removedv0.7.1
  5. Addedv0.7.0

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.

Deploy Server

Other Tools