Which integrations are available for this server?

Enables the validation and conversion of Digital Object Identifiers (DOIs) to PubMed identifiers (PMIDs) and supports DOI-specific field searching for biomedical research articles. Provides comprehensive access to over 36 million biomedical citations through tools for searching MEDLINE, life science journals, and online books, retrieving abstracts and full-text articles via PubMed Central, and managing citation data.

How do I use PubMed MCP Server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PubMed MCP Server Search for recent articles about mRNA vaccines and summarize the abstracts" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

PubMed MCP Server

by Augmented-Nature

Overview Schema Related Servers Score Discussions

TypeScript

Remote

PubMed MCP Server

A comprehensive Model Context Protocol (MCP) server that provides access to PubMed, NCBI's database of biomedical literature with over 36 million citations from MEDLINE, life science journals, and online books.

Developed by Augmented Nature

Overview

The PubMed MCP server exposes the full NCBI E-utilities and PubMed Central APIs through 16 specialized MCP tools, allowing you to search, retrieve, and analyze biomedical literature directly from your MCP-enabled environment.

Related MCP server: NCBI Literature Search MCP Server

Features

Search & Discovery Tools

search_articles - Search PubMed by keywords, authors, journals, dates, or MeSH terms with pagination
advanced_search - Complex queries with field-specific searches and boolean operators (AND/OR)
search_by_author - Find articles by specific author(s) with optional affiliation filtering
search_by_journal - Search within specific journals with date range filtering
search_by_mesh_terms - Search using Medical Subject Headings (MeSH) with major topic filtering
get_trending_articles - Get recently published articles in a specific field (last 30-365 days)

Article Retrieval Tools

get_article_details - Get comprehensive metadata and abstract for a specific PMID
get_abstract - Retrieve article abstract by PMID with basic metadata
get_full_text - Retrieve full text from PubMed Central (PMC) when available
batch_article_lookup - Retrieve multiple articles efficiently (up to 200 PMIDs)

Citation & Reference Tools

get_cited_by - Find articles that cite a specific PMID
get_references - Get reference list for an article
get_similar_articles - Find related articles based on content similarity
export_citation - Export citations in various formats (APA, MLA, Chicago, BibTeX, RIS)

Utility Tools

validate_pmid - Validate PubMed ID format and check if article exists
convert_identifiers - Convert between PMID, DOI, and PMC ID

Data Quality Features

Real-time access to 36+ million biomedical citations
Automatic rate limiting (3 req/s without API key, 10 req/s with key)
Comprehensive error handling with retry logic
Support for all PubMed search fields and operators
MeSH term integration for precise medical queries
Full-text access via PubMed Central when available

Installation

Prerequisites

Node.js 16+ (install from nodejs.org)
Optional: NCBI API key for higher rate limits (get from NCBI Account Settings)

Basic Configuration (No API Key)

{
  "mcpServers": {
    "pubmed-server": {
      "command": "node",
      "args": ["path/to/pubmed-server/build/index.js"],
      "autoApprove": [
        "search_articles",
        "get_article_details",
        "get_abstract",
        "validate_pmid"
      ]
    }
  }
}

With API Key (Recommended for Higher Rate Limits)

{
  "mcpServers": {
    "pubmed-server": {
      "command": "node",
      "args": ["path/to/pubmed-server/build/index.js"],
      "env": {
        "NCBI_API_KEY": "your_api_key_here",
        "NCBI_EMAIL": "your_email@example.com"
      },
      "autoApprove": [
        "search_articles",
        "get_article_details",
        "get_abstract",
        "validate_pmid",
        "search_by_author",
        "search_by_journal"
      ]
    }
  }
}

Usage Examples

Search for Recent CRISPR Research

{
  "query": "CRISPR gene editing",
  "max_results": 10,
  "sort": "pub_date"
}

Get Article Details

{
  "pmid": "41138228"
}

Advanced Search with Multiple Criteria

