Skip to main content
Glama

pubmed-mcp-server

by io.github.cyanheads

Pubmed Europepmc Search

pubmed_europepmc_search
Read-only

Search Europe PMC, a broad open-access biomedical corpus. Surfaces preprints (source: PPR), patents (source: PAT), Agricola (source: AGR), plus everything in PubMed (MED) and PMC. Use when additional coverage is needed — preprints and EPMC-only OA records are the typical recovery. Paginate via cursorMark. Defaults to MED, PMC, and PPR; pass sources to include PAT / AGR. Abstracts arrive as a bounded abstractSnippet with abstractTruncated marking the cut ones — pass a hit’s source and epmcId to pubmed_europepmc_fetch for the complete abstract.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoOptional EPMC sort: `<field> asc|desc`. Documented sortable fields: `P_PDATE_D` (publication date), `CITED` (citation count), `AUTH_FIRST` (first author surname), `PUB_YEAR` (publication year). Examples: `P_PDATE_D desc` (newest first), `CITED desc` (most cited). Omit for relevance ranking. Fields outside the documented set are rejected by EPMC. Note: `P_PDATE_D` is ignored for preprint-only (`sources: ["PPR"]`) result sets — preprints have no populated publication date, so use `PUB_YEAR` to order preprints by date.
queryYesEurope PMC search query. Supports field tokens like `AUTH:"<name>"`, `JOURNAL:"<title>"`, `TITLE:"<words>"`, `PUB_YEAR:[2020 TO 2024]`, `DOI:"..."`, `EXT_ID:<pmid> AND SRC:MED`, `PMCID:PMC<digits>`. Identifier tokens combined with `AND SRC:` must be unquoted — the quoted form matches nothing. Free text is matched broadly across abstract/title/keywords.
sourcesNoFilter to specific EPMC sources. Defaults to MED, PMC, PPR when omitted. Pass an explicit array including PAT or AGR to broaden coverage. Allowed values: MED, PMC, PPR, PAT, AGR.
pageSizeNoResults per page. Max 100 per EPMC API.
cursorMarkNoPagination cursor. Use `*` (default) for the first page; pass the previous response's `nextCursorMark` for subsequent pages.*
resultTypeNo`core` returns abstract, IDs, dates, license; `lite` is a smaller payload with IDs and titles only.core

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
hitsNoMatching Europe PMC records, in the order EPMC returned them
errorNoPresent when the call failed. Absent on success.
queryNoEffective query string echoed by Europe PMC
noticeNoOptional guidance when results are empty or paging overshot
searchUrlNoEurope PMC's website search URL for this query
cursorMarkNoCursor used for this response (echoed from the request)
totalCountNoTotal matching records across all pages
appliedSourcesNoSources the query was filtered against (defaults applied)
nextCursorMarkNoCursor to pass back as `cursorMark` for the next page. Absent on the final page.

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, so the tool's safety profile is known. The description adds behavioral context beyond annotations: default sources (MED, PMC, PPR), pagination via cursorMark, and the abstractSnippet bounded/abstractTruncated behavior, including a pointer to the fetch tool for full abstracts. Even the P_PDATE_D preprint limitation is disclosed in the sort parameter description. Good transparency.

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?

Four sentences, each earning its place: purpose, usage trigger, pagination, source defaults/abstract truncation. Front-loaded with the core purpose, then actionable details. No filler or repetition.

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 search tool with 6 parameters and an output schema, the description covers the key operational aspects: when to use, source coverage, pagination mechanics, abstract truncation, and cross-tool routing for full abstracts. Combined with rich schema and annotations, an agent has everything it needs to call this 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%, so the schema already documents all parameters thoroughly. The description reinforces cursorMark usage and source defaults, but does not add substantial new meaning beyond what the schema provides. Baseline of 3 is appropriate.

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

Purpose5/5

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

The description opens with a specific verb ('Search') and a clearly defined resource ('Europe PMC, a broad open-access biomedical corpus'). It enumerates the unique content types covered (preprints, patents, Agricola, PubMed, PMC), which distinguishes it from the sibling pubmed_search_articles. No ambiguity about what this tool does.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool: 'Use when additional coverage is needed — preprints and EPMC-only OA records are the typical recovery.' It also routes to the sibling fetch tool for complete abstracts (pass source and epmcId). It does not explicitly exclude other search tools, but the context is clear enough for an agent to select correctly.

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

All pubmed-mcp-server toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0
Disambiguation4/5

The tools constitute a well-designed set targeting distinct workflow steps: searching (pubmed_search_articles, pubmed_europepmc_search), fetching (pubmed_fetch_articles, pubmed_fetch_fulltext, pubmed_europepmc_fetch), ID conversion (pubmed_convert_ids), related articles (pubmed_find_related), citations (pubmed_format_citations, pubmed_lookup_citation), MeSH lookup (pubmed_lookup_mesh), and spelling (pubmed_spell_check). While search and fetch tools in PubMed vs Europe PMC overlap somewhat, the descriptions explicitly differentiate them (local PubMed vs broader Europe PMC with preprints/patents), so ambiguity is minor.

Naming Consistency5/5

All tools follow a consistent `pubmed_` prefix followed by verb_noun pattern: `search_articles`, `fetch_articles`, `lookup_citation`, `format_citations`, `convert_ids`, `find_related`, etc. The verbs are all lowercase snake_case, and the pattern is uniform across the entire set, even for the Europe PMC variants (`pubmed_europepmc_search`, `pubmed_europepmc_fetch`).

Tool Count5/5

11 tools makes for a well-scoped server. Each tool serves a clearly distinct purpose within the biomedical literature retrieval domain: searching, fetching metadata/full-text, ID conversion, citation formatting/lookup, MeSH exploration, related-articles, and spell-check. No tool feels redundant or trivial; the count is appropriate for the domain's complexity.

Completeness5/5

The tool set provides comprehensive coverage of the core PubMed/PMC workflow: search with full query syntax, fetch metadata and full text, convert identifiers across DOI/PMID/PMCID, find related articles, format citations, and explore MeSH vocabulary. Notable gaps like more advanced search history management or batch operations exist but are not essential to the domain's core purpose. The fallback logic (e.g., europepmc_fetch for non-PMC records, fulltext fallback chain) fills potential dead ends.

Resources