Which integrations are available for this server?

Provides tools for searching PubMed for medical literature, retrieving complete abstracts, and searching within open-access PubMed Central (PMC) articles. It includes features for pagination and accessing search history.

How do I use Enhanced PubMed MCP Server?

1. Click on "Deploy 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., "@Enhanced PubMed MCP Server Search for open access articles about AI in medical imaging" 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.

Enhanced PubMed MCP Server

by masa061580

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Enhanced PubMed MCP Server

🔬 No Python Required - Pure Node.js implementation of PubMed search MCP server

Quick Start

# Claude Desktop Configuration
{
  "mcpServers": {
    "pubmed": {
      "command": "npx",
      "args": ["-y", "enhanced-pubmed-mcp-server"]
    }
  }
}

Related MCP server: PubMed MCP Server

Features

✅ No Python Dependencies - Pure Node.js implementation
🔬 Enhanced PubMed Search - Complete abstracts, MeSH terms, keywords
📖 PMC Full-Text Search - Search within open access articles
💾 Search History - SQLite database for persistent storage
🔓 Open Access Detection - Identify freely available articles
🌐 Cross-Platform - Works on Windows, macOS, and Linux

Usage

Command Line

# Direct execution (no installation needed)
npx enhanced-pubmed-mcp-server

# Help and version info
npx enhanced-pubmed-mcp-server --help
npx enhanced-pubmed-mcp-server --version

Claude Desktop Integration

Add to your claude_desktop_config.json:

{
  "mcpServers": {
    "pubmed": {
      "command": "npx",
      "args": ["-y", "enhanced-pubmed-mcp-server"]
    }
  }
}

Configuration file locations:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Available Tools

search_pubmed(query, max_results) - Enhanced PubMed search
get_full_abstract(pmid) - Complete abstract retrieval
search_pmc_fulltext(query, max_results) - PMC full-text search
retrieve_pubmed_results(search_id, page) - Paginated results
list_pubmed_searches() - Search history

Search Examples

// Basic search
search_pubmed("COVID-19 vaccine", 10)

// Field-specific search
search_pubmed("CRISPR[Title]", 5)

// Date range search
search_pubmed("cancer therapy AND 2023[Date - Publication]", 15)

// Full-text search in open access articles
search_pmc_fulltext("machine learning medical imaging", 20)

// Get complete abstract
get_full_abstract("35504917")

Requirements

Node.js 14.0.0 or higher
Internet connection for PubMed API access

License

MIT

Repository

https://github.com/yourusername/enhanced-pubmed-mcp-server

Available Tools

6 tools

get_abstract_helpA

Get help and examples for using the get_full_abstract function

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

With no annotations, the description carries the full burden. It only states it's help, not disclosing any behavioral traits like idempotency, rate limits, or side effects. Minimal info.

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?

Single sentence, perfectly concise, front-loaded with purpose. 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?

Given zero parameters and no output schema, the description adequately covers purpose. Could specify format of help (e.g., text, examples) but not necessary for low complexity.

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?

