PubMed MCP Server

by masa061580

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v2.0.0
Disambiguation5/5
Each tool serves a distinct purpose: search, abstract retrieval (single/batch), full-text, count, similarity, export, citations, ID conversion, and batch processing. Overlapping tools like fetch/fetch_batch and search/count are clearly differentiated by scope and description.
Naming Consistency5/5
All tool names use lowercase snake_case and follow a predictable verb-first pattern (e.g., search, fetch, get_full_text, export_to_ris). The naming style is consistent and readable across the entire set.
Tool Count5/5
10 tools is well-scoped for a PubMed server, covering essential operations without redundancy. Each tool adds meaningful functionality, and the count feels appropriate for the domain.
Completeness5/5
The tool set covers the full research workflow: search, retrieval, full-text access, counting, similarity discovery, citation analysis, ID conversion, citation export, and batch processing. There are no obvious dead ends or missing core operations for a read-only biomedical literature server.
Average 4.1/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the operation retrieves full text and offers section filtering to reduce token usage, which is a useful behavioral detail. However, it does not mention response format, error handling, or rate limits, leaving some gaps typical of a read operation.
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 brief two-sentence definition that front-loads the core functionality and adds only one additional feature. It is succinct and to the point, with no redundant content.
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?
For a simple retrieval tool with two well-documented parameters and no output schema, the description covers the essential 'what' and hints at a key usage trait (section filtering). It lacks explicit statements about output format or relationship to siblings, but given the simplicity, it is mostly complete.
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 input schema provides detailed descriptions for both parameters, covering PMIC ID format and section options. The description adds no further parameter semantics; its mention of token usage is already in the schema. Given high schema coverage, the baseline of 3 is appropriate.
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?
The description clearly states the tool retrieves full text from PMC by PMC ID, specifying the verb and resource. It also mentions section filtering, which adds purpose. However, it does not explicitly differentiate from sibling tools like fetch or fetch_batch, so it does not achieve a perfect 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 when full text from PMC is needed, and the section filtering note suggests a use case for reducing token usage. However, there is no explicit comparison to alternatives or exclusion criteria, leaving the guidance implicit rather than explicit.
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 no annotations, the description carries the full burden. It details output modes and exactly what each returns (minimal/compact/full), which goes beyond the schema. It does not mention rate limits or error handling, but for a search tool this is substantial behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not overly long. It front-loads purpose and then explains output modes efficiently in one sentence. No wasted words, though the construction is a bit run-on.
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 6 params, nested filters, and no output schema, the description covers the essentials: purpose, output behavior, and mentions pagination/filters. It lacks comprehensive return value documentation but the output mode explanation partially fills that gap.
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 baseline is 3. The description adds significant meaning to output_mode by breaking down exactly which fields each mode includes, which is not in the schema. Other parameters are adequately described in the schema.
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?
The description clearly states it searches PubMed with MeSH support, filters, pagination, and selectable output verbosity. The verb and resource are specific, but it does not explicitly distinguish itself from sibling tools like count or find_similar_articles.
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 when one needs to search PubMed, but provides no explicit when-to-use vs alternatives or exclusions. No mention of when to choose this tool over count/find_similar_articles.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by mentioning rate-limit respect via max_concurrency, a meaningful behavioral trait. Yet it lacks a safety profile (read-only vs. mutation), return format, or error/partial-failure behavior, so it is not comprehensive.
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 sentences long, with the primary purpose front-loaded in the first sentence. Every clause contributes useful information (purpose, use case, operation types, rate-limit behavior) without extraneous fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the tool's purpose, operations, and rate limiting, but the absence of an output schema means the agent is left unaware of return values, error handling, or partial-failure behavior. For a batch tool with moderate complexity, this is a notable 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?
The schema already describes pmids and operations, and the description largely repeats the operations enum and max_concurrency default. It adds slight semantic value by explaining max_concurrency in relation to rate limits, but does not deepen understanding of pmids or operations beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Run multiple operations against the same set of PMIDs in one call.' It specifies the resource (PMIDs) and differentiates from siblings by emphasizing the combination of multiple operations in a single batch call, which is unique among the listed siblings.
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 'Helpful for systematic-review style workflows' gives clear context for when to use the tool. However, it does not explicitly name alternative tools or state when not to use it, so it falls short of full exclusion 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?
The description mentions the NCBI ID Converter API, offering a bit of external context, but it does not disclose response format, error behavior, or rate limits. With no annotations, the description carries the full burden, yet it only covers the basic conversion functionality.
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 that is direct and front-loaded, with no wasted words. It efficiently conveys the tool's core purpose.
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 the tool's simplicity and well-specified schema, the description is adequate for an agent to understand its function. It does not explain return format, but the purpose is unambiguous and the schema covers operational details like batch limits.
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 input schema fully describes each parameter with enums and descriptions, covering 100% of parameters. The description adds no additional meaning beyond naming the supported identifier types, which the schema already enumerates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts between PMID, PMCID, and DOI identifiers, specifying the verb 'Convert' and the resource. It distinguishes itself from sibling tools that fetch or search articles rather than convert ID types.
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 makes the tool's purpose evident and gives context for when to use it, but it does not explicitly state when not to use it or name alternative tools. The differentiation from siblings is implicit rather than explicit.
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?
The description discloses key behavioral traits: it is fast and retrieves no actual data. Without annotations, it carries the burden, but it doesn't mention potential rate limits, exact return format, or whether the count respects all query filters. It adds some value but not exhaustive context.
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 short sentences, highly efficient, and front-loaded with the main purpose. Every sentence adds value without unnecessary fluff.
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?
For a simple count tool with one parameter and no output schema, the description covers the essential purpose and usage. It could mention what the count represents (e.g., total matching entities across all pages) but is otherwise sufficient for a tool of this complexity.
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 input schema already provides 100% coverage for the single 'query' parameter with a helpful description including syntax support. The tool description adds no additional parameter semantics beyond what the schema states, so it stays at 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 clearly states the tool's purpose: 'Get only the count of search results'. It explicitly differentiates from the sibling 'search' tool by emphasizing it retrieves no actual data, only the count.
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 mentions it is 'Useful for refining search strategies' and notes it is 'Fast', implying it should be used when only the count is needed. However, it does not explicitly state when not to use it or name alternatives beyond this context.
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?
No annotations are provided, so the description carries the burden. It discloses the matching mechanism (MeSH terms and title-based similarity), but does not mention output format, error handling, or read-only nature. While the method detail adds some transparency, it lacks behavioral depth.
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 sentences: the first states the core function and method, the second states the intended use case. No wasted words, and key information is front-loaded.
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 (2 params, no output schema), and the description covers purpose and method adequately. However, without an output schema, it does not describe the return format or error behavior, which is a minor gap. Overall, it is sufficiently complete for an agent to invoke the tool 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 coverage is 100% with both parameters (pmid and retmax) clearly documented. The description adds no extra meaning beyond what the schema already provides, so baseline 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 clearly states the function: 'Find similar articles for a given PMID' using a specific method (MeSH terms and title-based similarity). This distinguishes it from siblings like search or fetch, 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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use it: 'Useful for literature review and related research discovery.' It does not explicitly name alternatives or exclusions, but the unique function makes the use case clear.
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 no annotations provided, the description must carry the behavioral burden. It discloses the key behavioral trait: returns compact RIS with minimal metadata, and explains the rationale (auto-fetch via PMID). It does not mention error handling or rate limits, but for a read-only export tool, this is adequate.
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 sentences long, front-loaded with the main purpose, and the second sentence adds necessary context about the minimal metadata. There is no redundancy or waste.
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?
For a simple tool with one parameter and no output schema, the description explains the return format (compact RIS) and the reason for it. It lacks explicit error behavior, but that is not critical for the tool's function.
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 already provides a description for the only parameter ('List of PubMed IDs (PMIDs)') with 100% coverage. The description adds no additional detail about parameter semantics, so it relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Export PubMed articles to RIS format') and specifically targets citation managers (EndNote/Zotero/Mendeley). This distinguishes it from siblings like 'fetch' or 'fetch_batch' which retrieve data rather than export to a specific format.
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?
It provides context for when to use the tool (for citation manager exports) and explains that the compact output is sufficient because citation managers auto-fetch via PMID. However, it does not explicitly describe when not to use it or mention alternative tools for full metadata retrieval.
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?
No annotations are provided, so the description must carry the transparency burden. It notes that the tool is 'OpenAI MCP compliant' and reinforces the single-PMID constraint, but does not disclose behavior for invalid PMIDs, rate limits, or the return format beyond 'abstract'. This leaves some ambiguity for unexpected inputs.
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 sentences, front-loads the core purpose, and includes a pointer to the batch alternative. No wasted words.
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?
For a one-parameter, no-output-schema tool, the description covers purpose and constraint well. It lacks explicit return structure and error handling, but the output is implicitly the abstract. Given the simplicity, it is mostly complete.
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% with a detailed description: 'Single PubMed ID (PMID) — NO arrays or comma-separated values.' The description adds the 'exactly one' constraint and batch usage, but the parameter meaning is already fully covered by the schema, so baseline 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 uses a specific verb ('Retrieve') and resource ('abstract for a single PMID'), clearly stating the scope. It distinguishes from siblings by explicitly stating 'Accepts exactly one PMID' and directing multi-PMID requests to fetch_batch.
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 provides an alternative for a different scenario: 'For multiple PMIDs, use fetch_batch.' This is a clear when-not and alternative. It also implies when to use (when you have a single PMID and need its abstract).
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 no annotations, the description carries the burden of behavioral disclosure. It states that the tool returns structured data per PMID and explains the effect of include_abstract=false with an example. This covers the core behavior, though it does not mention 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the main purpose, followed by a relevant parameter tip. No redundant wording or 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?
Given the tool's simplicity (2 params, no output schema or annotations), the description is mostly complete: it explains the batch behavior, the return shape, and the optional flag. It could be slightly more explicit about output field details or potential limitations, but overall sufficient for a straightforward fetch 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%, so parameters are already documented. The description adds value by clarifying the batch context for 'pmids' and providing a use-case example for 'include_abstract' beyond the schema's default-value explanation.
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 'Retrieve abstracts for multiple PMIDs in a single batch request' with a specific verb, resource, and scope. It distinguishes itself from siblings like 'fetch' (single-PMID) and 'get_full_text' by specifying batch abstract retrieval.
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 implies the primary use case (multiple PMIDs) and provides a concrete guideline for setting include_abstract=false when only full author lists are needed. However, it does not explicitly contrast with siblings like 'fetch' or 'batch_process'.
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 no annotations provided, the description carries the full transparency burden. It clearly states that iCite returns counts only and includes external citations, while pubmed uses elink and can return citing PMIDs. It also implies that include_citing_pmids is only effective with pubmed. It does not cover error handling or output format, but the core behavior is well disclosed.
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 redundancy. The first sentence states the core purpose; the second explains the key parameter choice and its benefit. Every clause adds value and the information is front-loaded.
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 relatively simple, has no output schema, and lacks annotations. The description covers the main use cases, the source distinction, and what to expect from each mode. It omits details like return structure or failure behavior, but these are less critical for a simple lookup tool and the description is otherwise adequate.
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 baseline is 3. The description adds meaning beyond the schema by explaining what 'icite' and 'pubmed' mean conceptually (external vs. internal citations, snowballing) and how they affect both the output and the include_citing_pmids parameter. This enriches the raw schema definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Get citation counts for PMIDs.' It clearly distinguishes between the two sources (iCite vs. PubMed), which differentiates this tool from sibling tools like 'count' or 'fetch'. The purpose is unambiguous and actionable.
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 gives explicit guidance on which source to use: default iCite for broad counts, and citing_source='pubmed' when PubMed-internal citations or citing PMIDs are needed. It explains the trade-off and a concrete use case (backward snowballing), but it does not explicitly contrast with sibling tools, so it falls short of full when/when-not guidance.
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

Copy to your README.md:

[![pubmed_mcp_server2 MCP server](https://glama.ai/mcp/servers/masa061580/pubmed_mcp_server2/badges/card.svg)](https://glama.ai/mcp/servers/masa061580/pubmed_mcp_server2)

Score Badge

Copy to your README.md:

[![pubmed_mcp_server2 MCP server](https://glama.ai/mcp/servers/masa061580/pubmed_mcp_server2/badges/score.svg)](https://glama.ai/mcp/servers/masa061580/pubmed_mcp_server2)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/masa061580/pubmed_mcp_server2'

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