F
licenseNot graded
qualityC
maintenanceFabrication-free, DOI-backed citations for AI content and agents, using openAlex public-domain data with resolvable DOIs. Includes an API and planned MCP server for agent-native citation retrieval.
-
Scholar Sidekick
Server Details
Catch AI-fabricated citations (real DOI + fake title). Retraction, open-access, 10,000+ CSL styles.
Ownership verified
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- mlava/scholar-sidekick-mcp
- GitHub Stars
- 8
- Server Listing
- Scholar Sidekick
Available Tools
7 toolsauditBibliographyAudit BibliographyARead-onlyIdempotentInspect
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); 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
| Name | Required | Description | Default |
|---|---|---|---|
| checks | No | Per-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 the retraction lookup. | |
| claims | No | Pre-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. | |
| format | No | Override format auto-detection for `bibliography`. | |
| bibliography | No | Raw bibliography text to parse and audit — BibTeX, RIS, or CSL-JSON. Provide EITHER this or `claims`, not both. Format is auto-detected from the content; override with `format`. Capped at 25 entries per call (excess is dropped and reported via `truncated`). | |
| screenWithLlm | No | Opt-in Stage 3 LLM screen applied per entry (same gating as verifyCitation: authenticated first-party key or paid RapidAPI tier). Default false. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| format | No | Detected input format ('bibtex' | 'ris' | 'csl-json'), or null for the claims[] path. |
| entries | No | One result per verifiable entry: { index, sourceKey?, status: 'ok'|'error', verdict, confidence, matched, mismatches, retraction, _provenance }. `index` is 1-BASED and counts position in the submitted input, so entry 1 is the first reference — do not add 1 again when you report it to a user. `sourceKey` is the entry's own key in the source file (BibTeX cite key, RIS `ID`, or CSL-JSON `id`) and is the reliable way to map a verdict back to the user's bibliography; it is absent on the claims[] path and on formats that carry no key. `status:'error'` means that one entry failed to verify, not that the batch failed. Entries appear in input order. |
| summary | No | Corpus roll-up: { total, matched, mismatch, ambiguous, not_found, errored, retracted }. `total` counts verifiable entries only, so it excludes `parseErrors` and anything past the cap. `retracted` is a separate axis from the verdict counts, and an entry can be both matched and retracted — never add the fields together. |
| truncated | No | Count of entries dropped beyond the 25-entry cap. Non-zero means the audit is incomplete — split the bibliography and call again for the rest. |
| parseErrors | No | Entries that could not be parsed or lacked a title: { index, error, message }. Same 1-based `index` space as `entries`, so the two arrays never collide: a given input position appears in exactly one of them. Report these to the user as unchecked, NOT as clean. |
TDQS
A4.8/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent annotations, the description reveals batch semantics (25 cap, dropped excess reported via truncated), per-entry leniency (one error doesn't fail the batch), index space semantics (entries and parseErrors share one index space), 1-based indexing, how to interpret summary fields, and the fact that reads are anonymous without keys. This is behavioral transparency far beyond what annotations already provide; it clarifies the return shape and edge cases.
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 dense and packed with value; nearly every sentence earns its place. It is longer than a typical MCP description, but given the complexity (two input modes, 25-entry cap, complex return semantics, read-only auth notes) the length is justified. It is front-loaded with the core purpose, then use cases, then semantics. Minor deduction for being quite long overall, which risks token cost, though no sentence is redundant.
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 output schema exists, the description explains the crucial interpretation details an agent will need: 1-based index, sourceKey, shared index space with parseErrors, summary field semantics, truncation meaning, and identity-vs-support distinction. It covers prerequisites (auth key for LLM screen), scope limits, and what the tool does not check. For a batch tool with this complexity, the description is exceptionally complete.
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% with rich per-parameter descriptions, so the baseline is 3 per the rubric. The description adds orientation about mutually exclusive inputs (EITHER bibliography OR claims, not both), default for checks, cap semantics, and the role of screenWithLlm relative to verifyCitation. It does not duplicate the schema's parameter definitions, but it adds integration-level meaning. Slightly below a 5 because it still relies on the schema for field-level detail, but it adds real value beyond schema.
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 'Verify a WHOLE bibliography in one call — the batch counterpart to verifyCitation' and makes clear it runs fabrication checks plus retraction lookups. This distinguishes it from sibling tools and names the specific use case. It also explains what it does not do (does not check whether a source supports the claim) which prevents misuse.
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 explicitly tells when to use this tool vs alternatives ('Use when the user pastes a reference list, a .bib / .ris file, or asks to...') and names verifyCitation as the per-single citation counterpart. It gives routing rules for input variants, cap limit behavior, and even mentions 'split the bibliography and call again' for truncation. This is exemplary usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
checkOpenAccessCheck Open AccessARead-onlyIdempotentInspect
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'. arXiv inputs check the linked published-journal DOI when arXiv records one; a preprint without one returns doi=null and reason='no_doi' (Unpaywall does not index arXiv preprints, which are freely readable on arXiv regardless). 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
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 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). |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| doi | Yes | |
| reason | No | |
| result | Yes | Open-access status, or null when no DOI resolved. |
| resolvedFrom | No |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral detail: DOI resolution behavior, doi=null and reason='no_doi' failure modes, arXiv special-case handling, Unpaywall as the data source, server-side caching, rate limits, and API key options. This goes well beyond what annotations provide and paints a complete picture of the tool's runtime behavior.
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 dense but every sentence earns its place: purpose, usage triggers, source, resolution behavior, failure modes, batching constraint, return shape, sibling differentiation, safety hints, and authentication all serve a distinct purpose. The most decision-relevant information (what and when) is front-loaded before the lower-level API details.
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 one parameter, an output schema, and rich annotations, the description is exceptionally complete. It covers intended use, input constraints, resolution edge cases, return structure, failure behavior, authentication, rate limits, and sibling relationship. An agent has everything needed to select and call this tool correctly, and nothing important is left to inference.
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% and the schema's id description already documents accepted ID types and the no-batch rule. The description reinforces and expands this by explaining resolution semantics, the arXiv exception, and the loop-one-call-per-identifier guidance. This adds genuine meaning beyond the schema, though the schema already carried most of the parameter burden.
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 where to find the best legal version.' It also explicitly differentiates from siblings by stating 'No sibling tool overlaps this — resolveIdentifier returns metadata but not OA status.' This clearly distinguishes the tool from the other identifier-related tools.
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 a use case (OA license/version before reusing). It also states when not to use it (single identifier per call, no batches, loop for multiple papers) and names the closest sibling alternative that does NOT overlap. This leaves no ambiguity about when to invoke the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
checkRetractionCheck RetractionARead-onlyIdempotentInspect
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). 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. arXiv inputs check the linked published-journal DOI when arXiv records one; a preprint without one returns doi=null and reason='no_doi' (preprints are outside the Crossref retraction graph — arXiv marks withdrawals on the abstract page instead). 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, label, doi, date, source} where type is a raw Crossref update type such as 'retraction', 'correction', 'erratum' or 'expression_of_concern'), 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.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | 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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| doi | Yes | Resolved DOI, or null when none could be derived. |
| reason | No | Why result is null (e.g. 'no_doi'). |
| result | Yes | Retraction status, or null when no DOI resolved. |
| resolvedFrom | No |
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 and expands on them with concrete behavioral details: source is Crossref updated-by mirroring Retraction Watch, DOI/PMID/PMCID/arXiv/ADS resolution behavior, ISBN always returning no_doi, arXiv preprint handling, return shape, and rate-limit/auth behavior. 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 appropriately front-loaded with purpose and use cases, and nearly every sentence adds value. It loses a point due to noticeable redundancy around batch rejection and looping, which appears twice in close proximity.
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 one identifier parameter and a defined output schema, the description covers all important operational context: ID resolution, edge cases, return structure, null/reason behavior, authentication options, rate limits, and idempotency. Nothing critical is missing for an agent to invoke it correctly.
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 coverage is 100%, yet the description still adds meaningful semantics beyond the schema: accepted identifier types, the deliberate rejection of batch input, ISBN behavior, and the resolution-to-DOI flow. This materially helps an agent form correct single-identifier calls.
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 has been retracted, corrected, or had an expression of concern raised.' It clearly distinguishes the tool from resolveIdentifier by stating that resolveIdentifier returns metadata but not retraction 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 explicit when-to-use guidance: user asks about retraction or wants to verify standing before citing. It also gives explicit exclusions: batch input is rejected, and multi-paper audits must loop one call per identifier, with resolveIdentifier named as a non-overlapping alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
exportCitationExport CitationARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Locale for formatting (e.g. en-US) | |
| text | Yes | One or more identifiers (DOIs, PMIDs, ISBNs, etc.) separated by newlines or commas | |
| style | No | Citation style (used only for txt export) | |
| format | Yes | Export format |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| format | Yes | The export format that was produced. |
| content | Yes | The entire bibliography in the requested format, as one string. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds substantial context: auth requirements (SCHOLAR_API_KEY, RAPIDAPI_KEY), rate limits, anonymous access, retry safety, and format-specific behavior (txt uses style; others ignore it). This goes well beyond the annotations.
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 provides necessary information: purpose, use cases, format semantics, identifier handling, return shape, alternatives, safety, auth, and rate limits. It is logically ordered and free of fluff, earning its length.
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 complexity (10 formats, 4 params, auth, alternatives), the description covers all bases: input formats, return shape, alternative tools, rate limits, and API keys. It is even self-contained enough to guide an agent without needing to inspect the schema or output schema.
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?
Although schema coverage is 100%, the description enriches each parameter. It explains every format enum value with use cases (BibTeX for LaTeX, RIS for reference managers, NBIB for PubMed), clarifies that style only applies to txt, and details the identifier formats accepted for the text parameter. This adds significant meaning beyond the schema.
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+resource: 'Export scholarly identifiers to a bibliography file format'. It clearly distinguishes from siblings by stating when to use exportCitation (file generation) vs. formatCitation (in-line text) and resolveIdentifier (raw metadata).
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?
Provides explicit when-to-use guidance: 'Use when the user wants a file (.bib, .ris, .nbib, .xml, .rdf, .csv) for Zotero, Mendeley, EndNote...'. Also explicitly names alternatives: 'Use formatCitation instead when the user wants in-line citation text; use resolveIdentifier when they want raw structured metadata.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
formatCitationFormat CitationARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | Locale for formatting (e.g. en-US, en-GB, fr-FR) | |
| text | Yes | One or more identifiers (DOIs, PMIDs, ISBNs, arXiv IDs, etc.) separated by newlines or commas | |
| style | No | Citation style: vancouver (default), ama, apa, ieee, cse, or any CSL style ID | |
| output | No | Output format (default: text) | |
| footnote | No | Format as footnotes instead of bibliography entries |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| html | No | Formatted citation HTML (when output=html). |
| lang | No | Locale used for formatting. |
| text | No | Formatted citation text (when output=text). |
| items | No | Structured CSL items (when output=json). |
| warnings | No | |
| formatter | No | Which engine formatted: 'builtin' or 'csl'. |
| styleUsed | No | Canonical style ID after alias/dependent-style resolution. |
TDQS
A5/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the annotations: it details read-only/idempotent behavior, rate limits, API key requirements, output format semantics, metadata block structure, and style resolution (e.g., 'harvard' resolves to 'harvard-cite-them-right'). No contradictions 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is lengthy but every sentence carries essential information, with the purpose and usage front-loaded. It avoids redundancy and organizes complex details (style resolution, output formats, rate limits) into a coherent flow without waste.
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 (5 parameters, output schema, many alternatives, and nuanced behavior), the description covers all aspects: return structure (text/html/items + metadata block), authentication tiers, rate limiting, style resolution, batch processing, and when-to-use alternatives. It is exceptionally complete.
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?
Although the schema already covers all parameters at 100%, the description adds substantial meaning: style defaults, builtins vs. CSL, alias resolution, batch input format (newline/comma separated, one round trip), and the output parameter returning text/html/items. It enriches every parameter beyond schema definitions.
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 clearly states the tool formats scholarly identifiers into a finished citation with a specific style. It distinguishes from siblings by contrasting with resolveIdentifier (raw metadata) and exportCitation (bibliography file), making its unique purpose unambiguous.
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?
It provides explicit use cases ('paste-ready citation string for a manuscript, slide, message, footnote, or in-line reference'), explicit alternatives, and even warns about style ambiguity ('Harvard' and 'Chicago' variants) requiring user confirmation before defaulting. This is exemplary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
resolveIdentifierResolve IdentifierARead-onlyIdempotentInspect
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
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | One or more identifiers to resolve (DOIs, PMIDs, PMCIDs, ISBNs, arXiv IDs, ISSNs, ADS bibcodes) separated by newlines or commas |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| items | Yes | Resolved CSL JSON items, one per identifier. |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description discloses operationally significant behaviors: authentication options (SCHOLAR_API_KEY, RAPIDAPI_KEY), rate-limit tiers, REST API caching with x-scholar-cache response header, and the ability to batch requests in one round trip. This adds substantial value over the structured annotations.
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 dense but well-structured: purpose first, usage examples, output summary, alternatives, safety, and API details. Every sentence carries operational weight, and the front-loaded purpose sentence makes the tool's function immediately clear. Length is justified by the tool's complexity.
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 breadth (multiple identifier types, batching, API keys, and output schema), the description is remarkably complete. It covers purpose, usage, alternatives, auth, rate limits, caching, and output format without redundant explanation of return values (output schema exists). It positions the tool well relative to its siblings.
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 covers the 'text' parameter with 100% coverage, but the description enriches it by enumerating additional identifier types (WHO IRIS URL), prefix handling (PMID:, arXiv:, ISBN hyphens, https://doi.org/...), and batch semantics (comma/newline-separated, one round trip per call). This goes beyond the schema's basic listing of identifier kinds.
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 states a specific verb+resource+output: 'Resolve scholarly identifiers to structured CSL JSON metadata (title, authors, journal, year, identifiers).' It also distinguishes from siblings by explicitly naming formatCitation and exportCitation as alternatives, making the tool's purpose unmistakable.
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 provides explicit use cases: 'Use when the user wants raw bibliographic data to inspect, transform, or feed into another tool — not a formatted citation.' It also gives clear exclusions and alternatives: 'Use formatCitation instead when the user wants a finished citation string in a specific style; use exportCitation when they want a downloadable bibliography file.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
verifyCitationVerify CitationARead-onlyIdempotentInspect
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 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} }. 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
| Name | Required | Description | Default |
|---|---|---|---|
| ads | No | NASA ADS bibcode (19 chars). | |
| doi | No | 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. | |
| isbn | No | ISBN (10- or 13-digit, hyphens tolerated). | |
| issn | No | ISSN for journal-level resolution. | |
| pmid | No | PubMed ID as cited (digits only, or with 'PMID:' prefix). | |
| year | No | Publication year as cited. Wrong year alone does not flip the verdict, but >=2-year gap from the resolved record lowers confidence. | |
| arxiv | No | arXiv ID (e.g. '2301.08745' or 'arXiv:2301.08745'; old-style 'hep-ph/0501023' accepted). | |
| pmcid | No | PubMed Central ID (e.g. 'PMC1234567' or 'PMCID:1234567'). | |
| title | Yes | The 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. | |
| author | No | First-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'). | |
| container | No | Journal or container name as cited (e.g. 'The Lancet', 'Neuroscience'). Soft signal — surfaced as a mismatch field but does not gate the verdict. | |
| whoIrisUrl | No | WHO IRIS URL (https://iris.who.int/...). | |
| screenWithLlm | No | Opt-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. |
Output Schema
ParametersJSON Schema
| Name | Required | Description |
|---|---|---|
| matched | No | The resolved record at the identifier, or null on not_found. |
| verdict | No | |
| candidates | No | |
| confidence | No | |
| mismatches | No | |
| _provenance | No |
TDQS
A4.9/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, and the description reinforces those traits with 'Read-only and idempotent — safe to retry.' It adds substantial context: the Topaz fabrication pattern, verdict semantics, auth gating for LLM screen (400 LLM_SCREEN_FORBIDDEN for anonymous callers), and rate-limit note. These details go well beyond the annotations and meaningfully inform the agent of real-world behavior.
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 front-loaded: the first sentence states the core purpose. Every subsequent sentence adds unique information—detection pattern, usage triggers, parameter rules, LLM gating, return structure, verdict semantics, sibling differentiation, safety. No word is wasted; it is an appropriately sized, information-dense reference.
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 (13 parameters, multiple identifiers, gated LLM screen), the description is remarkably complete. It explains the full return object, every verdict meaning with example subtypes, authentication requirements, error codes, and idempotency. The output schema exists but is not shown in this definition; the description compensates fully by documenting the return structure and semantics.
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 description coverage is 100%, so the schema already documents every parameter baseline. The description adds value by clarifying the identifier priority order, the requirement of 'title plus exactly one identifier' (even though the schema only marks title as required), the soft-signal nature of container, and the gating of screenWithLlm. This is genuinely helpful, but not exceptional since many parameter details are already in the schema descriptions.
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+resource: 'Verify a claimed citation against the resolved record at its identifier.' It immediately identifies the dominant AI-driven fabrication pattern and clearly distinguishes itself from resolveIdentifier by stating it is the only tool that cross-checks claimed title vs resolved metadata. This is unambiguous and differentiates from 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 use-case guidance is provided: 'Use when the user pastes a citation and asks "is this real?" or "check this DOI".' It also states single citation per call, required fields, and explicitly names the alternative tool (resolveIdentifier) for known-good identifiers. The LLM screen usage and authentication requirements are clearly described, leaving no ambiguity about when to invoke this versus siblings.
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. Dates show when Glama detected each change.
1 tool update
- Changed
auditBibliography16 fields changed- added
Input schema / properties / claims / items / properties / ads / descriptionAdded value: +"NASA ADS bibcode, e.g. '2019A&A...625A.135L'." - added
Input schema / properties / claims / items / properties / arxiv / descriptionAdded value: +"arXiv ID, e.g. '2301.00001' or 'arXiv:2301.00001'." - changed
Input schema / properties / claims / items / properties / author / descriptionPrevious 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'." - added
Input schema / properties / claims / items / properties / container / descriptionAdded value: +"Journal or book title as cited. Refinement only, same role as `year`." - added
Input schema / properties / claims / items / properties / doi / descriptionAdded value: +"DOI as cited, with or without a prefix ('10.1038/nphys1170' or a doi.org URL)." - added
Input schema / properties / claims / items / properties / isbn / descriptionAdded value: +"ISBN-10 or ISBN-13; hyphens are tolerated." - added
Input schema / properties / claims / items / properties / issn / descriptionAdded 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." - added
Input schema / properties / claims / items / properties / pmcid / descriptionAdded value: +"PubMed Central ID, e.g. 'PMC1234567'." - added
Input schema / properties / claims / items / properties / pmid / descriptionAdded value: +"PubMed ID, digits only or 'PMID:' prefixed." - changed
Input schema / properties / claims / items / properties / title / descriptionPrevious 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." - added
Input schema / properties / claims / items / properties / whoIrisUrl / descriptionAdded value: +"WHO IRIS publication URL." - added
Input schema / properties / claims / items / properties / year / descriptionAdded value: +"Publication year as cited. Refinement only — it never decides a verdict alone." - changed
Output schema / properties / entries / descriptionPrevious value: -"One result per verifiable entry: { index, sourceKey?, status: 'ok'|'error', verdict, confidence, matched, mismatches, retraction, _provenance }."New value: +"One result per verifiable entry: { index, sourceKey?, status: 'ok'|'error', verdict, confidence, matched, mismatches, retraction, _provenance }. `index` is 1-BASED and counts position in the submitted input, so entry 1 is the first reference — do not add 1 again when you report it to a user. `sourceKey` is the entry's own key in the source file (BibTeX cite key, RIS `ID`, or CSL-JSON `id`) and is the reliable way to map a verdict back to the user's bibliography; it is absent on the claims[] path and on formats that carry no key. `status:'error'` means that one entry failed to verify, not that the batch failed. Entries appear in input order." - changed
Output schema / properties / parseErrors / descriptionPrevious value: -"Entries that could not be parsed or lacked a title: { index, error, message }."New value: +"Entries that could not be parsed or lacked a title: { index, error, message }. Same 1-based `index` space as `entries`, so the two arrays never collide: a given input position appears in exactly one of them. Report these to the user as unchecked, NOT as clean." - changed
Output schema / properties / summary / descriptionPrevious value: -"Corpus roll-up: { total, matched, mismatch, ambiguous, not_found, errored, retracted }."New value: +"Corpus roll-up: { total, matched, mismatch, ambiguous, not_found, errored, retracted }. `total` counts verifiable entries only, so it excludes `parseErrors` and anything past the cap. `retracted` is a separate axis from the verdict counts, and an entry can be both matched and retracted — never add the fields together." - changed
Output schema / properties / truncated / descriptionPrevious value: -"Count of entries dropped beyond the 25-entry cap."New value: +"Count of entries dropped beyond the 25-entry cap. Non-zero means the audit is incomplete — split the bibliography and call again for the rest."
7 tool updates
- First observed
auditBibliography - First observed
checkOpenAccess - First observed
checkRetraction - First observed
exportCitation - First observed
formatCitation - First observed
resolveIdentifier - First observed
verifyCitation
Frequently Asked Questions
Claiming proves that you control a remote MCP connector. It does not move, proxy, or interrupt the server.
Open the connector listing, choose Claim ownership, and sign in to Glama.
Complete one verification method:
GitHub identity — fastest for official registry listings. For a namespace such as
io.github.alice/server, link the matching GitHub user, then choose Claim with GitHub. An organization namespace such asio.github.acme/serveralso needs that organization to have installed the Glama AI GitHub App and approved its permissions, because GitHub discloses organization membership only to apps it has installed. Use HTTP or DNS when it has not.HTTP challenge — works when you can deploy a public file. Generate a token, publish the exact JSON Glama shows at
/.well-known/glama.jsonon the same origin as the connector, then choose Check HTTP challenge.DNS challenge — works when you control DNS but cannot change the server. Generate a token, create the exact TXT record Glama shows, wait for it to propagate, then choose Check DNS challenge.
After verification, Glama sends a confirmation email and gives you access to listing details, thumbnails, health checks, and analytics. Keep the HTTP file or DNS record in place: Glama periodically checks it and ownership remains verified while the token is discoverable.
The HTTP ownership file has this structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"claim": "glama_claim_..."
}Claim tokens are opaque, stable, and bound to the signed-in Glama account. They contain no email address or other personal information. If Glama can no longer discover a verified HTTP or DNS token, it starts a seven-day grace period before removing claim-based access. Restore the same token during that period to keep ownership verified. Never publish an email address, Glama session token, GitHub token, or connector credential as ownership proof.
If verification fails, confirm that you copied the current token exactly. The HTTP file must be public, return valid JSON with a successful HTTP response, and stay on the connector's origin. DNS changes may need more time to propagate. A claim cannot transfer to a different origin or hostname: if the connector target changes, Glama starts the grace period and the new target must be claimed separately after the previous claim is released.
For a connector linked to the official MCP Registry, registry updates continue to replace its name, description, and URL by default. After claiming, open Manage connector and enable Use Glama listing details as the source of truth if edits made on Glama should be preserved. Categories and thumbnails are always managed on Glama; registry linkage and technical connection settings continue to sync.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
To improve your MCP server's ranking:
Claim ownership of the server listing
Complete the server profile with an accurate description and thumbnail
Provide a test profile so Glama can connect to and evaluate the server
Keep tool definitions clear and complete to earn a high Tool Definition Quality Score (TDQS)
Route real usage through the Glama Gateway; more recorded successful server uses also improve the ranking
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Connectors
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
AI research grounded in 300M scientific works — every citation a verifiable DOI.
Academic literature search, retrieval, and private library management on top of OpenAlex.
Search arXiv/Semantic Scholar/OpenAlex + medical evidence (PubMed/Europe PMC) + LaTeX/PDF tools.
Related MCP Servers
- AlicenseNot gradedqualityAmaintenanceChecks whether a citation has been retracted, corrected, or flagged with an expression of concern by querying Crossref — including retractions that Crossref backfills from the Retraction Watch database, which publishers often never record in their own metadata. Lets an AI agent verify a DOI, or every DOI in a reference list, before using it in research or writing.1MIT
- AlicenseNot gradedqualityCmaintenanceVerifies citations in reference lists by checking DOIs against public registries to catch AI-hallucinated or mismatched citations.MIT
SciWeave MCP Serverofficial
FlicenseNot gradedqualityCmaintenanceGround Claude, ChatGPT, Cursor, and Windsurf in 300M scientific works — every citation a verifiable DOI.-
Try in Browser
Glama MCP Gateway
Add one secure layer between your agents and this server.
TDQS
A4.9/5.0
Disambiguation5/5
Each tool has a clearly distinct purpose: auditBibliography is the batch counterpart to verifyCitation, checkOpenAccess focuses on OA status, checkRetraction on retractions, resolveIdentifier returns raw metadata, formatCitation produces citation strings, and exportCitation produces files. Descriptions explicitly cross-reference each other to prevent confusion.
Naming Consistency5/5
All tool names follow a consistent verb_noun camelCase pattern: audit, check, check, export, format, resolve, verify + object. There is no mixing of styles or vague verbs.
Tool Count5/5
With 7 tools, the server is well-scoped for its purpose of citation verification and formatting. Each tool covers a distinct operational need (batch audit, single verify, OA, retraction, format, export, resolve) without bloat.
Completeness5/5
The toolset covers the full citation lifecycle: verifying a single citation, auditing entire bibliographies, checking retraction and open-access status, formatting citations, exporting to common bibliography formats, and resolving identifiers to metadata. No obvious gaps exist for the stated domain.