No parameters exist, so baseline is 4. Description adds no param info, but none is needed. Schema coverage is 100% (empty 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 provides help and examples for a specific function (get_full_abstract), distinguishing it from siblings like get_full_abstract itself. Verb 'Get' and resource 'help and examples' are specific.

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?

Implied usage: use when needing help with get_full_abstract. No explicit when-not or alternatives provided, but context from sibling names clarifies the ecosystem.

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

get_full_abstractA

Get the complete abstract for a specific PMID

ParametersJSON Schema

Name	Required	Description	Default
`pmid`	Yes	PubMed ID of the article

TDQS

A3.6/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 fully disclose behavioral traits. It only states the action without mentioning side effects, error handling, rate limits, or prerequisites. Simple but insufficient for full 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, well-structured sentence that is front-loaded and conveys the essential information without 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 covers the core purpose. However, it could mention the expected return format or any exclusions (e.g., only for PubMed IDs).

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% and the parameter is documented. The description adds little value beyond reiterating the parameter purpose, resulting in a baseline score of 3.

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 the complete abstract for a specific PMID, which is a specific verb and resource. It distinguishes from sibling tools like search_pubmed and get_abstract_help by specifying the unique action and input.

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 PMID is available, but provides no explicit guidance on when to use this tool versus alternatives like search_pubmed or retrieve_pubmed_results. It lacks when-not or context for selection.

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

list_pubmed_searchesB

List all previously stored PubMed and PMC searches

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, description must disclose behavior; it only indicates the tool lists stored searches but omits details like returned fields, authentication needs, or pagination.

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?

Single sentence conveys the purpose without any wasted words; appropriately sized.

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?

Lacks completeness as there is no output schema; description fails to specify what information is returned for each search, which is essential for a list 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?

No parameters exist, and schema coverage is 100%; description adds no param info, but baseline for zero params is 4.

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 'list' and resource 'previously stored PubMed and PMC searches', clearly distinguishing from sibling tools like search_pubmed or retrieve_pubmed_results.

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; simply states the action without context or exclusions.

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

retrieve_pubmed_resultsB

Retrieve previously stored PubMed search results with pagination

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number to retrieve (starts at 1)
`search_id`	Yes	ID of the stored search to retrieve
`results_per_page`	No	Number of results per page (default: 10, max: 50)

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 only mentions pagination but does not disclose read-only nature, side effects, error handling, or data requirements beyond the schema.

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?

Single sentence of 8 words, no redundancy. Front-loaded with verb and resource, efficient.

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?

With 3 parameters and no output schema, description is minimal. It does not explain the return value format or error cases, making it incomplete for a retrieval 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 covers all 3 parameters with descriptions (100% coverage), so baseline is 3. Description adds no extra parameter meaning beyond the schema's own descriptions.

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 the resource ('previously stored PubMed search results') with pagination, distinguishing it from siblings like search_pubmed and list_pubmed_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 guidance on when to use this tool vs alternatives (e.g., after a search, instead of search_pubmed). The description lacks explicit conditions or exclusions.

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

search_pmc_fulltextC

Search PubMed Central (PMC) for full-text open access articles

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query for full-text search
`max_results`	No	Maximum number of results (default: 10, max: 50)

TDQS

C2.9/5.0

Behavior1/5

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

With no annotations, the description carries the full burden but discloses no behavioral traits. It does not mention rate limits, authentication needs, response format, or any operational constraints beyond the simple search action.

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 with no waste. However, it is too minimal, missing important details that would justify a higher score. It is appropriately front-loaded but could be expanded.

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?

For a search tool with two parameters and no output schema, the description is incomplete. It does not explain return format, result ordering, or limitations, leaving the agent without sufficient context to invoke the tool 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?

Schema description coverage is 100%, and the description simply repeats the schema text for both parameters without adding new meaning or context. Baseline 3 is appropriate as no additional value is provided.

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 searches PubMed Central for full-text open access articles, specifying the resource (PMC) and scope (full-text, open access), which distinguishes it from sibling tools like search_pubmed that likely search titles/abstracts.

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 search_pubmed or get_abstract_help. The description implies it's for full-text searches but lacks explicit context on exclusion criteria or prerequisites.

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

search_pubmedB

Enhanced PubMed search with complete abstract retrieval and PMC integration

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Search query to match against papers
`max_results`	No	Maximum number of results (default: 10, max: 500)

TDQS

B3.3/5.0

Behavior3/5

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

With no annotations, the description must convey behavioral traits. It indicates the tool performs search and retrieves abstracts, implying a read operation. However, it does not detail whether results include full abstracts inline, how PMC integration works, or any potential side effects. The description is moderately transparent but lacks 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 a single, front-loaded sentence with no redundant words. It efficiently conveys the tool's primary function and distinguishing features, earning its place without 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?

Given no output schema and moderate sibling overlap, the description is somewhat incomplete. It fails to specify the output format, pagination behavior, or how 'complete abstract retrieval' is achieved. While it touches on key features, more context is needed for full clarity.

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% (both parameters have descriptions). The description adds general context ('complete abstract retrieval and PMC integration') but does not augment parameter-specific semantics beyond the schema. Given full coverage, baseline score 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 identifies the tool as a PubMed search enhanced with complete abstract retrieval and PMC integration. It distinguishes from sibling tools like 'search_pmc_fulltext' (which searches PMC full text) and 'retrieve_pubmed_results' (which may just fetch results). However, 'Enhanced' is slightly vague and the scope of 'complete abstract retrieval' is not fully elaborated.

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 is provided on when to use this tool versus its siblings (e.g., 'get_full_abstract', 'search_pmc_fulltext'). The description mentions features but does not indicate scenarios where this tool is preferred or when alternatives are more appropriate.

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.

6 tool updatesv1.0.3Mar 7, 2026
- First observedget_abstract_help
- First observedget_full_abstract
- First observedlist_pubmed_searches
- First observedretrieve_pubmed_results
- First observedsearch_pmc_fulltext
- First observedsearch_pubmed

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.5/5.0

Scored 2026-06-04 08:00 across 6 tools

Disambiguation3/5

Some tools have overlapping purposes: search_pubmed includes 'complete abstract retrieval', which duplicates get_full_abstract. Additionally, get_abstract_help is a helper for get_full_abstract but could cause confusion with get_full_abstract. Overall, most tools are distinct but these overlaps reduce clarity.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_full_abstract, search_pubmed). The naming is predictable and readable, with no mixing of conventions.