{
  "title": "machine learning",
  "author": "Smith J",
  "mesh_terms": ["Artificial Intelligence", "Diagnosis"],
  "boolean_operator": "AND",
  "max_results": 50
}

Search by Author with Affiliation

{
  "author_name": "Smith J",
  "affiliation": "Harvard Medical School",
  "max_results": 50
}

Search Within Specific Journal

{
  "journal_name": "Nature",
  "keywords": "cancer immunotherapy",
  "date_from": "2024/01/01",
  "date_to": "2025/12/31",
  "max_results": 25
}

Search by MeSH Terms

{
  "mesh_terms": ["COVID-19", "Vaccines"],
  "major_topic_only": true,
  "max_results": 50
}

{
  "field": "artificial intelligence in medicine",
  "days": 30,
  "max_results": 20
}

Get Full Text from PMC

{
  "pmcid": "PMC1234567"
}

Batch Article Lookup

{
  "pmids": ["41138228", "41137959", "41137488"]
}

Export Citation in BibTeX

{
  "pmid": "41138228",
  "format": "bibtex"
}

Find Citing Articles

{
  "pmid": "12345678",
  "max_results": 100
}

Convert Between Identifiers

{
  "identifier": "10.1080/15476286.2025.2577449",
  "identifier_type": "doi"
}

API Reference

Search Parameters

Common Parameters:

query - Search query (keywords, phrases, field tags)
max_results - Number of results (1-1000, default: 20)
start - Starting position for pagination (default: 0)
sort - Sort order: relevance, pub_date, author, journal

Date Parameters:

date_from - Start date (YYYY/MM/DD format)
date_to - End date (YYYY/MM/DD format)

Field Tags:

[Title] - Article title
[Author] - Author name
[Journal] - Journal name
[MeSH Terms] - Medical Subject Headings
[Abstract] - Abstract text
[Affiliation] - Author affiliation
[Publication Type] - Type of publication
[DOI] - Digital Object Identifier

Example: "Smith J[Author] AND cancer[Title]"

MeSH Terms

Medical Subject Headings (MeSH) is the NLM controlled vocabulary thesaurus used for indexing articles. Using MeSH terms provides more precise search results than keyword searches.

Common MeSH Categories:

Diseases
Chemicals and Drugs
Analytical, Diagnostic and Therapeutic Techniques
Anatomy
Organisms
Psychiatry and Psychology
Phenomena and Processes

Citation Formats

The server supports multiple citation formats:

APA - American Psychological Association
MLA - Modern Language Association
Chicago - Chicago Manual of Style
BibTeX - LaTeX bibliography format
RIS - Research Information Systems format

Response Format

All tools return structured JSON data including:

Article metadata (PMID, title, authors, journal, publication date)
Abstract text (when available)
MeSH terms and keywords
DOI and other identifiers
Citation information
Full-text availability status

PMID Format

All PMIDs must be numeric strings (e.g., "12345678")

Error Handling

The server includes comprehensive error handling for:

Network Issues: Automatic retry with exponential backoff
Rate Limiting: Automatic throttling to comply with NCBI policies
Invalid Parameters: Clear error messages for validation failures
API Errors: Proper HTTP status code handling
Missing Data: Graceful handling of unavailable fields

Common error responses include:

{
  "error": "Invalid PMID format: abc123",
  "isError": true
}

Development

Building from Source

# Install dependencies
npm install

# Build TypeScript to JavaScript
npm run build

# Development with watch mode
npm run watch

Key Dependencies

@modelcontextprotocol/sdk - MCP server framework
axios - HTTP client for API requests
xml2js - XML parsing for PubMed responses
TypeScript for type safety and development

Data Sources

E-utilities API: https://eutils.ncbi.nlm.nih.gov/entrez/eutils/ PubMed Central API: https://www.ncbi.nlm.nih.gov/pmc/tools/developers/ Coverage: 36+ million citations from MEDLINE, life science journals, and online books Data Updates: Real-time access to the latest publications

Rate Limits

Without API key: 3 requests per second
With API key: 10 requests per second

