Medical MCP is a local MCP server that brings trusted medical data (drugs, literature, clinical tools, and health statistics) into AI workflows without API keys or data leaving your machine.
Search drug information across FDA, DailyMed, TGA, Health Canada, and EMA via search-drugs, get details by NDC via get-drug-details, look up standardized names via RxNorm (search-drug-nomenclature), and check drug interactions with check-drug-interactions
Get health statistics from WHO Global Health Observatory (life expectancy, mortality, disease prevalence) via get-health-statistics
Search medical literature in PubMed with evidence grading (search-medical-literature), get article details by PMID (get-article-details), search Google Scholar (search-google-scholar), and run multi-database searches across PubMed, Scholar, Cochrane, ClinicalTrials.gov, and Europe PMC (search-medical-databases)
Search top medical journals (NEJM, JAMA, Lancet, BMJ, Nature Medicine) via search-medical-journals
Find clinical guidelines and practice recommendations from medical organizations via search-clinical-guidelines
Monitor server health and upstream source availability with built-in health checks and cache statistics
Enables searching for academic research articles through web scraping, providing access to titles, authors, abstracts, journals, citations, and publication information from Google Scholar's database
Provides access to search and retrieve medical literature from PubMed's database of over 30 million citations, including research articles, clinical studies, and medical reviews
Allows querying of WHO Global Health Observatory data to retrieve health statistics and indicators from 194 countries, including life expectancy, mortality rates, and disease prevalence data
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., "@medical-mcp search for recent studies on diabetes treatment"
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.
Bring trusted medical data directly into your AI workflow. A local server for private, free access to FDA, WHO, PubMed, RxNorm, Semantic Scholar, and Google Scholar. No API keys. No data leaks.
An MCP (Model Context Protocol) server that brings authoritative medical information into AI coding environments like Cursor and Claude Desktop.
š Your Data Never Leaves ā Runs 100% locally; no tracking, no logs, no cloud
š No API Keys ā Works out of the box, zero configuration
š„ Authoritative Sources ā FDA, TGA, Health Canada, EMA, DailyMed, WHO, PubMed, Europe PMC, RxNorm, ClinicalTrials.gov
ā” Easy Setup ā One-click install in Cursor or simple manual setup
š¬ Comprehensive ā Drug info, health stats, medical literature, clinical guidelines, pediatric sources
š”ļø Resilient ā Circuit breakers, retry with backoff, rate limiting, and automatic fallbacks
š Evidence-Graded ā Results tagged with study type and evidence level (Meta-Analysis ā Case Report)
š„ Health Monitoring ā Built-in health check tool to diagnose source availability
Related MCP server: DrugWise
Resilience Layer ā Circuit breakers per source, retry with exponential backoff + jitter, per-source token bucket rate limiters
Monid web search ā Scholar, Cochrane, AAP, and PMC HTML go through Monid TinyFish (Tavily-style search/fetch). Semantic Scholar is the no-key fallback
Evidence Grading ā PubMed and multi-database results tagged with study type (Systematic Review, RCT, Cohort, Case Report, etc.) and evidence grade (IāV)
Response Validation ā Zod schemas validate all upstream API responses, logging warnings on schema drift without breaking
NCBI API Key Support ā Optional NCBI_API_KEY env var boosts PubMed from 3 req/sec to 10 req/sec
Health Check Tool ā health-check pings all upstream sources and reports latency, circuit breaker states, rate limiter status, and cache health
Structured Logging ā Leveled, structured logging (DEBUG/INFO/WARN/ERROR) with source tracking and timing for every API call
Request Timeouts ā All upstream calls have explicit response/deadline timeouts to prevent hanging
Install in Cursor (Recommended):
Or install manually:
npm install -g medical-mcp
# Or from source:
git clone https://github.com/JamesANZ/medical-mcp.git
cd medical-mcp && npm install && npm run buildsearch-drugs ā Search FDA, DailyMed, TGA (Australia), Health Canada, and EMA. Filter with countries (US, AU, CA, EU)
search-drug-nomenclature ā Standardized drug names via RxNorm
search-drug-safety ā FDA FAERS adverse events, recalls, and shortages
get-health-statistics ā WHO Global Health Observatory data (life expectancy, mortality, disease prevalence)
search-medical-literature ā Search 30M+ PubMed articles (with evidence grading)
get-article-details ā Detailed article info by PMID
search-google-scholar ā Academic papers via Monid TinyFish (research_paper) when MONID_API_KEY is set; otherwise Semantic Scholar
search-medical-databases ā Multi-database search (PubMed, Scholar, Semantic Scholar, Cochrane, ClinicalTrials.gov, Europe PMC)
search-medical-journals ā Top journals (NEJM, JAMA, Lancet, BMJ, Nature Medicine)
search-clinical-guidelines ā Practice recommendations from medical organizations
search-clinical-trials ā ClinicalTrials.gov plus Australia/New Zealand location coverage
list-sources ā Full catalog of registry adapters and dedicated-tool sources (WHO, PubMed, RxNorm, Scholar, Cochrane, AAP), including which MCP tool reaches each. This is not the search-drugs five-regulator fanout.
search-pediatric-guidelines ā AAP guidelines and Bright Futures preventive care
search-pediatric-literature ā Research from major pediatric journals
get-child-health-statistics ā Pediatric health indicators from WHO
search-pediatric-drugs ā Drugs with pediatric labeling and dosing information
search-aap-guidelines ā Comprehensive AAP guideline search (Bright Futures + Policy Statements)
health-check ā Ping all upstream sources, report latency/status, circuit breaker states, and cache health
get-cache-stats ā View cache statistics (hit rate, memory usage, entry count)
Click the install link above or use:
cursor://anysphere.cursor-deeplink/mcp/install?name=medical-mcp&config=eyJtZWRpY2FsLW1jcCI6eyJjb21tYW5kIjoibnB4IiwiYXJncyI6WyIteSIsIm1lZGljYWwtbWNwIl19fQ==Requirements: Node.js 18+ and npm
git clone https://github.com/JamesANZ/medical-mcp.git
cd medical-mcp
npm install
npm run build
npm startAdd to claude_desktop_config.json:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
{
"mcpServers": {
"medical-mcp": {
"command": "node",
"args": ["/absolute/path/to/medical-mcp/build/index.js"],
"env": {
"NCBI_API_KEY": "your_optional_key_here"
}
}
}
}Restart Claude Desktop after configuration.
{
"tool": "search-drugs",
"arguments": { "query": "Tylenol", "limit": 5 }
}Results now include evidence tags:
1. Efficacy of COVID-19 Treatments: A Meta-Analysis
Evidence: [Systematic Review / Meta-Analysis ā¢ Grade I]
Authors: Smith J, Jones K...
2. Randomized Trial of Remdesivir in Adults
Evidence: [Randomized Controlled Trial ā¢ Grade II]
Authors: Chen L, Wang M...{ "tool": "health-check", "arguments": {} }Returns:
ā
FDA: healthy (234ms)
ā
PubMed: healthy (156ms)
ā
WHO: healthy (890ms)
ā
RxNorm: healthy (312ms)
ā
ClinicalTrials: healthy (445ms)
ā
SemanticScholar: healthy (189ms)
NCBI API Key: ā
Configured (10 req/sec PubMed)Every API call flows through a three-layer resilience stack:
Request ā Rate Limiter ā Circuit Breaker ā Retry (with backoff) ā Upstream APIRate Limiter ā Per-source token bucket prevents exceeding API limits (PubMed: 3/sec without key, 10/sec with; FDA: 4/sec; Google Scholar: 0.2/sec)
Circuit Breaker ā After 3 consecutive failures, the circuit opens for 60s, preventing cascade failures. Transitions: CLOSED ā OPEN ā HALF_OPEN ā CLOSED
Retry ā Exponential backoff with full jitter on transient failures (429, 5xx, network errors). Max 2 retries
PubMed and multi-database results are automatically classified:
Grade | Study Type | Examples |
I | Systematic Review / Meta-Analysis | Cochrane reviews, PRISMA studies |
II | Randomized Controlled Trial | Double-blind placebo-controlled trials |
III | Cohort / Case-Control Study | Prospective, retrospective, population-based |
IV | Case Report / Case Series | Clinical case presentations |
V | Expert Opinion / Editorial | Commentaries, perspectives, narrative reviews |
When MONID_API_KEY is set, Scholar/Cochrane/AAP search and PMC HTML fetch go through Monid TinyFish. Without a key, Scholar falls back to Semantic Scholar's API ā free, well-structured, 100 req/sec, no API key needed.
All upstream API responses are validated against Zod schemas. If a source changes their API response format, the server logs a warning but continues operating with raw data ā no crashes, just alerts.
Source | Coverage | Update Frequency | Resilience |
FDA | US approved drug labels | Real-time | Circuit breaker + retry |
DailyMed | US structured product labels | Daily | Circuit breaker + retry |
TGA ARTG | Australian Register of Therapeutic Goods | Real-time | Circuit breaker + retry |
Health Canada DPD | Canadian marketed/approved drugs | Real-time | Circuit breaker + retry |
EMA | EU centrally authorised medicines | Twice daily JSON | In-memory cache + retry |
FDA FAERS / recalls / shortages | US safety signals | Real-time | Circuit breaker + retry |
WHO | Global health stats (194 countries) | Annual | Circuit breaker + retry |
PubMed | 30M+ medical citations | Daily | Circuit breaker + retry + NCBI key |
Europe PMC | PubMed + preprints + patents | Real-time | Circuit breaker + retry |
RxNorm | Standardized drug nomenclature (US) | Weekly | Circuit breaker + retry |
TinyFish via Monid | Research papers + domain-scoped web | Real-time | Optional |
Semantic Scholar | 200M+ papers with citation data | Real-time | Circuit breaker + retry |
AAP | Bright Futures & policy statements | Periodic | Graceful degradation |
Pediatric Journals | Major pediatric journals | Daily | Circuit breaker + retry |
ClinicalTrials.gov | Global + AU/NZ location filter | Real-time | Circuit breaker + retry |
Cochrane | Systematic reviews | Real-time | Monid TinyFish search |
Performance & Reliability:
Variable | Default | Description |
| (none) | Free PubMed API key ā 3x throughput. Get one at NCBI |
| (none) | Optional. When set, Scholar/Cochrane/AAP/PMC HTML use Monid's TinyFish search and fetch (Tavily-style web scraper). Get a key at Monid |
| (none) | Optional fallback if you call TinyFish directly instead of through Monid. |
|
| Logging level: |
Cache:
Variable | Default | Description |
|
| Enable/disable caching |
|
| Maximum cache entries |
|
| FDA TTL in seconds (24h) |
|
| PubMed TTL (1h) |
|
| WHO TTL (7d) |
|
| RxNorm TTL (30d) |
|
| Google Scholar TTL (1h) |
|
| Bright Futures TTL (30d) |
|
| AAP Policy TTL (7d) |
|
| TGA/EMA/Health Canada TTL |
|
| FAERS/recalls/shortages TTL |
|
| Clinical trial search TTL |
|
| Cleanup interval in ms (5min) |
Deduplication:
Variable | Default | Description |
|
| Enable/disable cross-source deduplication |
|
| Fuzzy title match threshold (0.0ā1.0) |
|
| Log removed duplicates |
Performance: Cached responses return in <10ms vs 800ā1500ms for API calls. Expected hit rate: 60%+ for common queries.
ā Localhost-only ā Server runs locally, no external access
ā No data storage ā All queries are real-time, nothing saved to disk
ā Process isolation ā Medical data stays on your machine
ā No API keys required ā Works without credentials (NCBI and Monid keys are optional)
Built with: Node.js, TypeScript, MCP SDK
Dependencies: @modelcontextprotocol/sdk, superagent, zod, express, cors
Platforms: macOS, Windows, Linux
Source layout:
src/
āāā index.ts # MCP tool definitions
āāā utils.ts # Core API functions + formatters
āāā constants.ts # API URLs, config constants
āāā types.ts # TypeScript types
āāā logger.ts # Structured leveled logging
āāā cache/
ā āāā config.ts # TTL policies, env var support
ā āāā manager.ts # In-memory LRU cache
āāā resilience/
ā āāā index.ts # Composed resilientCall()
ā āāā circuit-breaker.ts # Per-source circuit breaker
ā āāā retry.ts # Exponential backoff + jitter
ā āāā rate-limiter.ts # Token bucket rate limiter
āāā validation/
ā āāā schemas.ts # Zod schemas for API responses
āāā sources/ # Country/source registry + adapters
ā āāā adapters/ # FDA, TGA, Health Canada, EMA, DailyMed, FAERS, trials, TinyFish
ā āāā ...
āāā utils/
āāā deduplication.ts # Cross-source paper dedup
āāā evidence-grading.ts # Study type classification
āāā semantic-scholar.ts # Semantic Scholar API clientā ļø Important: This tool provides information from authoritative sources but should not replace professional medical advice, diagnosis, or treatment. Always consult qualified healthcare professionals for medical decisions.
ā If this project helps you, please star it on GitHub! ā
Contributions welcome! Please open an issue or submit a pull request.
MIT License ā see LICENSE.md for details.
If you find this project useful, consider supporting it:
ā” Lightning Network
lnbc1pjhhsqepp5mjgwnvg0z53shm22hfe9us289lnaqkwv8rn2s0rtekg5vvj56xnqdqqcqzzsxqyz5vqsp5gu6vh9hyp94c7t3tkpqrp2r059t4vrw7ps78a4n0a2u52678c7yq9qyyssq7zcferywka50wcy75skjfrdrk930cuyx24rg55cwfuzxs49rc9c53mpz6zug5y2544pt8y9jflnq0ltlha26ed846jh0y7n4gm8jd3qqaautqaāæ Bitcoin: bc1ptzvr93pn959xq4et6sqzpfnkk2args22ewv5u2th4ps7hshfaqrshe0xtp
Ī Ethereum/EVM: 0x42ea529282DDE0AA87B42d9E83316eb23FE62c3f
Check for potential drug-drug interactions between two medications
| Name | Required | Description | Default |
|---|---|---|---|
| drug1 | Yes | First drug name | |
| drug2 | Yes | Second drug name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool checks for 'potential' interactions but doesn't specify what constitutes a potential interaction, the source of data, accuracy levels, or output format. For a medical tool with safety implications, this is a significant gap.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 complexity of drug interaction checking and the lack of annotations and output schema, the description is incomplete. It doesn't explain what the tool returns, how interactions are categorized, or any limitations, which is inadequate for a tool with potential safety-critical applications.
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 clear descriptions for 'drug1' and 'drug2' as drug names. The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints, so it meets the baseline for high schema coverage.
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 with a specific verb ('Check') and resource ('drug-drug interactions'), specifying it evaluates interactions between two medications. However, it doesn't distinguish this from sibling tools like 'get-drug-details' or 'search-drugs', which might provide related but different functionality.
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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, exclusions, or compare it to sibling tools such as 'search-drug-nomenclature' or 'search-medical-databases', leaving the agent to infer usage context.
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 medical article by PMID
| Name | Required | Description | Default |
|---|---|---|---|
| pmid | Yes | PubMed ID (PMID) of the article |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read-only operation ('Get'), it doesn't specify critical traits like authentication requirements, rate limits, error handling, or what 'detailed information' includes (e.g., abstract, authors, citations). This is inadequate for a tool with no annotation coverage.
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, efficient sentence that front-loads the core purpose with zero wasted words. It directly communicates what the tool does without unnecessary elaboration, 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?
Given the lack of annotations and output schema, the description is incomplete. It doesn't explain what 'detailed information' entails in the return values, behavioral constraints, or how it differs from sibling search tools. For a tool with no structured coverage beyond input schema, this leaves significant gaps for an agent.
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 schema description coverage is 100%, with the parameter 'pmid' fully documented in the schema as 'PubMed ID (PMID) of the article'. The description adds no additional parameter semantics beyond restating the need for a PMID, so it meets the baseline score without adding value.
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 action ('Get detailed information') and target resource ('specific medical article by PMID'), making the purpose immediately understandable. However, it doesn't differentiate this tool from potential siblings like 'search-medical-literature' or 'search-medical-journals' that might also retrieve article information, preventing a perfect 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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a PMID), exclusions, or comparisons to sibling tools like 'search-medical-databases' for broader searches, leaving the agent without contextual usage direction.
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 drug by NDC (National Drug Code)
| Name | Required | Description | Default |
|---|---|---|---|
| ndc | Yes | National Drug Code (NDC) of the drug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool's purpose but doesn't describe behavioral traits such as whether it's read-only (implied by 'Get' but not explicit), rate limits, error handling, or what 'detailed information' includes (e.g., format, depth). This leaves significant gaps for a tool with no annotation coverage.
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, efficient sentence with zero wasteāit directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly.
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 no annotations and no output schema, the description is incomplete for a tool that presumably returns detailed drug information. It doesn't explain what 'detailed information' entails (e.g., fields, structure) or address potential complexities like error cases or data sources, leaving the agent with insufficient context for reliable use.
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 the schema fully documenting the single 'ndc' parameter. The description adds no additional parameter semantics beyond what the schema provides (e.g., no examples, format details, or constraints). Baseline 3 is appropriate as the schema does the heavy lifting.
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 specific action ('Get detailed information') and target resource ('about a specific drug by NDC'), distinguishing it from siblings like search-drugs (which searches) or check-drug-interactions (which checks interactions). It precisely communicates the verb+resource combination.
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 you have a specific NDC and need detailed drug information, but it doesn't explicitly state when to use this versus alternatives like search-drugs (for searching without a known NDC) or when not to use it. The context is clear but lacks explicit guidance on alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get health statistics and indicators from WHO Global Health Observatory
| Name | Required | Description | Default |
|---|---|---|---|
| indicator | Yes | Health indicator to search for (e.g., 'Life expectancy', 'Mortality rate') | |
| country | No | Country code (e.g., 'USA', 'GBR') - optional | |
| limit | No | Number of results to return (max 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states what the tool does but lacks details on behavioral traits such as rate limits, authentication requirements, error handling, or the format of returned data. For a tool with no annotations, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to parse and understand quickly. 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?
Given the tool's moderate complexity (3 parameters, 1 required) and lack of annotations and output schema, the description is minimally adequate but incomplete. It covers the basic purpose but fails to address behavioral aspects or usage context, leaving gaps that could hinder an agent's ability to use the tool effectively.
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%, meaning the input schema already documents all parameters thoroughly. The description adds no additional meaning beyond what the schema provides, such as examples of indicators beyond those listed or context for country codes. With high schema coverage, the 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 verb ('Get') and resource ('health statistics and indicators from WHO Global Health Observatory'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'search-medical-databases' or 'search-medical-literature', which might also retrieve health data but from different sources or with different scopes.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any specific context, prerequisites, or exclusions, nor does it reference sibling tools like 'search-medical-databases' that might overlap in functionality. This leaves the agent without clear usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for clinical guidelines and practice recommendations from medical organizations
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Medical condition or topic to search for guidelines | |
| organization | No | Specific medical organization to filter by (e.g., 'American Heart Association', 'WHO') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching but doesn't cover aspects like whether this is a read-only operation, potential rate limits, authentication needs, or what the search results include (e.g., format, pagination). For a search tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence that directly states the tool's purpose without any wasted words. It's appropriately sized and front-loaded, making it easy to understand at a glance.
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 moderate complexity (search with two parameters), no annotations, and no output schema, the description is minimally adequate. It covers the basic purpose but lacks details on behavior, output format, and usage context, which are important for a search operation in a medical domain with multiple sibling tools.
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 clear descriptions for both parameters ('query' and 'organization') in the input schema. The description doesn't add any extra meaning or examples beyond what the schema provides, so it meets the baseline score of 3 without compensating or detracting.
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 verb ('Search for') and resource ('clinical guidelines and practice recommendations from medical organizations'), making the purpose understandable. It doesn't explicitly differentiate from sibling tools like 'search-medical-literature' or 'search-medical-databases', which might have overlapping domains, so it doesn't reach the highest 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?
No guidance is provided on when to use this tool versus alternatives like 'search-medical-literature' or 'search-medical-databases' from the sibling list. The description implies a specific focus on guidelines, but it doesn't state exclusions or prerequisites, leaving usage context vague.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for drug information using RxNorm (standardized drug nomenclature)
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Drug name to search for in RxNorm database |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool is for searching, which implies a read-only operation, but doesn't disclose any behavioral traits such as rate limits, authentication needs, response formats, or potential side effects. For a tool with zero annotation coverage, this is a significant gap in transparency.
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, efficient sentence: 'Search for drug information using RxNorm (standardized drug nomenclature)'. It is front-loaded with the core purpose, has no wasted words, and is appropriately sized for the tool's complexity, earning a top score for conciseness and structure.
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 low complexity (one parameter, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose but lacks details on usage guidelines, behavioral traits, and output, which are important for full contextual understanding. Without annotations or an output schema, the description should do more to compensate, but it falls short, resulting in a mediocre score.
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 has 100% description coverage, with the single parameter 'query' documented as 'Drug name to search for in RxNorm database'. The description adds no additional meaning beyond this, as it doesn't elaborate on parameter syntax, examples, or constraints. Given the high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.
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: 'Search for drug information using RxNorm (standardized drug nomenclature)'. It specifies the verb ('Search'), resource ('drug information'), and method ('using RxNorm'), which is specific and informative. However, it doesn't explicitly distinguish this tool from sibling tools like 'search-drugs' or 'search-medical-databases', which might also involve drug-related searches, so it doesn't reach the highest 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 description provides no guidance on when to use this tool versus alternatives. It doesn't mention any specific contexts, exclusions, or comparisons to sibling tools such as 'search-drugs' or 'get-drug-details', leaving the agent to infer usage based on the name alone. This lack of explicit guidelines reduces its helpfulness for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for drug information using FDA database
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Drug name to search for (brand name or generic name) | |
| limit | No | Number of results to return (max 50) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Search') and source ('FDA database'), but lacks details on permissions, rate limits, error handling, or response format. For a search tool with zero annotation coverage, this is insufficient to inform safe and effective use.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 lack of annotations and output schema, the description is incomplete. It doesn't cover behavioral aspects like authentication needs or result structure, and with sibling tools present, it fails to provide differentiation. For a search tool in a medical context, more context is needed for reliable use.
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 has 100% description coverage, fully documenting the 'query' and 'limit' parameters. The description adds no additional semantic context beyond what's in the schema, such as search syntax or result ordering. Baseline 3 is appropriate as the schema handles the heavy lifting.
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 action ('Search for drug information') and the resource ('FDA database'), which is specific and unambiguous. However, it doesn't explicitly differentiate from sibling tools like 'search-drug-nomenclature' or 'search-medical-databases', which might also involve drug-related searches, leaving some room for confusion about scope.
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 no guidance on when to use this tool versus alternatives like 'search-drug-nomenclature' or 'get-drug-details'. It mentions the FDA database as the source, but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for academic research articles using Google Scholar
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Academic topic or research query to search for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it indicates this is a search operation (implying read-only behavior), it doesn't describe any behavioral traits such as rate limits, authentication requirements, result format, pagination, or potential limitations of Google Scholar. For a search tool with zero annotation coverage, this leaves significant gaps in understanding how the tool behaves.
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, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every word earning its place. There is no redundancy or fluff.
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 lack of annotations and output schema, the description is incomplete for effective tool use. It doesn't explain what the tool returns (e.g., article metadata, links, abstracts), any limitations (e.g., result count, sorting options), or how it differs from sibling search tools. For a search tool in a server with multiple similar tools, more context is needed to guide proper selection and invocation.
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 has 100% description coverage, with the single parameter 'query' documented as 'Academic topic or research query to search for'. The description doesn't add any additional meaning beyond what the schema provides (e.g., examples of valid queries, formatting tips, or scope clarifications). With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting.
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: 'Search for academic research articles using Google Scholar'. It specifies the verb ('search'), resource ('academic research articles'), and platform ('Google Scholar'). However, it doesn't explicitly differentiate from sibling tools like 'search-medical-journals' or 'search-medical-literature', which appear to serve similar search functions in related domains.
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 no guidance on when to use this tool versus alternatives. It doesn't mention any specific context, prerequisites, or exclusions, nor does it reference sibling tools that might be more appropriate for medical-related searches (e.g., 'search-medical-journals' or 'search-medical-literature'). The agent must infer usage from the tool name and description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search across multiple medical databases (PubMed, Google Scholar, Cochrane, ClinicalTrials.gov) for comprehensive results
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Medical topic or condition to search for across multiple databases |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool searches across multiple databases for comprehensive results but lacks details on rate limits, authentication needs, result format, pagination, or error handling. This is a significant gap for a search tool with no structured safety hints.
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, efficient sentence that front-loads the key action and resources. It avoids unnecessary words, though it could be slightly more structured by explicitly listing use cases or limitations.
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 complexity of searching multiple medical databases, no annotations, and no output schema, the description is incomplete. It doesn't explain result types, handling of multiple sources, or potential constraints, making it inadequate for informed tool selection by an AI agent.
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 has 100% description coverage, with the 'query' parameter documented as 'Medical topic or condition to search for across multiple databases'. The description adds no additional parameter details beyond this, so it meets the baseline of 3 where the schema does the heavy lifting.
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 action ('Search across multiple medical databases') and the resource ('medical databases'), specifying PubMed, Google Scholar, Cochrane, and ClinicalTrials.gov. It distinguishes from some siblings like 'search-google-scholar' (single database) but not all, such as 'search-medical-literature' which might overlap.
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 explicit guidance on when to use this tool versus alternatives is provided. It mentions 'comprehensive results' but doesn't clarify when to choose this over siblings like 'search-medical-journals' or 'search-medical-literature', leaving usage context 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.
Search specific medical journals (NEJM, JAMA, Lancet, BMJ, Nature Medicine) for high-quality research
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Medical topic or condition to search for in top medical journals |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions searching 'specific medical journals' and 'high-quality research', but does not describe how results are returned (e.g., format, pagination), what constitutes 'high-quality', or any limitations (e.g., access restrictions, rate limits). This leaves significant gaps for a search tool with no annotation coverage.
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, efficient sentence that directly states the tool's function without unnecessary words. It is appropriately sized and front-loaded, making it easy to understand quickly with zero wasted information.
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 lack of annotations and output schema, the description is incomplete for a search tool. It does not explain what the tool returns (e.g., article titles, summaries, links), how results are filtered or ranked, or any behavioral traits like error handling. This leaves the agent with insufficient context to use the tool effectively.
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 has 100% description coverage, with the single parameter 'query' documented as 'Medical topic or condition to search for in top medical journals'. The description adds minimal value beyond this, only implying the query should target the listed journals. With high schema coverage, the baseline score of 3 is appropriate as the schema does most of the work.
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: searching specific medical journals (NEJM, JAMA, Lancet, BMJ, Nature Medicine) for high-quality research. It specifies both the action ('search') and the target resources (named journals), but does not explicitly distinguish it from similar siblings like 'search-medical-literature' or 'search-google-scholar', which prevents a perfect 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 description provides minimal guidance on when to use this tool, mentioning only that it searches 'specific medical journals' for 'high-quality research'. It does not explain when to choose this over alternatives like 'search-medical-literature' or 'search-google-scholar', nor does it specify any prerequisites or exclusions for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for medical research articles in PubMed
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Medical topic or condition to search for | |
| max_results | No | Maximum number of articles to return (max 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('Search for') but doesn't describe what the search returns (e.g., article titles, abstracts, metadata), whether it's paginated, rate-limited, or requires authentication. For a search tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
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, efficient sentence that front-loads the core purpose without unnecessary words. Every part of the sentence ('Search for medical research articles in PubMed') contributes directly to understanding the tool's function, 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?
Given the tool's complexity (search operation with 2 parameters) and lack of annotations and output schema, the description is incomplete. It doesn't explain what the search returns (e.g., list of articles with IDs), how results are sorted, or any limitations (e.g., date ranges, filters). For a search tool without structured output information, more context is needed to guide effective use.
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 both parameters ('query' and 'max_results') with clear descriptions and constraints. The description adds no additional parameter semantics beyond what's in the schema, such as query syntax examples or result formatting. Baseline 3 is appropriate when the schema handles parameter documentation effectively.
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 verb ('Search for') and resource ('medical research articles in PubMed'), making the purpose immediately understandable. It distinguishes itself from siblings like 'search-clinical-guidelines' or 'search-medical-journals' by specifying PubMed as the target database. However, it doesn't explicitly contrast with 'search-medical-databases' or 'search-google-scholar', which might cover overlapping content.
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 no guidance on when to use this tool versus alternatives like 'search-medical-databases' or 'search-google-scholar'. It doesn't mention prerequisites, such as needing a specific query format or when to prefer PubMed over other sources. Without this context, the agent must infer usage from the tool name alone.
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.
v1.0.0check-drug-interactionsget-article-detailsget-drug-detailsget-health-statisticssearch-clinical-guidelinessearch-drug-nomenclaturesearch-drugssearch-google-scholarsearch-medical-databasessearch-medical-journalssearch-medical-literatureScored across 11 tools
Multiple tools have overlapping purposes that could cause confusion, such as search-medical-databases, search-medical-journals, search-medical-literature, and search-google-scholar all targeting article/research searches with unclear boundaries. Similarly, search-drug-nomenclature and search-drugs both handle drug searches but from different sources, potentially leading to misselection. The descriptions help somewhat, but the significant overlap reduces clarity.
The naming follows a consistent verb-noun pattern with hyphens (e.g., check-drug-interactions, get-article-details), which is predictable and readable. There are minor deviations, such as some tools using 'get' and others using 'search', but overall the convention is maintained throughout the set, making it easy to understand the tool functions at a glance.
With 11 tools, the count is reasonable and well-scoped for a medical information server, covering drug interactions, drug details, health statistics, clinical guidelines, and various search functionalities. It's slightly on the higher side but not excessive, as each tool appears to serve a distinct purpose within the medical domain, making it manageable for agents to navigate.
The tool set covers key areas like drug information, medical literature, and health statistics, but there are notable gaps. For example, it lacks update or delete operations for any resources, and there's no clear lifecycle management for medical data (e.g., no tools for patient records or treatment plans). While agents can work around this for information retrieval, the surface is incomplete for broader medical workflows.
MCP gateway federating 22 biomedical MCP servers behind one endpoint: gnomAD, ClinVar, HPO, VEP.
Auditable MCP server for PubMed, Europe PMC, ClinicalTrials.gov, and bioRxiv/medRxiv queries
MCP server for medicare-coverage
MCP server for US nursing facility search and ownership lookup (NursingHomeDatabase).