Tool Count5/5

With 6 tools, the count is well-scoped for a PubMed search and retrieval server. It covers core functionalities without being bloated or too sparse.

Completeness4/5

The server covers searching (PubMed and PMC), retrieving stored results, listing searches, and getting abstracts. A notable minor gap is the lack of a delete or clear function for stored searches/results, but the core workflows are complete.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Reddit Discussion

Related Servers

Related MCP Connectors

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
pubmed-mcp-server A
io.github.cyanheads
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
Search Research & Data Biology & Medicine
114148
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 A
io.github.pipeworx-io
PubMed MCP — wraps the NCBI E-utilities API (biomedical literature, free, no auth)
Research & Data Biology & Medicine Search
4321

Related MCP Servers

PubMed MCP Server
Search Research & Data
ncukondo
A
license
B
quality
D
maintenance
Enables searching and retrieving scientific articles from PubMed using NCBI E-utilities API with features like rate limiting and caching.
Updated 9 months ago (2025-12-11 07:34 UTC)
3
33 npm
MIT
PubMed MCP Server
Research & Data Search Biology & Medicine
emi-dm
F
license
A
quality
D
maintenance
Enables searching and retrieving detailed information from PubMed articles using the NCBI Entrez API. Supports configurable search parameters including title/abstract filtering and keyword expansion to find relevant scientific publications.
Updated a year ago (2025-09-25 11:38 UTC)
1
-
PubMed MCP Server
Research & Data Biology & Medicine Search
aglitch120
A
license
Not graded
quality
D
maintenance
Enables comprehensive biomedical literature research through PubMed database access with advanced search, full-text retrieval, citation analysis, and batch processing capabilities. Supports both local deployment and cloud hosting for seamless integration with AI assistants.
Updated a year ago (2025-10-27 10:15 UTC)
1
MIT
PubMed MCP Server
Research & Data Biology & Medicine Search
aeghnnsw
F
license
Not graded
quality
C
maintenance
Enables searching PubMed's biomedical literature database and retrieving article metadata, abstracts, and full content through the E-utilities API. Supports advanced queries, batch operations, and multiple output formats with automatic rate limiting.
Updated a year ago (2025-06-26 16:45 UTC)
2
-