The server automatically handles rate limiting to comply with NCBI's usage policies.

Troubleshooting

Server Connection Issues:

# Test server manually
cd pubmed-server
node build/index.js
# Should show: "PubMed MCP Server running on stdio"

Invalid PMID Errors:
- Ensure PMIDs are numeric strings
- Example: "12345678" ✓, "PMID12345678" ✗
No Results Returned:
- Check search query syntax
- Try broader search terms
- Verify field tags are correct
Rate Limit Errors:
- Consider obtaining an NCBI API key
- Reduce request frequency
- Use batch operations when possible
Full Text Not Available:
- Not all articles have full text in PMC
- Check if article has a PMC ID
- Some articles may be behind paywalls

Research Use Cases

Literature Review: Comprehensive search across biomedical literature
Citation Analysis: Track citations and references for research impact
Systematic Reviews: Batch retrieval and analysis of multiple articles
Meta-Analysis: Collect data from multiple studies efficiently
Research Trends: Identify trending topics and recent publications
Author Research: Find all publications by specific researchers
Journal Analysis: Analyze publication patterns in specific journals
MeSH-Based Discovery: Precise medical subject searches

Compliance & Ethics

This server provides access to publicly available biomedical literature from PubMed. Users should:

Follow institutional policies for research and publication
Respect copyright and licensing terms for full-text articles
Cite sources appropriately in publications
Use data for legitimate research and educational purposes
Comply with NCBI's usage policies and rate limits

License

MIT License - See LICENSE file for details

