pubmed-mcp-server

by cyanheads

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Remote

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v2.10.12
Disambiguation4/5
Each tool targets a distinct resource or action, but there is a cluster of retrieval tools (pubmed_fetch_articles, pubmed_fetch_fulltext, pubmed_europepmc_fetch) whose boundaries are subtle and rely on dense descriptions to separate. Similarly pubmed_search_articles vs pubmed_europepmc_search overlap conceptually across corpora. Descriptions do resolve these, keeping confusion to one or two pairs.
Naming Consistency4/5
Names are uniformly snake_case with a consistent pubmed_ prefix, and most follow a predictable verb_noun pattern (search_articles, fetch_articles, lookup_mesh, convert_ids). The two Europe PMC tools invert the order (europepmc_fetch, europepmc_search), a minor but noticeable deviation.
Tool Count5/5
Eleven tools is well-scoped for a biomedical literature server, covering search, retrieval, citation, vocabulary, and ID operations without bloat. Each tool clearly earns its place.
Completeness4/5
The surface covers the full retrieval lifecycle: search, metadata fetch, full-text, related/citing, MeSH, citation formatting and lookup, ID conversion, and Europe PMC fallback paths. Minor gaps exist (e.g. no explicit bulk export or saved-set management), but core workflows are complete with graceful fallbacks.
Average 4.2/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 6 of 6 community issues answered or closed in the last 6 months
- 60 commits in the last 12 weeks
- Last stable release on September 11, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, and the description adds genuinely new behavioral context: the data-source fallback chain (NCBI ELink primary, then Europe PMC, then OpenAlex). It does not mention rate limits or result-shape caveats, but the fallback disclosure is real added value.
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?
Two sentences, zero filler, with the purpose front-loaded and the relationship taxonomy immediately following. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value explanation is not needed, and the description covers purpose, relationship modes, and source fallback. It omits explicit guidance on routing between this tool and sibling search/fetch tools, which keeps it just below a 5.
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%, so pmid, offset, maxResults, and relationship are already documented in the schema. The description echoes the relationship semantics and the source-article concept but adds no syntax or format detail beyond the schema — baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Find articles related to a source article') and enumerates the three relationship modes, so an agent immediately understands the tool's function. It does not explicitly contrast itself with siblings such as pubmed_fetch_articles or pubmed_lookup_citation, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by listing the three relationship modes, which tells an agent what it can ask for, but it gives no 'when to use this vs. alternatives' guidance and no exclusions. Usage is inferable rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered structurally. The description adds the format-selection flexibility (single vs array), which is useful, but does not disclose whether output is a string, dict keyed by format, pagination, or error behavior for invalid PMIDs. Adequate but thin for a networked lookup.
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?
Two sentences, no waste, front-loaded with the primary purpose followed immediately by the format flexibility. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return shape need not be explained, and annotations cover the safety profile. The description is complete enough to invoke correctly, though it omits any note about when to prefer this tool over pubmed_lookup_citation.
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 schema already documents pmids, format enum values, and the anyOf string/array flexibility in detail. The description restates the same single-vs-array pattern the schema already specifies, so it adds no meaning beyond structured fields. Baseline 3 is correct.
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 (Get formatted citations) and resource (PubMed articles) with the exact formats supported. An agent can distinguish this from siblings like pubmed_lookup_citation (which likely does the reverse – citation to PMID) without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (get formatted citations for given PMIDs) but offers no explicit when-to-use guidance or mention of alternatives. In a crowded sibling set including pubmed_lookup_citation, the lack of routing guidance is a clear gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover readOnlyHint and openWorldHint, so the safety profile is handled. The description adds real behavioral context: return format (PMIDs + optional summaries), pagination via offset for large sets, and the general shape of results. It doesn't mention rate limits or the 9999-record PubMed cap (that lives in the schema), but as a read-only search this is solid.
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?
Three tight sentences, front-loaded with the core action and resource, then capabilities. Zero filler; every clause carries information (filters, return shape, pagination).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 14 params with full schema coverage, an output schema, and annotations, the description is appropriately scoped. It explains return shape and pagination. Missing: explicit routing to sibling tools (europepmc_search, fetch_articles handoff) for a tool whose ecosystem has many near-neighbors, which is a minor gap.
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%, so baseline is 3. The description adds marginal value by summarizing filter categories (field-specific: author, journal, MeSH; common: language, species, free full text) and pagination, but every parameter is already fully documented in the schema, so it doesn't add beyond what's structured.
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+resource ("Search PubMed") and enumerates the capabilities: full query syntax, filters, date ranges, and return shape (PMIDs with optional summaries). It clearly distinguishes itself from siblings like pubmed_fetch_articles and pubmed_europepmc_search by positioning as the primary PubMed search entry point.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage is clear for a search tool, but there's no explicit when-not guidance or routing to siblings (e.g., europepmc_search vs pubmed_search_articles, or the summaryCount→fetch_articles handoff beyond the schema's own note). The description omits any alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering safety and open-endedness. The description adds the nature of the output ('NCBI's suggested correction') but does not disclose additional behavioral traits like rate limits or error handling. Given the annotation coverage, this is adequate but not enriched beyond them.
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 two concise sentences with zero filler. The core action and purpose are front-loaded, and the usage hint follows naturally. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with a single parameter, a full output schema, and annotations covering read-only and open-world behavior. The description covers the purpose and usage. Nothing essential for calling the tool is missing, though it could mention the exact format of the correction, which the output schema presumably handles.
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?
The schema description coverage is 100%, so the parameter 'query' is fully documented in the schema itself. The tool description adds no extra parameter details, which is acceptable per the baseline since the schema carries the full semantic load.
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 a specific action ('Spell-check a query') and the result ('get NCBI's suggested correction'). It unambiguously distinguishes this tool from siblings like pubmed_search_articles or pubmed_fetch_articles, which handle searching and retrieval rather than spelling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for refining search queries' provides clear context on when to use the tool. It does not explicitly mention alternatives or exclusions, but the intent is evident and sufficient for an agent to select it appropriately among the sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe read-only, open-world profile, so the bar is lower; the description still adds real behavior: responses may be truncated under maxResponseCharacters, articles are deferred whole (never partially populated), and the follow-up set appears in deferred.ids. It does not disclose rate limits or the 200-PMID cap, but the deferral semantics are the meaningful addition.
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?
Three tight sentences: purpose first, return contents second, the truncation/follow-up mechanic third. No filler, nothing repeated from the schema, and the actionable constraint is not buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is not required, and the description still covers the one non-obvious behavior (deferral). It omits the batch-size bound (max 200 pmids) and does not point to full-text retrieval when metadata is insufficient, leaving minor gaps.
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 nonetheless explains the practical consequence of maxResponseCharacters (articles past the ceiling are deferred whole and surfaced in deferred.ids for a follow-up call), which adds operational meaning beyond the schema's field-level wording.
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+resource ('Fetch full article metadata by PubMed IDs') and enumerates what comes back (abstract, authors, journal, MeSH terms). By calling out metadata in contrast to the sibling pubmed_fetch_fulltext, an agent can distinguish the two 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the required pmids input ('by PubMed IDs'), and the follow-up loop for deferred ids is described, but there is no explicit when-to-use/when-not guidance or named alternative (e.g., use pubmed_fetch_fulltext when you need the body text). Adequate but with a clear routing gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint annotations, the description goes beyond by detailing the multi-source fallback chain, character budget behaviors (truncation vs outline, deferral in deferred.ids), and resource controls like includeAssets/includeTables defaults. It explains what gets dropped and how, which is valuable context not in annotations. Missing: rate limits, authentication needs, or timeout behavior.
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?
Well-structured with front-loaded core purpose followed by fallback and parameter highlights. Every sentence carries weight, though it's somewhat long given the complexity. No wasted words, but could be slightly more scannable.
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 tool with 12 parameters, a rich schema, and an output schema, the description is complete. It covers purpose, fallbacks, parameter interactions, and budget semantics. Since an output schema exists, it doesn't need to explain return values. An agent has enough to invoke correctly and understand behavior.
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%, so the schema already documents all 12 parameters thoroughly. The description adds some high-level context about exactly one of pmcids/pmids/dois must be provided and the two character controls, but doesn't add syntax details beyond what's already in the schema. Baseline 3 is appropriate when 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 specific verb (fetch) and resource (full-text articles from PubMed Central) with structured sections, tables, and references. It also distinguishes itself from siblings like pubmed_fetch_articles and pubmed_europepmc_fetch by naming the fallback to Europe PMC fullTextXML, making scope clear 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Clearly states the context: use this to get full-text when needed, and describes fallback behavior when PMC misses (Europe PMC, then Unpaywall if enabled). However, it doesn't explicitly contrast with sibling tools like pubmed_fetch_articles (likely abstracts) or pubmed_europepmc_fetch, leaving some ambiguity about when to choose this over those alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context: deterministic citation matching via ECitMatch, primary-keying on journal+volume+page, and the guarantee that author-only or volume-only inputs yield no match — non-obvious traits an agent needs.
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?
Three sentences, front-loaded with the action and purpose before constraints. The dense parenthetical about ECitMatch keying is information-rich rather than wasteful, though slightly compact for quick parsing.
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 an output schema present, return values need no explanation. The description covers the matching mechanism, input requirements, and accuracy tradeoffs; combined with readOnly/openWorld annotations, an agent has everything needed to invoke it correctly.
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 nested citation schema already documents each field plus the journal-or-year requirement and the primary-key behavior, so the description largely repeats structured content. It reinforces field-selection strategy ("more fields = better match accuracy") but adds little 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?
States a specific verb and resource (look up PubMed IDs from partial bibliographic citations) and clearly scopes the input shape (journal, year, volume, page, author). It also contrasts itself with free-text search for structured references, letting an agent distinguish it from pubmed_search_articles.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
"Useful when you have a reference ... and need the PMID" gives explicit when-to-use context and positions it against free-text search. It does not name the sibling (pubmed_search_articles) directly or state when-not to use it, so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral details beyond the readOnlyHint/openWorldHint annotations by explaining the return contents and the pagination mechanism for paging past the maxResults cap. No contradictions with the annotations are present.
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 a single sentence with no filler: it front-loads the action and result type, then adds pagination behavior. Every clause contributes useful information.
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 rich input schema, existing output schema, and readOnly/openWorld annotations, the description is complete for agent selection and invocation. It covers the core use case, return contents, and pagination nuance without needing to restate structured fields.
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% and each parameter already has a detailed description. The description's mention of pagination and offset restates the schema's own guidance without adding significant new parameter-level meaning, so the baseline of 3 applies.
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 ('Search and explore') and a specific resource ('MeSH controlled vocabulary'), and it names the return payload (descriptor records with tree numbers, scope notes, entry terms). This clearly differentiates it from siblings like pubmed_search_articles or pubmed_lookup_citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this tool is for MeSH vocabulary lookups rather than article or citation searches, which is a distinct use case from the siblings. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint, so safety is covered. The description adds real behavioral context beyond that: the 50-ID ceiling, the single-idType-per-request rule, and the PMC-only resolution scope, which materially changes what results the agent should expect. It stops short of describing unmapped-ID or partial-failure 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?
Three short sentences, front-loaded with the core purpose, then the constraints, then the alternative. Every sentence carries a distinct piece of actionable information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no explanation, and the description covers scope, limits, and routing. The only omission is what happens to individually unresolvable IDs within an accepted batch, which is minor given the output schema covers results.
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 schema already spells out per-element format validation for doi/pmid/pmcid, the maxItems of 50, and the same-type rule. The description's 'up to 50 IDs of a single type' restates the schema rather than adding syntax or edge-case meaning, so the baseline of 3 applies.
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 — 'Convert between article identifiers (DOI, PMID, PMCID)' — and enumerates the identifier types handled. It also explicitly separates itself from pubmed_search_articles for the non-PMC case, so an agent can route correctly without opening the 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 precondition (articles must be indexed in PubMed Central), a hard operational limit (up to 50 IDs, single type per request), and names the concrete alternative (pubmed_search_articles) for the excluded case. Both when-to-use and when-not-to-use are covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and openWorldHint already declared, the baseline burden is lower, and the description adds substantial behavior beyond them: cursorMark-based pagination, the default source set (MED/PMC/PPR), and the output contract of a bounded abstractSnippet with abstractTruncated flagging cut results. It also routes to pubmed_europepmc_fetch for the full abstract — genuinely actionable behavioral context.
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?
Four sentences with purpose and scope front-loaded ahead of usage, pagination, and output behavior; every sentence earns its place. The final sentence is dense but packs critical truncation semantics and the follow-up fetch routing. Minor repetition of schema-documented defaults keeps it from a 5.
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 6-parameter read-only search tool with an output schema, the description covers corpus scope, the when-to-use condition, pagination, default sources, abstract truncation behavior, and the sibling tool for complete abstracts. Nothing material is left for the agent to infer or discover at call time.
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 schema itself is exceptionally detailed (sortable-field caveats, the P_PDATE_D preprint quirk, the unquoted-identifier-token rule, max pageSize). The description's mentions of defaults and cursorMark largely restate what the schema already documents, so it adds little parameter meaning beyond the established baseline.
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: 'Search Europe PMC, a broad open-access biomedical corpus,' and enumerates the exact coverage (preprints, patents, Agricola, plus all PubMed and PMC content). This cleanly distinguishes it from sibling pubmed_search_articles, which targets the narrower PubMed corpus, without needing to open 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 Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit trigger condition: 'Use when additional coverage is needed — preprints and EPMC-only OA records are the typical recovery,' and explains how to widen scope ('pass sources to include PAT/AGR'). It does not explicitly name the when-not alternative (e.g., 'use pubmed_search_articles for PubMed-only queries'), but the coverage-based contrast makes the routing decision clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description discloses that this tool returns untruncated abstracts, processes up to 25 records per call, and resolves the whole batch in one Europe PMC request. It also explains the MED-versus-PMC behavior in the schema and how truncated search snippets map to this tool, giving agents concrete behavioral expectations.
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?
Every sentence earns its place: core purpose, truncation relationship, alternative tool exclusion, and batch limit. The key behavior is front-loaded, and the description is informative without redundancy.
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 an output schema present, return-value documentation is unnecessary, and the description covers the essential operational context: what to pass, when to use it, why it exists versus siblings, and the batch limit. There are no obvious gaps an agent would face when selecting or invoking this tool.
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 already documents `source` and `epmcId` with enum values, patterns, and copy-from-search-hit guidance. The description adds workflow-level semantic value by telling the agent to pass the search hit's `source` and `epmcId`, and reinforces the batch limit, but it does not substantially redefine the parameter meanings.
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: 'Fetch complete Europe PMC records — including the full, untruncated abstract — for records addressed by `source` plus `epmcId`.' It clearly distinguishes itself from `pubmed_europepmc_search` and from `pubmed_fetch_articles`/`pubmed_fetch_fulltext` by naming exactly what makes this tool the right retrieval path.
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: pair it with `pubmed_europepmc_search`, pass the hit's `source` and `epmcId`, and use it for PPR/PAT/AGR records that lack PMID/DOI and therefore cannot be handled by sibling fetch tools. It also states the 25-record per-call limit, making the usage boundary unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

pubmed-mcp-server MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![pubmed-mcp-server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/cyanheads/pubmed-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/cyanheads/pubmed-mcp-server)

Score Badge

Copy to your README.md:

[![pubmed-mcp-server MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/cyanheads/pubmed-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/cyanheads/pubmed-mcp-server)