Enables searching PubMed by keyword with filters (date range, publication type, sorting, pagination) and fetching full article details by PMID, including authors, abstract, MeSH terms, and references.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@PubMed MCP Server search for recent papers on CRISPR cancer therapy"
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 服务器，基于 Model Context Protocol 构建，让 AI Agent 直接搜索和阅读 PubMed 学术文献。
无需 NCBI API Key，直接爬取 PubMed 公开网页接口。
将本仓库 Git 地址发送给你的 Agent：
https://github.com/wjixiang/pubmed-mcp.gitAgent 会自动克隆、安装依赖、构建并启动 MCP 服务器。
构建完成后，在 Claude Desktop 等 MCP 客户端中配置：
{
"mcpServers": {
"pubmed": {
"command": "node",
"args": ["/path/to/pubmed-mcp/dist/mcp/index.js"]
}
}
}Tools（Agent 可调用的工具）
工具 | 说明 |
| 按关键词搜索 PubMed，支持日期范围、文章类型过滤、排序、分页 |
| 按 PMID 获取完整文章记录（作者、摘要、MeSH、参考文献等） |
Resources（可读取的数据资源）
URI 模板 | 说明 |
| 以文本形式提供文章详情 |
Prompts（预设提示模板）
名称 | 说明 |
| 引导 Agent 对指定主题进行结构化文献综述 |
| 引导 Agent 总结指定文章 |
pnpm install
pnpm build # 构建库 + MCP 服务器
pnpm start:mcp # 启动 MCP 服务器
pnpm type-check # TypeScript 类型检查
pnpm test:run # 运行全部测试
pnpm test:e2e # E2E 测试（需要网络，访问真实 PubMed）Related MCP server: PubMed MCP Server
An MCP server for PubMed literature retrieval, built on Model Context Protocol. Enables AI Agents to directly search and read PubMed academic literature.
No NCBI API Key required — scrapes the public PubMed web interface directly.
Send this repository's Git URL to your Agent:
https://github.com/wjixiang/pubmed-mcp.gitThe Agent will automatically clone, install dependencies, build, and launch the MCP server.
After building, configure in Claude Desktop or other MCP clients:
{
"mcpServers": {
"pubmed": {
"command": "node",
"args": ["/path/to/pubmed-mcp/dist/mcp/index.js"]
}
}
}Tools (callable by Agent)
Tool | Description |
| Search PubMed by keyword, with date range filters, publication type filters, sorting, and pagination |
| Fetch full article record by PMID — authors, abstract, MeSH terms, references, and more |
Resources (readable data)
URI Template | Description |
| Article details as plain text |
Prompts (pre-built templates)
Name | Description |
| Guide the Agent to conduct a structured literature review on a given topic |
| Guide the Agent to summarize a specific article |
pnpm install
pnpm build # Build library + MCP server
pnpm start:mcp # Start MCP server
pnpm type-check # TypeScript type checking
pnpm test:run # Run all tests
pnpm test:e2e # E2E tests (requires network, hits live PubMed)MIT
Fetch the full record of a PubMed article by its PMID. Returns title, authors with affiliations, abstract, keywords, MeSH terms, references, similar articles, publication types, full-text sources, journal info, and more.
| Name | Required | Description | Default |
|---|---|---|---|
| pmid | Yes | PubMed ID (e.g. "33423454") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool as read-only and open-world, and the description adds useful context about the specific fields returned (title, authors, abstract, etc.), which goes beyond the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the purpose front-loaded. The second sentence lists return fields; while somewhat lengthy, it is still concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no nested objects) and the comprehensive list of return fields in the description, the description fully covers the needed information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description does not add parameter details beyond what the schema provides (e.g., 'by its PMID' mirrors the schema description). Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Fetch') and resource ('full record of a PubMed article'), clearly distinguishing it from the sibling tool pubmed_search, which is for searching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (fetching details for a known PMID) and distinguishes from pubmed_search, but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PubMed for articles by keyword. Returns a list of article profiles with PMID, title, authors, journal citation, and snippet. Supports date-range filters (YYYY:YYYY), publication-type filters (e.g. "clinical trial", "review"), sorting, and pagination.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (1-indexed, defaults to 1) | |
| sort | No | Sort order: match (relevance), date, pubdate, fauth (first author), jour (journal) | match |
| term | Yes | Search query (free-text, e.g. "cancer immunotherapy") | |
| filter | No | Filters: date ranges like "2020:2024", publication types like "clinical trial", "review", "systematic review", "meta-analysis", "randomized controlled trial", "books and documents" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true and openWorldHint=true. Description adds that it returns a list with specific fields and supports filtering/sorting/pagination, which goes beyond annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with main purpose and return value, followed by supported features. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it's a search tool without output schema, description sufficiently covers return format and all capabilities. Parameter details are fully provided in schema. Sibling tool exists for detail retrieval, making this complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for all 4 parameters. Description adds context like date format 'YYYY:YYYY' and examples of publication types ('clinical trial', 'review'), enhancing understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it searches PubMed for articles by keyword and lists returned fields (PMID, title, authors, journal citation, snippet). Distinguishes from sibling tool pubmed_article_detail which likely gets article details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes supported filters (date ranges, publication types), sorting, and pagination. Implicitly contrasts with sibling by focusing on search vs. detail retrieval, but does not explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0pubmed_article_detailpubmed_searchThe two tools have completely distinct purposes: one for searching by keyword and the other for fetching full details by PMID. There is no overlap or ambiguity.
Both tools use the consistent 'pubmed_' prefix followed by descriptive action/noun pairs (pubmed_search, pubmed_article_detail), maintaining a clear and predictable pattern.
With only 2 tools, the server covers the essential PubMed operations (search and detail retrieval). While more advanced features could be added, this minimal set is well-scoped for basic article lookup.
The server covers the core search and detail retrieval workflow for PubMed articles. It lacks some advanced features like author-specific queries or citation networks, but it meets the primary need of searching and viewing articles.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.
Search biomedical literature, get article details, find related articles, and explore MeSH terms
Search PubMed with precision using keyword and journal filters and smart sorting. Uncover MeSH ter…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wjixiang/pubmed-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server