PubCrawl is an MCP server that gives AI assistants read-only, verifiable access to biomedical literature, US/UK drug labelling, and clinical trials via official APIs (PubMed, Europe PMC, openFDA/DailyMed, UK eMC, ClinicalTrials.gov).
Literature
search_pubmed — search PubMed with date range, article type, sort, and result limits (PMIDs, titles, authors, journals, DOIs).
search_europepmc — broader corpus including preprints and patents; filters for preprints-only/open-access, sortable by citations.
get_abstract — structured abstract sections, keywords, MeSH terms, PMC ID.
get_full_text — full text of open-access PMC articles with sections, figure/table captions, reference counts.
find_related — similar articles via PubMed's neighbor algorithm, ranked by relevance.
format_citation — APA, Vancouver, Harvard, or BibTeX citations.
trending_papers — recent papers on a topic, optionally filtered to high-impact journals.
Drug labelling
resolve_drug_name — brand↔generic name resolution with drug class and indications (RxNorm/openFDA).
get_uspi — US Prescribing Information sections via openFDA, cited to DailyMed.
get_smpc — UK Summary of Product Characteristics from the eMC.
compare_labels — side-by-side USPI vs SmPC comparison with mapped equivalent sections (US Indications ↔ UK 4.1).
search_by_indication — find drugs approved for a condition in the US, cross-checked for UK availability.
Clinical trials
search_trials — search ClinicalTrials.gov by condition, intervention, status, phase; returns NCT IDs, sponsors, enrollment.
get_trial — full trial details: eligibility, design, arms, outcomes, locations, linked PubMed IDs.
All tools are read-only, require no API keys (optional NCBI key for higher rate limits), and cite sources with PMIDs, NCT IDs, or DOIs.
Provides tools for searching PubMed, retrieving abstracts and full text, finding related articles, generating formatted citations, and discovering trending papers, with filters for date, article type, and journal impact.
Click on "Deploy 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., "@PubCrawl Search PubMed for recent clinical trials on semaglutide"
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.
An MCP server that gives AI assistants access to PubMed, Europe PMC, FDA & UK drug labelling, and ClinicalTrials.gov.
A peer-reviewed pub crawl through the literature — the label — and the trial.
Quick start · Tools · Examples · Architecture · Roadmap · Contributing
PubCrawl connects your AI assistant (Claude Desktop, Cursor, or any MCP-compatible client) directly to the primary sources clinicians and researchers actually use — so you can ask a question in plain English and get an answer grounded in PubMed, Europe PMC, FDA/UK drug labelling, and ClinicalTrials.gov, with real PMIDs, NCT IDs, and DOIs you can verify.
Every tool is a thin, deterministic wrapper over an official API. Nothing is invented; every result cites its source.
Ask "compare US and UK labelling for semaglutide" and PubCrawl pulls both live labels and maps equivalent sections — US Indications and Usage ↔ UK 4.1 Therapeutic indications, and so on — so the differences are visible instead of assumed:
US Prescribing Information | UK SmPC | |
Indications | glycaemic control · reduce risk of MACE in T2D with established CVD · reduce risk of sustained eGFR decline, ESKD and CV death in T2D with CKD | glycaemic control only — CV and renal outcomes appear as cross-references to §4.4/4.5/5.1, not as indications |
Contraindications | personal or family history of MTC or MEN 2 · hypersensitivity | hypersensitivity only |
A cardiovascular claim that is on-label in the US promotes an unlicensed indication in the UK. If you write, review, or check medical copy for both markets, that gap is the whole job — and compare_labels is the only MCP tool that surfaces it.
🔬 14 tools across literature, drug labelling, and clinical trials
🧾 Verifiable by design — results link back to DailyMed, the eMC, PubMed, and ClinicalTrials.gov
📰 Preprints via Europe PMC — surface work ahead of formal publication
🆓 No API keys required (an optional free NCBI key raises PubMed rate limits)
🧪 Fully typed, tested, and CI-checked — literature retrieval gated by OpenGATE, and labelling & trials by the in-repo fidelity benchmark, on every release
Built by PharmaTools.AI.
Related MCP server: mcp-pubmed-server
1. Add PubCrawl to your client config — no install step needed, npx fetches it on first run.
For Claude Desktop, edit claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"pubcrawl": {
"command": "npx",
"args": ["-y", "@pharmatools/pubcrawl"]
}
}
}2. Restart your client. PubCrawl appears under + → Connectors.
3. Ask away:
"Compare the US and UK labelling for atorvastatin, and find recent Phase 3 trials for it."
That's it. → More examples · API key & other options
Tool | What it does |
| Search PubMed with filters for date range, article type, and sort order. Returns PMIDs, titles, authors, journals, and DOIs. |
| Search Europe PMC — a broader corpus than PubMed that also indexes preprints (bioRxiv, medRxiv) and patents. Each result includes an abstract snippet, citation count, open-access status, and a preprint flag. Filter to preprints or open-access only. |
| Get the full structured abstract for an article — broken into labeled sections (background, methods, results, conclusions) with keywords and MeSH terms. |
| Retrieve the full text of open-access articles from PubMed Central, with parsed sections, figure/table captions, and reference counts. |
| Find similar articles using PubMed's neighbor algorithm, ranked by relevance score. |
| Generate a formatted citation in APA, Vancouver, Harvard, or BibTeX style. |
| Find recent papers on a topic, with optional filtering to high-impact journals (Nature, Science, Cell, NEJM, Lancet, JAMA, etc.). |
Tool | What it does |
| Convert a brand drug name to its generic (or a generic to its US brand names), with drug class and common indications. Deterministic, via RxNorm/openFDA — no AI. |
| Pull US Prescribing Information sections via openFDA (cited to DailyMed) — indications, dosing, warnings, contraindications, and more. |
| Retrieve UK Summary of Product Characteristics from the eMC — the UK equivalent of US prescribing information, with numbered SmPC sections. |
| Side-by-side comparison of US (USPI) and UK (SmPC) labelling for the same drug, pairing equivalent sections (US Indications ↔ UK 4.1). A missing side is always explained, cut sections are flagged |
| Find drugs approved for a medical condition. Searches FDA labelling via openFDA, then cross-references UK availability on the eMC. |
Tool | What it does |
| Search ClinicalTrials.gov for clinical trials. Filter by condition, intervention, recruitment status, and phase. Returns NCT IDs, sponsors, enrollment, and links. |
| Get full details for a clinical trial by NCT ID — eligibility criteria, study design, arms, primary/secondary outcomes, locations, and associated PubMed IDs. |
Once connected, just ask naturally:
Literature
"Search PubMed for recent clinical trials on semaglutide."
"Search Europe PMC for preprints on GLP-1 receptor agonists, most cited first."
"Get the abstract for PMID 38127654, then find related papers and cite them all in Vancouver style."
"What are the trending papers on CRISPR gene therapy this month, high-impact journals only?"
"Pull the full text of that PMC article and summarise the methods section."
Drug labelling
"Get the FDA prescribing information for metformin — just the indications and warnings."
"Pull the UK SmPC for atorvastatin."
"Compare US and UK labelling for lisinopril and highlight the differences."
"What's the generic name and drug class for Ozempic?"
"What drugs are approved for type 2 diabetes in both the US and UK?"
Clinical trials
"Find recruiting Phase 3 trials for pembrolizumab in breast cancer."
"Get the eligibility criteria and primary outcomes for NCT03086486."
Cross-source (where PubCrawl shines)
"For semaglutide: summarise the US label's cardiovascular indication, then find the pivotal trial and its NEJM publication."
Three layers — tools register the MCP interface, lib clients talk to each external API, and shared cache + parsers keep it fast and consistent.
Each tool file exports a register*Tool(server) function with a zod schema and an async handler. All network calls are rate-limited, cached, and time-bounded. See CLAUDE.md for a full architecture walkthrough and CONTRIBUTING.md to add a tool.
# Zero-install (recommended): npx fetches it on demand — see Quick start above.
# Or install globally:
npm install -g @pharmatools/pubcrawl
# Config for a global install:
# { "mcpServers": { "pubcrawl": { "command": "pubcrawl" } } }Without a key, PubMed requests are limited to 3/second. A free key raises this to 10/second.
Create a free NCBI account at https://www.ncbi.nlm.nih.gov/account/
Account Settings → API Key Management → create a key
Add it to your config:
{
"mcpServers": {
"pubcrawl": {
"command": "npx",
"args": ["-y", "@pharmatools/pubcrawl"],
"env": { "NCBI_API_KEY": "your_key_here" }
}
}
}PubCrawl also ships a stateless Streamable HTTP transport for browser-based and hosted clients:
npm run start:http # serves POST /mcp and GET /health on PORT (default 3000)Highlights of what's planned — see ROADMAP.md for the full list.
get_europepmc_fulltext — read preprints & OA articles surfaced by search_europepmc
get_adverse_events — openFDA FAERS adverse-event lookups
EMA / EPAR labelling to complement the US + UK compare_labels
MeSH query helper for sharper PubMed searches
MCP resources & prompts for common review workflows
Ideas welcome — open an issue.
git clone https://github.com/nickjlamb/pubcrawl.git
cd pubcrawl
npm install
npm run dev # TypeScript watch mode
npm run build # compile to dist/
npm start # run the stdio server
npm test # Vitest unit suite
npm run lint # ESLintUnit tests live in tests/ and cover the parsing, caching, citation, formatting and label-pairing logic with fixture payloads (no network calls). CI runs lint → test → build on every push and pull request. New to the codebase? Start with CONTRIBUTING.md.
npm run bench # labelling + trials fidelity benchmark against the live sources
npm run bench -- --ci # what the release gate runs: exit 1 if a verified case failsTwo gates run on every release and weekly. OpenGATE's retrieval scorer checks PubMed and Europe PMC records against hand-verified anchors. The in-repo fidelity benchmark does the same for drug labelling and trials: compare_labels is held to a gold set of US/UK anchors (a phrase must appear on one side and must not on the other, so real divergences are surfaced rather than smoothed over) plus a verbatim check that refetches the raw openFDA record and eMC page and confirms every returned sentence is a substring of the source. No LLM judge anywhere in either gate.
Versions follow Semantic Versioning. See the CHANGELOG for a full history and Releases for notes and assets.
Contributions are welcome and appreciated — bug reports, new data sources, new tools. Read the contributing guide to get started, then open an issue or a pull request.
If PubCrawl supports work you publish, please cite it — see CITATION.cff, or:
@software{lamb_pubcrawl,
author = {Lamb, Nick},
title = {PubCrawl: verifiable biomedical literature, drug labelling and clinical trials for AI assistants},
year = {2026},
publisher = {Zenodo},
doi = {10.5281/zenodo.22101559},
url = {https://doi.org/10.5281/zenodo.22101559}
}Compare US FDA Prescribing Information vs UK/EU SmPC for a drug side-by-side. Maps equivalent sections (e.g., US Indications ↔ UK 4.1) and returns paired verbatim content. A missing side is always explained: us_label/uk_label say whether the label was retrieved, each comparison notes why a section is null, and sections cut at the engine's length cap are flagged truncated.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | Yes | Drug name to compare across US and UK labelling | |
| uk_drug | No | Name to use for the UK lookup when it differs from `drug` — brands often do (Farxiga/Forxiga, Prilosec/Losec). Defaults to `drug`. | |
| us_drug | No | Name to use for the US lookup when it differs from `drug` (e.g. a US-only brand). Defaults to `drug`. | |
| sections | No | Specific topics to compare (e.g., ['indications', 'adverse reactions']). Compares all mapped sections if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, non-destructive, open-world), so the description's added value is in output behavior: it discloses that a missing side is always explained, that null sections carry a reason, and that length-capped sections are flagged truncated. That is genuinely useful context beyond the annotations, though it says nothing about rate limits or retrieval failures.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences with the purpose front-loaded, followed by mapping mechanics and then failure/truncation semantics. No sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description does real work by explaining the returned structure (paired verbatim content, section mapping, null explanations, truncation flags). It is close to complete, though it omits any note on result size or how many sections are mapped by default.
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 description coverage is 100%, so the schema already documents all four parameters including the brand-name divergence cases. The description adds no syntax or format detail for the parameters themselves, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Compare US FDA Prescribing Information vs UK/EU SmPC for a drug side-by-side.' It also names the section-mapping behavior, which distinguishes it from the read-only siblings get_uspi and get_smpc.
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 comparison framing implies when to reach for this tool rather than the single-jurisdiction get_uspi/get_smpc siblings, and the 'sections' parameter documents scoping. However, it never explicitly tells the agent to prefer get_uspi or get_smpc when only one side is needed, so no true exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Format a citation for a PubMed article in APA, Vancouver, Harvard, or BibTeX style.
| Name | Required | Description | Default |
|---|---|---|---|
| pmid | Yes | PubMed ID | |
| style | No | Citation style | apa |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=true, covering the non-destructive and external-data aspects. However, the description does not disclose that the tool likely fetches article metadata from PubMed, what the return value looks like, or error behavior. It adds no behavioral context beyond the verb 'Format'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded with the action and resource, no filler.
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 simple 2-parameter shape, full schema documentation, and annotations covering safety and world interaction, the description is largely sufficient. It falls short only by not stating the return format, which is minor for such a tool.
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 description coverage is 100%, so all parameters are documented. The description reiterates the enumeration of styles already present in the schema, adding no new semantic meaning. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description names a specific verb 'Format', a precise resource 'citation for a PubMed article', and enumerates the four supported styles. This clearly distinguishes it from sibling search/retrieval tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a formatted citation is needed, but it does not explicitly state when to use it versus alternatives like search_pubmed or get_abstract, nor does it mention prerequisites such as a valid PMID. Context is implied, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full structured abstract and metadata for a PubMed article. Returns abstract sections (background, methods, results, conclusions), keywords, MeSH terms, and PMC ID.
| Name | Required | Description | Default |
|---|---|---|---|
| pmid | Yes | PubMed ID | |
| structured | No | Return structured abstract sections |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the output behavior in detail: the abstract sections, keywords, MeSH terms, and PMC ID. It does not mention edge cases (e.g., missing abstract sections), but the key behavioral information is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The first sentence front-loads the tool's purpose; the second succinctly enumerates the return fields. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description carries the burden of explaining return values, and it does so by listing the key fields. It could but does not mention that metadata includes broader fields (authors, journal, date), and it doesn't describe behavior for invalid PMIDs or non-structured abstracts. However, for a simple retrieval tool, the essential invocation details are covered.
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 description coverage is 100%, so the parameters are fully documented in the schema. The description's mention of 'structructured abstract' and 'abstract sections' aligns with the 'structured' parameter but does not add meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get') and resource ('full structured abstract and metadata for a PubMed article'), making the tool's function immediately clear. It also lists concrete return fields (abstract sections, keywords, MeSH terms, PMC ID), which distinguishes it from siblings like get_full_text or search_pubmed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context: when you have a PubMed ID and need the abstract/metadata, use this tool. It does not explicitly contrast it with alternatives such as get_full_text, nor does it state when not to use it. This is implied usage rather than explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full text of an open-access article from PubMed Central. Returns article sections, figure/table captions, and reference count. Only works for articles available in PMC.
| Name | Required | Description | Default |
|---|---|---|---|
| pmid | No | PubMed ID | |
| pmcid | No | PubMed Central ID (e.g., PMC1234567) | |
| sections | No | Filter to specific section titles |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that it only works for open-access articles and lists return contents, which is useful. However, it does not disclose behavior like error handling for non-PMC articles or rate limits. With annotations covering safety, a 3 is appropriate.
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 primary action and return info first, followed by the access constraint. No wasted 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 the tool's simplicity, the schema fully covers parameters, and annotations cover the read-only nature. The description covers what it returns and the access limitation. It could mention the possibility of needing an open-access status check, but not strictly necessary.
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 description coverage is 100%, so parameters (pmid, pmcid, sections) are documented. The description adds no extra detail beyond 'articles available in PMC', and implicitly that both pmid and pmcid can be used but without specifics. Baseline 3 is correct.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Get'), a clear resource (full text of an article), and the source (PubMed Central). It also lists what is returned (sections, captions, reference count), and notes a key constraint (only works for open-access articles in PMC). This distinguishes it from siblings like get_abstract and get_smpc.
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' by noting it is for full text from PMC, and clearly states a limitation (only works for open-access articles). It does not explicitly mention when not to use or name alternatives like get_abstract, but the context is clear enough for an agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get UK/EU Summary of Product Characteristics (SmPC) for a drug from eMC (medicines.org.uk). Returns structured labelling sections.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | Yes | Drug name to look up (e.g., 'metformin', 'atorvastatin') | |
| sections | No | Specific sections to retrieve — accepts numbers like '4.1' or names like 'indications'. Returns all sections if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint=true and destructiveHint=false. The description adds useful context by identifying the external data source and stating that it 'Returns structured labelling sections', which goes beyond the annotation safety profile. It does not detail error behavior or network dependency, but the annotation coverage lowers the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or redundancy. It efficiently communicates the action, scope, source, and output format in about twenty 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?
The tool is simple (2 parameters, 1 required, no output schema), and the description provides enough orientation: what it fetches, from where, and the general shape of the result. With no output schema, it would benefit from a bit more detail about the exact response structure, but the current level is adequate for a basic read-only lookup.
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 description coverage is 100%, and both parameters ('drug' and 'sections') are already documented with examples and defaults in the schema. The description does not add meaning beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Get'), a specific resource ('UK/EU Summary of Product Characteristics'), a source ('eMC / medicines.org.uk'), and the return type ('structured labelling sections'). The 'UK/EU' and 'eMC' qualifiers clearly distinguish this from sibling tools like get_uspi, which targets US prescribing information.
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 use case is implied by the description: use this when you need UK/EU SmPC labelling for a drug. However, it does not explicitly state when not to use it or name alternatives such as get_uspi for US labels, leaving some routing inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get detailed information about a specific clinical trial from ClinicalTrials.gov. Returns eligibility criteria, study design, arms, outcomes, locations, and associated PubMed IDs.
| Name | Required | Description | Default |
|---|---|---|---|
| nctId | Yes | ClinicalTrials.gov NCT identifier (e.g., NCT03086486) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly, openWorld, and non-destructive behavior. The description adds context beyond that by naming the external source and detailing exactly which subsets of trial data are returned, which is especially valuable because no output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose and then lists the relevant return values. Every phrase earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter lookup tool with no output schema, the description covers the essential return fields and the data source. It does not explain not-found behavior or response envelope, but that is minor given the tool's simplicity and strong annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the nctId parameter is already well documented with a pattern and example. The description does not add parameter-level meaning, but the baseline of 3 applies because the schema carries the full burden.
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 specifies the exact verb ('get'), the resource ('a specific clinical trial from ClinicalTrials.gov'), and enumerates the returned content. This makes the tool's purpose clear and distinguishes it from search_trials and other siblings.
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 clearly implies use when detailed information about a specific trial is needed, especially given a required nctId. However, it never explicitly states when not to use it or names alternatives like search_trials, leaving comparison guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get FDA US Prescribing Information (USPI) for a drug from openFDA (cited to DailyMed). Returns structured labelling sections with LOINC codes.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | Yes | Drug name to look up (e.g., 'metformin', 'atorvastatin') | |
| sections | No | Specific sections to retrieve (e.g., ['indications', 'adverse reactions', 'contraindications']). Returns all sections if omitted. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by disclosing the return structure (structured labelling sections with LOINC codes) and the data source, which is beyond the annotation coverage. It does not contradict annotations and provides meaningful additional context about what the tool returns.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, information-dense sentence that front-loads the core purpose ('Get FDA USPI') and then adds the return format. There is no wasted wording, and every clause contributes essential detail. This is an exemplar of concise, structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with two documented parameters and annotations covering safety, the description is largely complete. It explains the source, the return type, and the inclusion of LOINC codes. A minor gap is that it does not describe the exact JSON structure of the returned sections (e.g., whether they are keyed by LOINC code), but this is acceptable given the absence of an output schema and the tool's simplicity.
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 description coverage is 100%, with both parameters (drug and sections) clearly documented in the schema itself. The description does not add any parameter-specific information beyond what the schema provides, so it does not elevate the baseline of 3. It relies entirely on the schema for parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Get') and specific resource ('FDA US Prescribing Information (USPI) for a drug'), explicitly identifying the source (openFDA, DailyMed) and the return format (structured labelling sections with LOINC codes). This unambiguously distinguishes it from sibling tools like get_smpc (European labels) without needing to name them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for US drug labels via the 'US' and 'FDA' terminology, but it does not explicitly state when to use this tool versus alternatives (e.g., get_smpc for European labels) or provide any exclusion criteria. The guidance is implied rather than explicit, so it falls short of a clear when-to-use directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert a brand drug name to its generic name (or a generic to its US brand names), with drug class and common indications. Deterministic — sourced from RxNorm/openFDA, no AI.
| Name | Required | Description | Default |
|---|---|---|---|
| drug | Yes | Brand or generic drug name to resolve (e.g., 'Lipitor' or 'atorvastatin') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already establish read-only, non-destructive behavior. The description adds genuinely useful behavioral context: it is deterministic, sourced from RxNorm/openFDA, and not AI-generated. This tells an agent to expect stable, auditable results and subtly signals that output may be limited to known drug-name mappings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no wasted words. The action and scope are front-loaded, and the provenance/determinism note is cleanly separated. It avoids repeating schema content and earns each sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter, read-only resolver with full schema coverage and safety annotations, the description provides the input expectations, conversion directions, and main output types. There is no output schema, and the exact return shape is not specified, but that is a minor gap for such a simple lookup tool.
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 description coverage is 100%, so the schema fully documents the single 'drug' string parameter with examples. The description adds the directional nuance (generic → US brand names) and the output categories, but it does not need to add further input-format constraints. The 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 opens with a clear action ('Convert'), identifies the resource (drug name), and specifies bidirectional resolution (brand→generic and generic→US brand names). It also lists additional outputs (drug class, common indications), and none of the sibling tools share exactly this responsibility, so an agent can distinguish it immediately.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for drug-name normalization and lookup, but it never explicitly says when to prefer this tool over related siblings such as get_smpc, compare_labels, or search_by_indication. 'No AI' hints at using it when authoritative, deterministic output is wanted, but there is no explicit when/when-not guidance or mention of alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find drugs approved for a medical condition. Searches US FDA labelling for the condition, then checks UK (eMC) availability for each drug found.
| Name | Required | Description | Default |
|---|---|---|---|
| condition | Yes | Medical condition or indication to search for (e.g., 'type 2 diabetes', 'hypertension') | |
| maxResults | No | Maximum number of drug results to return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is clear. The description adds behavioral detail by explaining the two-step process: searching US FDA labelling first, then checking UK (eMC) availability. This gives the agent insight into how results are derived, which is valuable beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no fluff. The first sentence front-loads the core purpose, and the second explains the process. Every word earns its place, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple search tool with two parameters and read-only annotations, the description is quite complete. It covers the purpose and the process, and the annotations cover safety. It does not describe the exact output format, but with no output schema, that omission is acceptable given the tool's simplicity.
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?
The input schema covers 100% of parameters with descriptions for both 'condition' and 'maxResults'. The description does not add additional parameter context, but since the schema already provides adequate semantics, a baseline score 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 clearly states the tool's purpose: 'Find drugs approved for a medical condition.' It specifies the verb 'Find' and the resource 'drugs approved for a medical condition,' and further distinguishes its approach by mentioning the US FDA labelling search and UK (eMC) availability check, which sets it apart from sibling tools like search_pubmed or get_uspi.
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 provides clear context on when to use the tool: when seeking drugs approved for a condition, with the dual FDA/eMC scope. However, it does not explicitly name alternative tools or provide exclusion criteria (e.g., 'for literature use search_pubmed'), so the guidance is strong but not fully explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Europe PMC — a broader biomedical corpus than PubMed that also indexes preprints (bioRxiv, medRxiv), patents, and agricultural/biomedical databases. Unlike search_pubmed, each result includes an abstract snippet, citation count, open-access status, and whether a preprint. Use preprintsOnly to surface work ahead of formal publication.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order: relevance, date (newest first), or cited (most cited first) | relevance |
| query | Yes | Search query (Europe PMC query syntax supported, e.g. field tags like AUTH, TITLE, JOURNAL) | |
| maxResults | No | Maximum number of results | |
| preprintsOnly | No | Restrict to preprints (bioRxiv, medRxiv, etc.) | |
| openAccessOnly | No | Restrict to open-access articles |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only and open-world behavior. The description adds meaningful behavioral context beyond the annotations: the corpus scope, the included preprint/patent sources, and the fact that every result contains an abstract snippet, citation count, open-access status, and preprint flag. This is valuable disclosure about what the tool returns and searches, well beyond the annotation metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly written sentences with no filler: the first identifies the tool and corpus, the second differentiates it from search_pubmed, and the third gives a concrete usage tip. Information is front-loaded and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description adequately conveys corpus scope, result-content highlights, and a key parameter. The schema covers all arguments, and annotations cover safety behavior. A minor gap is the absence of explicit response-structure or pagination expectations, but nothing critical prevents an agent from selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all five parameters. The description adds real semantic value for preprintsOnly ('surface work ahead of formal publication') and clarifies the corpus context for query meaning. It does not add to the meaning of sort, maxResults, or openAccessOnly, but the schema descriptions cover those adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Search Europe PMC') and defines the corpus as broader than PubMed, including preprints, patents, and agricultural/biomedical databases. It also distinguishes itself from search_pubmed by naming the richer per-result fields (abstract snippet, citation count, open-access status, preprint flag). An agent can clearly identify what this tool does and why it differs from siblings.
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 gives clear context for when this tool is appropriate: broader biomedical coverage, preprints, patents, and richer result metadata. It explicitly names search_pubmed as a sibling alternative, and it directs the agent to preprintsOnly for work ahead of formal publication. It does not, however, state explicit when-not conditions or repeatedly mention other sibling tools, so it stops just short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search PubMed for biomedical literature. Returns article summaries with PMIDs, titles, authors, journals, and DOIs.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order | relevance |
| query | Yes | PubMed search query | |
| dateTo | No | End date (YYYY/MM/DD) | |
| dateFrom | No | Start date (YYYY/MM/DD) | |
| maxResults | No | Maximum number of results | |
| articleType | No | Article type filter (e.g., review, clinical trial) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a safe read-only operation (readOnlyHint=true, destructiveHint=false). The description adds useful information by listing the returned article summary fields (PMIDs, titles, authors, journals, DOIs), but does not disclose potential caveats such as incomplete coverage or API limitations. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The verb and resource are front-loaded, and the output summary is stated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only search tool with 100% schema coverage, the description covers the core purpose, the database, and the expected output fields despite having no output schema. It is slightly incomplete only in not directing the agent toward sibling tools, which is already penalized under usage guidelines.
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 description coverage is 100%, so the schema carries the parameter documentation burden. The description does not add meaning to parameters like sort, dateFrom, dateTo, or maxResults beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb ('Search'), resource ('PubMed'), domain ('biomedical literature'), and summarizes the return payload. It is clear enough to distinguish from siblings like search_europepmc by the explicit resource name, though it does not explicitly name an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to use this tool versus the siblings, especially search_europepmc or get_full_text. The agent must infer from the name and schema that this is the PubMed-focused search and not a full-text or abstract-specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ClinicalTrials.gov for clinical trials. Filter by condition, intervention, status, and phase. Returns trial summaries with NCT IDs, status, sponsors, and enrollment info.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | Sort order for results | relevance |
| term | No | General search term (searches all fields) | |
| phase | No | Trial phase filter | |
| status | No | Trial recruitment status filter | |
| condition | No | Disease or condition (e.g., 'breast cancer', 'diabetes') | |
| maxResults | No | Maximum number of results (1-100) | |
| intervention | No | Drug or therapy (e.g., 'pembrolizumab', 'radiation') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already disclose readOnlyHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context by specifying what the search returns ('trial summaries with NCT IDs, status, sponsors, and enrollment info'). It does not contradict the annotations and provides an adequate picture of the tool's outcome, though it does not mention things like pagination or result size limits (already in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is composed of three short, purposeful sentences. The first sentence states the core action, the second lists the key filter dimensions, and the third describes the output fields. There is no redundancy or fluff, and the most important information is front-loaded.
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 absence of an output schema, the description's enumeration of returned fields (NCT IDs, status, sponsors, enrollment info) is valuable and fills the gap. The tool is a straightforward read-only search with a fully described schema, so the description covers the essentials. It does not explicitly mention external API dependency or result volume, but these are minor given the context and the openWorldHint annotation.
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 description coverage is 100%, so the input schema thoroughly documents all 7 parameters. The description's mention of filters (condition, intervention, status, phase) merely restates parameter names without adding new semantic detail beyond what the schema already provides. Thus, the description contributes no additional parameter-level insight, warranting the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Search ClinicalTrials.gov') and the resource, and explicitly lists the filter dimensions (condition, intervention, status, phase) plus the return fields (NCT IDs, status, sponsors, enrollment info). This differentiates it from sibling search tools like search_pubmed or search_europepmc, which target literature rather than trials.
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 its usage by naming ClinicalTrials.gov, but it does not explicitly state when to choose this tool over alternatives (e.g., search_pubmed for articles or get_trial for a specific trial). No 'when not to use' guidance is provided, leaving the agent to infer it from the sibling names and context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find recent/trending papers on a topic. Sorted by date, with optional filtering to high-impact journals.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Number of days to look back | |
| topic | Yes | Topic or search term | |
| maxResults | No | Maximum number of results | |
| highImpactOnly | No | Filter to high-impact journals only |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, non-destructive, open-world behavior. The description adds useful context about ordering by date and an optional high-impact filter, but it does not disclose return format, pagination, or the meaning of 'trending.' This is adequate but not rich.
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 no filler. The primary action and key ordering/filtering behavior are front-loaded, making the purpose immediately clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with a fully documented schema and readOnly/openWorld annotations, the description is nearly sufficient. The main ambiguity is the term 'trending' and the lack of an explicit output description, but the invocation path is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all four parameters. The description reinforces the topic parameter and the highImpactOnly filter but does not add meaningful detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—find recent/trending papers—and a clear resource (papers by topic), plus key behavior (sorted by date, high-impact filtering). It does not explicitly distinguish itself from siblings like search_pubmed or search_europepmc, so it misses the top score.
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 phrase 'recent/trending' implies a time-sensitive search use case, but the description provides no explicit guidance on when to choose this over sibling search tools or when not to use it. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.6.2compare_labels2 fields changedInput schema / properties / uk_drugAdded value: +{
+ "description": "Name to use for the UK lookup when it differs from `drug` — brands often do (Farxiga/Forxiga, Prilosec/Losec). Defaults to `drug`.",
+ "type": "string"
+}Input schema / properties / us_drugAdded value: +{
+ "description": "Name to use for the US lookup when it differs from `drug` (e.g. a US-only brand). Defaults to `drug`.",
+ "type": "string"
+}v2.5.1compare_labelsfind_relatedformat_citationget_abstractget_full_textget_smpcget_trialget_uspiresolve_drug_namesearch_by_indicationsearch_europepmcsearch_pubmedsearch_trialstrending_papersScored across 14 tools
Most tools target clearly distinct resources and actions, such as article retrieval, drug-label comparison, and trial lookup. Some conceptual overlap exists between search_pubmed and search_europepmc, and trending_papers overlaps slightly with literature search, but descriptions clarify corpora and use cases.
Names are predominantly snake_case with a verb_noun pattern (get_abstract, search_pubmed, resolve_drug_name). Minor deviations include acronym-based tools (get_uspi, get_smpc) and the noun phrase trending_papers, but overall the convention is readable and predictable.
14 tools fit a multi-domain biomedical research server spanning literature, drug labels, and clinical trials. Each tool covers a distinct capability, and the count sits within the well-scoped 3-15 range without obvious redundancy.
Core workflows are covered: literature search/retrieval, citation formatting, related articles, drug-label comparison, drug-name resolution, and trial search/detail. Minor gaps remain, such as general drug-label keyword search or non-PMC full-text access, but agents can work around them.
Search biomedical papers, inspect publication records, and traverse citation or semantic graphs.
Linked life-science search: 43M+ papers, 1.2M+ trials, drugs, genes, FDA/EMA approvals, patents.
Search 36M+ PubMed biomedical articles and ClinicalTrials.gov studies.
Search PubMed/Europe PMC, fetch articles and full text (PMC/EPMC/Unpaywall), citations, MeSH terms.