Data Source: PubMed/NCBI (https://pubmed.ncbi.nlm.nih.gov) API Documentation: https://www.ncbi.nlm.nih.gov/books/NBK25501/ Server Version: 1.0.0

Available Tools

16 tools

advanced_searchC

Perform advanced search with field-specific queries and boolean operators

ParametersJSON Schema

Name	Required	Description
`title`	No	Search in article titles
`abstract`	No	Search in abstracts
`author`	No	Author name
`journal`	No	Journal name
`mesh_terms`	No	MeSH (Medical Subject Headings) terms
`publication_types`	No	Publication types (e.g., "Clinical Trial", "Review")
`boolean_operator`	No	Boolean operator to combine terms (default: AND)
`max_results`	No	Maximum results (default: 20)

TDQS

C2.8/5.0

Behavior2/5

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

No annotations are provided, and the description adds minimal behavioral context beyond what is in the schema. It does not disclose rate limits, authentication needs, or any side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise at one sentence, but it lacks structure and could be more informative. It fits in a single line but does not prioritize key details for tool selection.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 8 optional parameters and many sibling tools, the description provides minimal context. It does not explain how boolean operators work across fields, default behaviors, or how it compares to related search tools. Missing output schema details also reduce completeness.

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 each parameter well-described. The description adds that queries are 'field-specific' and use boolean operators, which is already evident from the boolean_operator enum and field parameters. No significant additional meaning.

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?

Description clearly states it performs 'advanced search with field-specific queries and boolean operators', indicating a specific functionality. However, it does not differentiate from sibling tools like search_articles, which may also offer field-specific searches.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus siblings such as search_articles or search_by_author. The description and schema imply it is for combining multiple fields, but context is missing.

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

batch_article_lookupB

Retrieve multiple articles efficiently (up to 200 PMIDs)

ParametersJSON Schema

Name	Required	Description	Default
`pmids`	Yes	Array of PubMed IDs

TDQS

B3.3/5.0

Behavior2/5

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

No annotations are provided, and the description lacks behavioral details such as read-only nature, error handling, output format, or side effects. The word 'efficiently' is vague.

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 very concise at one sentence, but could include more context about the output or constraints. It is not verbose, yet slightly under-specified.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given multiple sibling tools and no output schema, the description does not specify what is returned (e.g., article metadata), error behavior, or prerequisites. Incomplete for an agent to use effectively.

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 fully describes the pmids parameter (array, max 200), and the description repeats that limit but adds no additional meaning. Baseline 3 is appropriate given 100% schema coverage.

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 verb 'Retrieve' and resource 'multiple articles', and specifies the batch limit of 200 PMIDs, distinguishing it from single-article tools like get_article_details.

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 hints at batch efficiency but does not explicitly state when to use this tool versus alternatives like get_article_details or search_articles. Usage context is implied but not clearly defined.

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

convert_identifiersB

Convert between PMID, DOI, and PMC ID

ParametersJSON Schema

Name	Required	Description	Default
`identifier`	Yes	Identifier to convert (PMID, DOI, or PMC ID)
`identifier_type`	No	Type of input identifier (default: auto-detect)

TDQS

B3.4/5.0

Behavior2/5

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

No annotations provided, and the description gives no behavioral details beyond conversion; lacks information on idempotency, error handling, or side effects.

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?

Single sentence conveying core functionality efficiently, but could be slightly more informative without verbosity.

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?

No output schema or return value description; missing details on output format and error behavior, but adequate for a simple conversion tool.

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 description adds no additional meaning; baseline score 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 verb 'Convert' and the specific identifier types (PMID, DOI, PMC ID), distinguishing it from sibling search and retrieval tools.

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?

No explicit guidance on when to use this tool versus alternatives; usage is implied but not contextualized among sibling tools.

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

export_citationA

Export citation in various formats (APA, MLA, Chicago, BibTeX, RIS)

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID
`format`	No	Citation format (default: apa)

TDQS

A3.8/5.0

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 implies a simple read operation (export citation) but does not disclose if the operation is idempotent, requires authentication, or has rate limits. However, the tool is straightforward enough that an agent might infer basic behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, concise sentence that conveys all essential information without redundancy. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple with two parameters and no output schema. The description explains inputs and outputs adequately, though it does not specify the return format (e.g., plain text string) or any post-processing expectations. Given the simplicity, this is a minor 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?

The schema covers 100% of parameters with descriptions. The description adds value by specifying the default format ('apa'), which is not indicated in the schema enum. It also lists the available formats, reinforcing the parameter options.

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: exporting citations. It lists specific output formats (APA, MLA, Chicago, BibTeX, RIS) and the required input (PubMed ID). This distinguishes it from sibling tools like 'get_article_details' which do not offer citation export.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool over alternatives. For example, it doesn't mention if it should be used when a formatted citation string is needed, or if other tools like 'get_cited_by' should be used for related tasks. No exclusions or alternative suggestions are given.

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

get_abstractB

Retrieve article abstract by PMID

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID

TDQS

B3.2/5.0

Behavior2/5

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

No annotations provided. The description does not disclose behavior like handling of invalid PMIDs, rate limits, or authentication requirements.

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 a single concise sentence, no wasted words. However, it lacks structured formatting or helpful hints.

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?

For a simple retrieval tool with one parameter and no output schema, the description is minimally adequate. It doesn't specify what is returned or edge cases.

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% for the single parameter 'pmid' ('PubMed ID'). The description adds no additional meaning beyond the schema.

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

Purpose5/5

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

The description clearly states the verb 'Retrieve', the resource 'article abstract', and the identifier 'PMID'. This distinguishes it from siblings like get_full_text or get_article_details.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. No mention of limitations (e.g., only returns abstract, not full text) or prerequisites (valid PMID).

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

get_article_detailsA

Get comprehensive metadata and abstract for a specific article by PMID

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID (e.g., "12345678")

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, and the description does not detail behavioral traits such as rate limits, authentication, or the exact scope of 'metadata', which leaves some ambiguity.

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, well-structured sentence with no wasted words, efficiently conveying the tool's purpose.

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?

Though adequate for a simple tool with one parameter, the description lacks details about what 'comprehensive metadata' includes and the return format, especially given no output schema.

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 a clear description for 'pmid'. The description adds no additional meaning beyond the schema, meeting the baseline for a simple parameter.

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 verb 'Get' and the resource 'comprehensive metadata and abstract', which distinguishes it from sibling tools like 'get_abstract' that likely return only the abstract.

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 does not explicitly state when to use this tool versus alternatives like 'get_abstract' or 'get_full_text', though the naming provides some implicit guidance.

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

get_cited_byA

Find articles that cite a specific PMID

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID
`max_results`	No	Maximum citing articles to return (default: 100)

TDQS

A3.5/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the burden. It does not disclose behavioral traits such as pagination, rate limits, or what happens with no results. The tool is simple but still lacks basic 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?

The description is a single, front-loaded sentence with no wasted words. It efficiently communicates the tool's purpose.

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?

Given the tool's low complexity (2 parameters) and no output schema, the description is acceptable but minimal. It lacks context on return format, pagination, or limits, which would help an agent use it correctly.

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

Parameters3/5

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

Schema coverage is 100% with descriptions for both pmid and max_results. The description adds no additional meaning beyond the schema, meeting baseline expectations but not exceeding them.

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 'Find articles that cite a specific PMID' clearly states the action ('find') and the resource ('articles that cite a specific PMID'). It distinctly separates from siblings like get_references, which retrieves references of an article.

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

Usage Guidelines3/5

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

Usage is implied by the description (use to find citing articles for a PMID), but there is no explicit guidance on when not to use, prerequisites, or alternatives (e.g., might be better to use search_articles for broader queries).

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

get_full_textB

Retrieve full text from PubMed Central (PMC) when available

ParametersJSON Schema

Name	Required	Description	Default
`pmcid`	Yes	PMC ID (e.g., "PMC1234567" or "1234567")

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, so description must disclose behavior. 'When available' hints at conditional success, but no details on failure behavior, prerequisites, or side effects.

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?

One efficient sentence with no unnecessary words. Could benefit from slightly more detail, but remains concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so description should explain return values and error conditions. Only mentions availability, lacking completeness for a simple but conditional tool.

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

Parameters3/5

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

Schema coverage is 100% and parameter description in schema is adequate. The description adds no extra meaning beyond 'when available', 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 action ('Retrieve') and resource ('full text from PubMed Central (PMC)'), and distinguishes it from siblings like 'get_abstract'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives. No mention of checking availability or fallback options if PMC full text is not available.

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

get_referencesC

Get reference list for an article

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID
`max_results`	No	Maximum references to return (default: 100)

TDQS

C2.6/5.0

Behavior2/5

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

No annotations are present, and the description does not disclose any behavioral traits (e.g., rate limits, pagination behavior, sorting, or what fields are returned). A mutation or data retrieval tool should provide more context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, clear sentence with no unnecessary words. It is appropriately concise for a simple operation, though it could be slightly expanded with key details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (list retrieval with pagination options) and lack of output schema, the description is too sparse. It fails to mention behavior like default limit, ordering, or the format of returned references, leaving the agent with incomplete information.

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?

Input schema has 100% description coverage for both parameters. The description adds no extra meaning beyond what the schema already provides, so baseline of 3 is appropriate.

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

Purpose3/5

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

The description states a clear verb ('Get') and resource ('reference list for an article'), but does not distinguish this from sibling tools like 'get_cited_by' or 'get_similar_articles', which also deal with related articles.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as 'get_cited_by' or 'get_article_details', nor any prerequisites or exclusions.

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

get_similar_articlesB

Find related articles based on content similarity

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID
`max_results`	No	Maximum similar articles (default: 20)

TDQS

B3.1/5.0

Behavior2/5

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

No annotations provided, and description lacks details about behavior (e.g., algorithmic basis, limitations, authentication needs). Only states 'based on content similarity' without further 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?

Single sentence is concise and front-loaded. However, it may be too brief for sufficient information, but not overly verbose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Description lacks information about return format, pagination, rate limits, or any additional constraints. Given no output schema and no annotations, the description is incomplete for a tool with two parameters.

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?

Input schema covers 100% of parameters with clear names and descriptions. The description adds no extra meaning beyond the schema, so baseline score 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?

Description clearly states 'Find related articles based on content similarity', which is a specific verb+resource. It distinguishes from sibling tools like search_articles (query-based) and get_article_details (single article details).

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as search_articles or get_cited_by. The description does not provide context for optimal usage.

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

get_trending_articlesA

Get recently published or trending articles in a specific field

ParametersJSON Schema

Name	Required	Description
`field`	Yes	Research field or topic
`days`	No	Number of days to look back (default: 30)
`max_results`	No	Maximum results (default: 20)

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description must disclose behavioral traits. It fails to explain what 'trending' means algorithmically, whether results are sorted, or any potential side effects. The description is too terse to be behaviorally transparent.

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, front-loaded sentence with no wasted words. Every part contributes to understanding the tool's core purpose.

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?

Given the tool's simplicity (3 params, no output schema), the description covers the basic purpose but omits details like sorting order, interpretation of 'trending', and any default behavior. Adequate but not fully 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 coverage is 100%, so the schema already documents all parameters (field, days, max_results). The description adds no extra meaning beyond the schema; it only echoes 'field'. 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 tool retrieves 'recently published or trending articles in a specific field'. It uses a specific verb ('get') and resource ('articles') and differentiates from siblings like 'search_articles' which is broader, by focusing on recency/trending.

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 for finding recent/trending articles but does not explicitly state when to use this tool versus alternatives (e.g., 'search_articles' for general queries). No explicit when-not-to-use guidance is provided.

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

search_articlesB

Search PubMed for articles by keywords, authors, journals, dates, or MeSH terms. Returns PMIDs and basic metadata.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search query (e.g., "cancer treatment", "Smith J[Author]", "Nature[Journal]")
`max_results`	No	Maximum number of results to return (1-1000, default: 20)
`start`	No	Starting position for pagination (default: 0)
`sort`	No	Sort order
`date_from`	No	Start date for date range (YYYY/MM/DD format)
`date_to`	No	End date for date range (YYYY/MM/DD format)

TDQS

B3.1/5.0

Behavior2/5

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

With no annotations, the description must carry the full burden. It states the return type (PMIDs and basic metadata) but lacks disclosure on important behaviors like pagination limits, whether it's read-only, or any authentication requirements.

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, direct and efficient. Every word adds value, no redundancy.

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?

Given 6 parameters and no output schema or annotations, the description is adequate but incomplete. It doesn't cover pagination behavior, error handling, or detailed output format. The schema helps, but the description could be richer.

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 baseline is 3. The description adds minimal value beyond the schema, merely listing searchable fields without explaining query syntax or parameter interactions. It does not compensate for any gaps since there are none.

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 searches PubMed for articles by various criteria and returns PMIDs and basic metadata. It implies a general-purpose search capability, distinguishing it from specialized siblings like search_by_author or search_by_journal, though not explicitly.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives like advanced_search or search_by_mesh_terms. There is no mention of when not to use it or which sibling to choose for specific needs.

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

search_by_authorB

Find articles by specific author(s)

ParametersJSON Schema

Name	Required	Description
`author_name`	Yes	Author name (e.g., "Smith J", "John Smith")
`affiliation`	No	Author affiliation/institution (optional)
`max_results`	No	Maximum results (default: 50)

TDQS

B3/5.0

Behavior2/5

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

Without annotations, the description carries full burden but only provides basic purpose. No details on behavior like pagination, sorting, 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.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One sentence is concise but lacks any structure or additional context. It is front-loaded but does not earn its place with added value beyond the name.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 3 parameters and no output schema, the description fails to cover return format, pagination, or edge cases. It is insufficient for complete understanding.

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?

All three parameters have descriptions in the schema (100% coverage), so the description adds no additional meaning. Baseline score of 3 applies.

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

Purpose5/5

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

The description clearly states the verb 'Find' and the resource 'articles by specific author(s)', distinguishing it from sibling tools like 'search_by_journal' or 'search_by_mesh_terms'.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives such as 'search_articles' or 'advanced_search'. The description omits any context for selection.

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

search_by_journalA

Search articles within specific journal(s)

ParametersJSON Schema

Name	Required	Description
`journal_name`	Yes	Journal name or abbreviation
`keywords`	No	Additional keywords to search within the journal
`date_from`	No	Start date (YYYY/MM/DD)
`date_to`	No	End date (YYYY/MM/DD)
`max_results`	No	Maximum results (default: 50)

TDQS

A3.5/5.0

Behavior3/5

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

With no annotations provided, the description bears full burden for behavioral disclosure, but it only describes the basic function without detailing behavior like search scope, error handling, or result format, leaving significant gaps.

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 a single sentence, highly concise with no wasted words; while efficient, it could be more structured or front-loaded with critical information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of output schema, the description should explain return values or behavior, but it does not. The tool has moderate complexity (5 parameters), yet the description leaves the agent uninformed about results or side effects.

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?

All five parameters are fully described in the input schema (100% coverage), so the description adds no extra meaning beyond the schema; baseline score 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 'Search articles within specific journal(s)' clearly identifies the core action (search) and resource (articles), and specifies the filter (specific journals), effectively distinguishing it from sibling tools like 'search_articles' and 'search_by_author'.

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 a journal name is known, but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or context about its suitability compared to sibling search tools.

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

search_by_mesh_termsC

Search using Medical Subject Headings (MeSH) terms

ParametersJSON Schema

Name	Required	Description
`mesh_terms`	Yes	MeSH terms to search for
`major_topic_only`	No	Only return articles where MeSH term is a major topic (default: false)
`max_results`	No	Maximum results (default: 50)

TDQS

C2.9/5.0

Behavior2/5

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

No annotations provided, and description only says 'search'. No disclosure of read-only nature, result ordering, or pagination behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence that is direct and efficient. Could benefit from a brief additional sentence on usage.

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?

No output schema; description does not explain return format, pagination, or limitations. Adequate for a simple search but missing details.

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 provides 100% description coverage for all three parameters. Description adds minimal value beyond repeating the MeSH concept.

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 searches using MeSH terms. It distinguishes from sibling tools like search_articles by specifying the controlled vocabulary, but could be more explicit about returning articles.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs. siblings like advanced_search or search_by_author. No mention of prerequisites or context.

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

validate_pmidB

Validate PubMed ID format and check if article exists

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID to validate

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations, the description should fully explain behavior. It does not disclose what the tool returns (e.g., boolean, status message) or how it handles invalid PMIDs (error vs. false). This lack of detail hinders the agent's ability to interpret results.

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, front-loaded sentence with no unnecessary words. It conveys the core purpose efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite low complexity, the description omits critical details about output and error handling. For a validation tool, the agent needs to know what the return value looks like to make decisions. The description is incomplete for practical use.

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?

The schema already describes the single parameter with 100% coverage. The tool description adds value by clarifying that the tool both validates format and checks existence, which goes beyond the parameter description alone.

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 (validate format and check existence) on a specific resource (PubMed ID). It distinguishes from siblings like get_article_details or batch_article_lookup, which retrieve data rather than validate.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives such as get_article_details for detailed information. There is no mention of prerequisites or exclusions.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

16 tool updatesv1.0.0May 7, 2026
- First observedadvanced_search
- First observedbatch_article_lookup
- First observedconvert_identifiers
- First observedexport_citation
- First observedget_abstract
- First observedget_article_details
- First observedget_cited_by
- First observedget_full_text
- First observedget_references
- First observedget_similar_articles
- First observedget_trending_articles
- First observedsearch_articles
- First observedsearch_by_author
- First observedsearch_by_journal
- First observedsearch_by_mesh_terms
- First observedvalidate_pmid

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0

Disambiguation4/5

Most tools have distinct purposes, but there is slight overlap between 'get_abstract' and 'get_article_details' (the latter includes abstract), and between 'advanced_search' and 'search_articles' (advanced search allows field-specific queries). However, descriptions clearly differentiate them.

Naming Consistency4/5

The naming follows a mostly consistent verb_noun pattern, with 'search_by_*' for specific field searches and 'get_*' for retrieval. However, a few tools like 'advanced_search', 'batch_article_lookup', and 'convert_identifiers' deviate from the prefix pattern.

Tool Count5/5

16 tools is well-scoped for a PubMed server covering searching, retrieval, citation, and related articles. Each tool serves a clear purpose without being excessive.

Completeness5/5

The tool set covers the full lifecycle of PubMed access: search by various criteria, retrieve metadata/abstract/full text, export citations, convert identifiers, and find related articles. No obvious gaps for a read-only API.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Pubmed A
io.github.pipeworx-io
PubMed MCP — wraps the NCBI E-utilities API (biomedical literature, free, no auth)
Research & Data Biology & Medicine Search
4021
lineex-pubmed-mcp-smithery
ai.smithery
Search PubMed with precision using keyword and journal filters and smart sorting. Uncover MeSH ter…
Research & Data Search Biology & Medicine
21
PubMed / MEDLINE Literature Search A
com.olyport
Search biomedical literature, get article details, find related articles, and explore MeSH terms
Research & Data Biology & Medicine Search
52
Nih Reporter A
io.github.pipeworx-io
NIH RePORTER MCP — every NIH-funded research project (free, no auth)
Government Data Research & Data
402

Related MCP Servers

PubMed-MCP-Server
Research & Data Bioinformatics
JackKuo666
A
license
Not graded
quality
F
maintenance
🔍 Enable AI assistants to search, access, and analyze PubMed articles through a simple MCP interface.
Updated a year ago (2025-05-08 12:45 UTC)
127
MIT
NCBI Literature Search MCP
Research & Data Search Biology & Medicine
vitorpavinato
F
license
Not graded
quality
D
maintenance
Provides seamless access to over 35 million PubMed scientific articles through natural language queries for research discovery and analysis. It enables tools for advanced searches, retrieving article details, and exploring related research within the life sciences and biomedical fields.
Updated a year ago (2025-06-28 20:05 UTC)
12
-
mcp-pubmed
Research & Data Biology & Medicine Search
PetrefiedThunder
A
license
A
quality
D
maintenance
An MCP server that provides access to PubMed and NCBI's biomedical literature database for searching articles, retrieving metadata, and tracking citations. It enables users to explore related research, browse MeSH vocabulary, and find free full-text links.
Updated 3 months ago (2026-06-01 20:42 UTC)
6
MIT
mcp-pubmed
Research & Data Biology & Medicine Search
benoitleq
A
license
A
quality
D
maintenance
An MCP server that provides direct access to PubMed and PubMed Central via the NCBI E-utilities API. It enables AI models to search biomedical literature, retrieve detailed article metadata, and download open-access full texts.
Updated 5 months ago (2026-03-28 09:15 UTC)
5
MIT

Appeared in Searches

PubMed Biomedical Literature Search

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/Augmented-Nature/PubMed-MCP-Server'

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

PubMed MCP Server

Overview

Features

Search & Discovery Tools

Article Retrieval Tools

Citation & Reference Tools

Utility Tools

Data Quality Features

Installation

Prerequisites

Basic Configuration (No API Key)

With API Key (Recommended for Higher Rate Limits)

Usage Examples

Search for Recent CRISPR Research

Get Article Details

Advanced Search with Multiple Criteria

Search by Author with Affiliation

Search Within Specific Journal

Search by MeSH Terms

Get Trending Articles

Get Full Text from PMC

Batch Article Lookup

Export Citation in BibTeX

Find Citing Articles

Convert Between Identifiers

API Reference

Search Parameters

MeSH Terms

Citation Formats

Response Format

PMID Format

Error Handling

Development

Building from Source

Key Dependencies

Data Sources

Rate Limits

Troubleshooting

Research Use Cases

Compliance & Ethics

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Appeared in Searches

Latest Blog Posts

MCP directory API