Skip to main content
Glama
cyanheads

pubmed-mcp-server

by cyanheads

Pubmed Fetch Fulltext

pubmed_fetch_fulltext
Read-only

Retrieve structured full-text articles from PubMed Central, with automatic fallback to Europe PMC. Accepts PMC IDs, PubMed IDs, or DOIs and enables section filtering.

Instructions

Fetch full-text articles from PubMed Central with structured sections and references. When PMC misses, transparently falls back to Europe PMC fullTextXML (structured JATS for records with a PMC counterpart). Provide exactly one of pmcids (PMC IDs directly), pmids (PubMed IDs, auto-resolved), or dois (DOIs, auto-resolved to PMC via the ID Converter; preprints with a PMC counterpart recover via Europe PMC).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
doisNoDOIs to resolve (e.g. ["10.21203/rs.3.rs-9010375/v1"]). Provide exactly one of `pmcids`, `pmids`, or `dois`. Resolved to a PMCID via the PMC ID Converter and returned as structured JATS when the article is in PMC; DOIs with no PMC counterpart (preprints, EPMC-only OA) fall through to Europe PMC, then Unpaywall, when those layers are enabled.
pmidsNoPubMed IDs. Provide exactly one of `pmcids`, `pmids`, or `dois`. Articles in PMC are returned as structured JATS; articles not in PMC fall through to Europe PMC (when EPMC has a `fullTextXML`), then to Unpaywall when `UNPAYWALL_EMAIL` is set and a DOI is available.
pmcidsNoPMC IDs to fetch (e.g. ["PMC9575052"]). Provide exactly one of `pmcids`, `pmids`, or `dois`. PMC IDs with no retrievable full text fall through to Europe PMC, then to Unpaywall on the DOI the chain resolves for them.
sectionsNoFilter to specific sections by title, case-insensitive (e.g. ["Introduction", "Methods", "Results", "Discussion"]). Applies to `source=pmc` results only.
maxSectionsNoMaximum top-level body sections. Applies to `source=pmc` results only.
overflowModeNoHow to spend `maxCharacters` across an article that exceeds it. truncate: fill sections in document order, so early sections stay whole and sections past the budget are dropped (counted in `truncation.omittedSections`). outline: split the budget evenly so every section keeps its heading, and an excerpt as far as the budget reaches — use it to survey what an article contains before requesting specific `sections`. Ignored when no budget is set, and identical for `source=unpaywall` bodies, which have no headings to preserve.truncate
maxCharactersNoPer-article budget for body text, in characters. Counts `source=pmc` section and subsection text, or the `source=unpaywall` `content` body; titles, abstracts, identifiers, and references are never counted or shortened. Applied after `sections`, `maxSections`, and `includeReferences`, so semantic filtering is unaffected. The response-wide ceiling is this value times the number of articles returned. Omit for the full body.
includeReferencesNoInclude reference list. Applies to `source=pmc` results only.
maxCharactersPerSectionNoBudget for a single top-level body section, in characters, counting the section text plus its subsections. Combine with `maxCharacters` to cap both one section and the article; the tighter of the two wins. Applies to `source=pmc` results only.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noticeNoOptional guidance for a partial or empty body. A `sections`-filter miss names the requested terms and affected article id(s) and suggests retrying without `sections` or using broader headings. A metadata-only record names the id(s) the chain could retrieve as front matter only and points at `pubmed_fetch_articles` for the abstract. A budgeted response names the characters returned versus carried and points at `truncation`. Absent when none of those applies.
articlesYesFull-text articles
truncationNoCharacter accounting for full text the budget shortened. Present only when a budget actually removed characters — its absence means every returned article carries its full post-filter body.
unavailableNoPer-identifier explanations for any requested PMIDs, PMCIDs, or DOIs with no returnable full text. `idType` discriminates which branch the id came from.
totalReturnedYesNumber of articles returned
Behavior5/5

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

Annotations declare readOnlyHint=true and openWorldHint=true, both consistent with the description. The description adds significant behavioral detail: fallback behavior, truncation modes (`truncate` vs `outline`), character budget interplay, and that references are excluded from budget. No contradictions.

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 well-structured with a clear overview sentence, then parameter details. It is slightly long (over 200 words) but every sentence adds value; no redundancy. Front-loads the core purpose and fallback behavior. Minor room for trimming, but highly functional.

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 (9 parameters, fallback logic, multiple output modes), the description is remarkably complete. It explains all major behaviors, constraints, and edge cases (e.g., preprints with PMC counterpart). Output schema exists (implied by 'structured JATS'), so no need to describe return values.

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

Parameters5/5

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

Schema description coverage is 100% (baseline 3), but each parameter description adds substantial meaning beyond the schema—e.g., explaining resolution chains for DOIs, fallback context for pmids, and detailed behavior of `overflowMode` and `maxCharacters`. This greatly aids an agent in selecting and invoking the tool correctly.

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 starts with a specific verb ('Fetch full-text articles') and resource ('PMC with structured sections and references'), clearly distinguishing it from sibling tools like pubmed_fetch_articles (which likely returns metadata) and pubmed_europepmc_fetch (which focuses on Europe PMC).

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 states to provide exactly one of three ID types (`pmcids`, `pmids`, `dois`), explains the fallback chain when PMC misses (to Europe PMC, then Unpaywall), and notes when to use each input. This provides clear when-to-use guidance and alternatives.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cyanheads/pubmed-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server