pubmed-mcp-server
Server Details
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- cyanheads/pubmed-mcp-server
- GitHub Stars
- 121
- Server Listing
- pubmed-mcp-server
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.3/5 across 10 of 10 tools scored.
Each tool targets a distinct operation: ID conversion, Europe PMC search, article fetch, fulltext fetch, related articles, citation formatting, citation lookup, MeSH lookup, PubMed search, and spell check. No functional overlap.
Tool names consistently use the 'pubmed_' prefix followed by a descriptive phrase, with most following a verb_noun pattern (e.g., pubmed_fetch_articles). However, 'pubmed_europepmc_search' reverses the order (noun_verb), which is a minor inconsistency.
10 tools cover a comprehensive range of PubMed-related tasks without being excessive. Each tool serves a distinct purpose, making the set well-scoped for biomedical literature retrieval.
The tool set covers all major PubMed operations: search, fetch metadata, fetch fulltext, convert IDs, find related articles, format citations, lookup citations, explore MeSH, and spell-check queries. No obvious gaps for a read-only PubMed interface.
Available Tools
11 toolspubmed_convert_idsPubmed Convert IdsARead-onlyInspect
Convert between article identifiers (DOI, PMID, PMCID). Accepts up to 50 IDs of a single type per request. Only resolves articles indexed in PubMed Central — for articles not in PMC, use pubmed_search_articles instead.
| Name | Required | Description | Default |
|---|---|---|---|
| ids | Yes | Article identifiers to convert. All IDs must be the same type. DOIs: "10.1093/nar/gks1195", PMIDs: "23193287", PMCIDs: "PMC3531190" (the "PMC" prefix is optional — bare digits like "3531190" are also accepted). | |
| idType | Yes | The type of IDs being submitted. Required so the API can unambiguously resolve them. |
Output Schema
| Name | Required | Description |
|---|---|---|
| records | Yes | Conversion results, one per input ID |
| totalConverted | Yes | Number of IDs successfully converted |
| totalSubmitted | Yes | Number of IDs submitted |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint and openWorldHint. The description adds behavioral context: only resolves articles in PubMed Central, enforces batch limits and type uniformity. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy. First sentence states purpose, second adds critical constraints, third provides alternative. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and complete parameter schema, the description provides sufficient context: scope, limits, alternative tool. No major gaps are evident.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. Description adds value with concrete examples for IDs (e.g., '10.1093/nar/gks1195') and clarifies that the 'PMC' prefix is optional. It also explains why idType is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Convert' and the resources (article identifiers: DOI, PMID, PMCID). It distinguishes from the sibling tool pubmed_search_articles by specifying the scope (only articles in PubMed Central) and provides an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use this tool (converting identifiers for articles in PMC), when not to (for articles not in PMC, use pubmed_search_articles), and imposes constraints: up to 50 IDs of a single type per request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_europepmc_fetchPubmed Europepmc FetchARead-onlyInspect
Fetch complete Europe PMC records — including the full, untruncated abstract — for records addressed by source plus epmcId. Pairs with pubmed_europepmc_search, which returns bounded abstractSnippet values and flags cut ones with abstractTruncated: true; pass those hits' source and epmcId here to read the whole abstract. This is the retrieval path for preprint (PPR), patent (PAT), and Agricola (AGR) records, which frequently carry no PMID and no DOI, so pubmed_fetch_articles and pubmed_fetch_fulltext cannot address them. Up to 25 records per call.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes | Records to retrieve, each addressed by the `source` and `epmcId` of a `pubmed_europepmc_search` hit. The whole batch resolves in one Europe PMC request. |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Guidance when one or more requested records could not be resolved. Absent when every record came back. |
| records | Yes | Resolved records, in the order Europe PMC returned them |
| notFound | No | Requested `source` + `epmcId` pairs Europe PMC returned no record for |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and openWorldHint=true. Description adds valuable context: retrieves untruncated abstract, up to 25 records per call, and explains resolution behavior for PMC records. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, no wasted words, front-loaded with core purpose. Structured logically: what it does, how it pairs with search, special use cases, and batch limit.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of output schema, description covers all necessary context: use case, parameters, pairing, limitations, and alternative tools. No gaps for effective agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds meaning beyond schema by explaining that source+epmcId come from search hit, and for PMC records it resolves to canonical MED record. Provides context missing in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Fetch complete Europe PMC records' and distinguishes from sibling 'pubmed_europepmc_search' which returns truncated abstracts. Also clarifies it handles preprint, patent, and Agricola records that other fetch tools cannot.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states pair with 'pubmed_europepmc_search', when to use (for full abstract after truncated snippet), and why alternatives like 'pubmed_fetch_articles' cannot be used for certain record types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_europepmc_searchPubmed Europepmc SearchARead-onlyInspect
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.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Optional 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. | |
| query | Yes | Europe 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. | |
| sources | No | Filter 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. | |
| pageSize | No | Results per page. Max 100 per EPMC API. | |
| cursorMark | No | Pagination cursor. Use `*` (default) for the first page; pass the previous response's `nextCursorMark` for subsequent pages. | * |
| resultType | No | `core` returns abstract, IDs, dates, license; `lite` is a smaller payload with IDs and titles only. | core |
Output Schema
| Name | Required | Description |
|---|---|---|
| hits | Yes | Matching Europe PMC records, in the order EPMC returned them |
| query | Yes | Effective query string echoed by Europe PMC |
| notice | No | Optional guidance when results are empty or paging overshot |
| searchUrl | Yes | Europe PMC's website search URL for this query |
| cursorMark | Yes | Cursor used for this response (echoed from the request) |
| totalCount | Yes | Total matching records across all pages |
| appliedSources | Yes | Sources the query was filtered against (defaults applied) |
| nextCursorMark | No | Cursor to pass back as `cursorMark` for the next page. Absent on the final page. |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds substantial behavioral details beyond the annotations: defaults to MED, PMC, PPR; behavior of sort parameter for preprint-only sets; pagination via cursorMark; difference between core and lite result types. All consistent with readOnlyHint and openWorldHint annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with purpose. The two paragraphs cover all necessary information without redundancy, making it efficient for an AI agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, output schema, annotations), the description is complete. It addresses key behaviors, edge cases (sort for preprints), and source coverage, leaving no obvious gaps for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 100% schema coverage, the description enriches parameter understanding: explains sort field limitations, default sources, pagination mechanics, and resultType payload differences. It provides practical examples and edge cases that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's purpose: searching Europe PMC, a broad biomedical corpus. It distinguishes from sibling tools by specifying coverage of preprints, patents, Agricola, and everything in PubMed/PMC, which sets it apart from more focused search tools like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context on when to use: 'when additional coverage is needed — preprints and EPMC-only OA records are the typical recovery.' It explains pagination and source defaults but does not explicitly state when not to use or compare directly to alternatives, leaving some room for interpretation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_fetch_articlesPubmed Fetch ArticlesARead-onlyInspect
Fetch full article metadata by PubMed IDs. Returns detailed article information including abstract, authors, journal, MeSH terms.
| Name | Required | Description | Default |
|---|---|---|---|
| pmids | Yes | PubMed IDs to fetch | |
| includeMesh | No | Include MeSH terms | |
| includeGrants | No | Include grant information |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Optional guidance when no articles were returned — points to discovery tools. Absent on successful fetches. |
| articles | Yes | Parsed articles |
| totalReturned | Yes | Number of articles returned |
| unavailablePmids | No | PMIDs that returned no article data |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and openWorldHint true, so the description correctly aligns. It adds value by listing the returned data types (abstract, authors, journal, MeSH terms), which informs the agent about the scope of results without contradicting 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core action, the second lists contents. It is front-loaded and concise, but given 10 siblings, a more structured breakdown (e.g., bullet points or explicit differentiation) could improve scanning for agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for a tool with an output schema and annotations, but for an external API (openWorldHint), it omits constraints like max 200 IDs, reliance on prior search, or any rate limits. While the schema handles parameter details, external context is missing for a fully informed agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully explains the three parameters. The description only mentions 'PubMed IDs' and 'MeSH terms' broadly, which overlaps with the schema but does not add new semantic meaning or usage nuances beyond the structured definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Fetch' and resource 'full article metadata by PubMed IDs', and lists specific content like abstract, authors, journal, MeSH terms. This differentiates it from siblings such as pubmed_search_articles (search returns IDs) and pubmed_fetch_fulltext (full text), establishing a distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when PubMed IDs are available and detailed metadata is needed, but lacks explicit when-to-use, when-not-to-use, or alternative guidance. Given 9 siblings, the description does not help the agent distinguish between fetch_articles and fetch_fulltext or search, leaving selection ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_fetch_fulltextPubmed Fetch FulltextARead-onlyInspect
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), then to Unpaywall — publisher-hosted or institutional open-access copies as HTML-as-Markdown or PDF-as-text. 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 and EPMC-only OA fall through to the Europe PMC and Unpaywall layers).
| Name | Required | Description | Default |
|---|---|---|---|
| dois | No | DOIs 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. | |
| pmids | No | PubMed 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. | |
| pmcids | No | PMC 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. | |
| sections | No | Filter to specific sections by title, case-insensitive (e.g. ["Introduction", "Methods", "Results", "Discussion"]). Applies to `source=pmc` results only. | |
| maxSections | No | Maximum top-level body sections. Applies to `source=pmc` results only. | |
| overflowMode | No | How 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 |
| maxCharacters | No | Per-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. | |
| includeReferences | No | Include reference list. Applies to `source=pmc` results only. | |
| maxCharactersPerSection | No | Budget 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
| Name | Required | Description |
|---|---|---|
| notice | No | Optional 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. |
| articles | Yes | Full-text articles |
| truncation | No | Character 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. |
| unavailable | No | Per-identifier explanations for any requested PMIDs, PMCIDs, or DOIs with no returnable full text. `idType` discriminates which branch the id came from. |
| totalReturned | Yes | Number of articles returned |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses fallback behavior (Europe PMC, Unpaywall) beyond the readOnlyHint and openWorldHint annotations. It adds behavioral context such as auto-resolution and fallback layers.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat lengthy but well-structured and front-loaded with the main purpose. Every sentence adds value, though it could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description adequately covers the tool's functionality, fallbacks, and parameter usage. Minor omissions like error handling are acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context beyond the schema, e.g., fallback details for dois and pmids. The parameter descriptions are enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool fetches full-text articles from PubMed Central with structured sections and references, including fallback mechanisms. It distinguishes this tool from siblings like pubmed_fetch_articles (metadata) and pubmed_convert_ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use each identifier parameter (pmcids, pmids, dois) and how fallbacks work. It does not explicitly state when not to use the tool, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_format_citationsPubmed Format CitationsARead-onlyInspect
Get formatted citations for PubMed articles in one or more formats (apa, mla, bibtex, ris, vancouver). Pass a single format as a string or multiple as an array.
| Name | Required | Description | Default |
|---|---|---|---|
| pmids | Yes | PubMed IDs to cite | |
| format | No | Citation format(s) to generate — single style as a string or multiple as an array. Allowed values: apa, mla, bibtex, ris, vancouver. | apa |
Output Schema
| Name | Required | Description |
|---|---|---|
| notice | No | Optional guidance when no citations were produced — points to discovery tools. Absent when at least one citation was produced. |
| citations | Yes | Citations per article |
| totalFormatted | Yes | Number of PMIDs successfully formatted |
| totalSubmitted | Yes | Number of PMIDs submitted for citation formatting |
| unavailablePmids | No | Requested PMIDs that did not return article metadata |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and openWorldHint. The description adds value by specifying the exact styles and default behavior, but does not elaborate on potential error handling or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose, with no wasted words. Every sentence is necessary and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 not be explained. The description covers the core functionality and constraints, though it could briefly mention that multiple PMIDs are accepted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema fully documents both parameters. The description reiterates that format can be a string or array, which adds no new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns formatted citations for PubMed articles, listing specific styles. It distinguishes itself from sibling tools like pubmed_fetch_articles and pubmed_lookup_citation, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when formatted citations are needed and mentions the ability to pass single or multiple styles, but it does not provide explicit when-to-use or when-not-to-use guidance compared to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_lookup_citationPubmed Lookup CitationARead-onlyInspect
Look up PubMed IDs from partial bibliographic citations. Useful when you have a reference (journal, year, volume, page, author) and need the PMID — deterministic citation matching, more reliable than free-text search for structured references. Each citation must include at least journal or year (ECitMatch primary-keys on journal+volume+page; author-only or volume-only inputs guarantee no match); more fields = better match accuracy.
| Name | Required | Description | Default |
|---|---|---|---|
| citations | Yes | Citations to look up. More fields = better match accuracy. |
Output Schema
| Name | Required | Description |
|---|---|---|
| results | Yes | Match results, one per input citation |
| totalMatched | Yes | Number of citations with PMID matches |
| totalWarnings | Yes | Number of matched citations that carry at least one warning |
| totalSubmitted | Yes | Number of citations submitted |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint, openWorldHint), description reveals it uses ECitMatch with primary keys on journal+volume+page, explains deterministic nature, and guarantees no match for certain inputs. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack purpose, use case, reliability, constraints, and best practices. Every sentence adds value; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter (citations array) and existing output schema, the description fully explains matching logic, constraints, and reliability. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but description adds context about minimum required fields (journal or year) and explains ECitMatch primary keys, which enhances understanding. Slightly above baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool looks up PubMed IDs from partial bibliographic citations, specifies it's for structured references, and distinguishes from free-text search by noting deterministic matching. This differentiates it from sibling tools like 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (having a reference with journal/year/volume/page/author) and warns against author-only or volume-only inputs. It also recommends more fields for better accuracy, providing clear guidance on optimal usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_lookup_meshPubmed Lookup MeshARead-onlyInspect
Search and explore the MeSH (Medical Subject Headings) controlled vocabulary. Returns descriptor records with tree numbers, scope notes, and entry terms, plus pagination via offset for paging past the maxResults cap.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | MeSH descriptor name or free-text term to look up | |
| offset | No | Result offset for pagination (0-based). Pass the `nextOffset` from the previous response to get the following page; the exact-descriptor match is pinned to the first page only. | |
| maxResults | No | Maximum results | |
| includeDetails | No | Fetch full MeSH records (scope notes, tree numbers, entry terms) |
Output Schema
| Name | Required | Description |
|---|---|---|
| query | Yes | Original search query |
| notice | No | Optional guidance when no descriptors matched or the offset overshot the result set — suggests spell-check, free-text search, or resetting the offset. Absent on successful result pages. |
| offset | Yes | Result offset this page was read from |
| results | Yes | Matching MeSH records |
| nextOffset | No | Offset to request for the next page. Omitted when this is the last page, so its absence is the end-of-results signal. |
| totalCount | Yes | Total MeSH descriptors matching the query upstream, before the maxResults cap |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=true, indicating safe, non-destructive behavior. The description adds specific return content (tree numbers, scope notes, entry terms) without contradicting annotations. No additional behavioral traits (e.g., pagination, auth needs) are disclosed, but the description is sufficient given 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences, no wasted words, and front-loaded with the key action. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the existence of an output schema and the tool’s simplicity (3 params, 1 required), the description covers the essential return fields. No additional context is needed for an AI agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats that the tool returns scope notes, tree numbers, and entry terms but does not add meaning beyond the schema for individual parameters (e.g., query format, maxResults behavior, includeDetails effect). No parameter descriptions are enriched.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: searching and exploring the MeSH controlled vocabulary, and specifies the return fields (descriptor records with tree numbers, scope notes, entry terms). It distinguishes from sibling tools like pubmed_search_articles which focus on article search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for MeSH lookups but does not provide explicit guidance on when to use this tool versus alternatives (e.g., pubmed_lookup_citation, pubmed_search_articles) or when not to use it. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_search_articlesPubmed Search ArticlesARead-onlyInspect
Search PubMed with full query syntax, filters, and date ranges. Returns PMIDs and optional brief summaries. Supports field-specific filters (author, journal, MeSH terms), common filters (language, species, free full text), and pagination via offset for paging through large result sets.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order: relevance (default), pub_date (newest first), author, or journal | relevance |
| query | Yes | PubMed search query (supports full NCBI syntax) | |
| author | No | Filter by author name (e.g. "Smith J") | |
| offset | No | Result offset for pagination (0-based). PubMed serves at most the first 9999 records of a result set, so this caps at 9998; narrow the query or add filters to reach anything beyond it. | |
| journal | No | Filter by journal name | |
| species | No | Filter by species | |
| language | No | Filter by language (e.g. "english") | |
| dateRange | No | Filter by date range. The filter is applied only when both `minDate` and `maxDate` are non-empty; either one empty disables the entire date range. | |
| meshTerms | No | Filter by MeSH terms. Multiple terms are AND'd — all must match. | |
| maxResults | No | Maximum results to return | |
| hasAbstract | No | Only include articles with abstracts | |
| freeFullText | No | Only include free full text articles | |
| summaryCount | No | Fetch brief summaries for top N results (0 = PMIDs only). Above the 50 cap, pass the remaining PMIDs to pubmed_fetch_articles. | |
| publicationTypes | No | Filter by publication type (e.g. "Review", "Clinical Trial", "Meta-Analysis"). Multiple values are OR'd — any match qualifies. |
Output Schema
| Name | Required | Description |
|---|---|---|
| pmids | Yes | PubMed IDs |
| query | Yes | Original query |
| notice | No | Optional guidance when the result set does not reflect what was asked for — a field tag PubMed ignored, a phrase it matched nothing for, a dateRange dropped for having one bound, no matches at all, or paging past the end. Absent when nothing applies. |
| offset | Yes | Result offset used |
| searchUrl | Yes | PubMed search URL |
| summaries | Yes | Brief summaries (empty array when summaryCount is 0) |
| totalCount | Yes | Total matching articles |
| appliedFilters | Yes | Normalized filter values that were applied to the PubMed query |
| effectiveQuery | Yes | Sanitized query sent to PubMed after applying all active filters |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations (readOnlyHint, openWorldHint) already indicate safe, open-ended queries. Description adds value by specifying return of 'PMIDs and optional brief summaries' and mention of pagination. Does not contradict annotations. Could further detail rate limits or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences front-loaded with primary function. Every word adds value; no redundant phrases. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 14 parameters, nested objects, and output schema present, the description covers key features (filters, pagination, summaries). Could include result size limit or output type details but is not deficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with detailed parameter descriptions. Description summarizes filters and pagination but does not add new meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Search PubMed with full query syntax' clearly identifying action and resource. Distinguishes from siblings like pubmed_fetch_articles (fetching) and pubmed_convert_ids (conversion) by specifying search with filters and pagination.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes capabilities but does not explicitly guide when to use this tool vs. alternatives like pubmed_fetch_articles for full text or pubmed_lookup_citation for specific citations. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pubmed_spell_checkPubmed Spell CheckARead-onlyInspect
Spell-check a query and get NCBI's suggested correction. Useful for refining search queries.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | PubMed search query to spell-check |
Output Schema
| Name | Required | Description |
|---|---|---|
| original | Yes | Original query |
| corrected | Yes | Corrected query (same as original if no suggestion) |
| hasSuggestion | Yes | Whether NCBI suggested a correction |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds context that it connects to 'NCBI' (aligning with openWorldHint), but does not disclose additional behavioral traits like what happens when no corrections exist or how many suggestions are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste: first sentence defines the action and return value, second provides usage context. Appropriately front-loaded and sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, simple structure, and an output schema exists, the description provides sufficient context. It could be improved by noting this is specifically for PubMed queries, but the tool name makes this clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents the 'query' parameter. The description does not add supplementary semantics, examples, or format constraints beyond what the schema provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Spell-check a query'), the external resource ('NCBI's suggested correction'), and distinguishes clearly from sibling tools which focus on fetching articles, converting IDs, or formatting citations rather than query validation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context on when to use ('Useful for refining search queries'), indicating it should be used for query validation before searching. However, it does not explicitly mention when NOT to use it or name specific sibling alternatives like pubmed_search_articles.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
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
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!
Your Connectors
Sign in to create a connector for this server.