The Medical MCP Server provides comprehensive access to authoritative medical information from multiple databases including FDA, WHO, PubMed, RxNorm, and Google Scholar.
Drug Information & Safety:
Search FDA drug database by name or retrieve detailed information by NDC code (manufacturer, dosage, warnings, clinical pharmacology)
Search RxNorm for standardized drug nomenclature with RxCUI codes and synonyms
Check for potential drug-drug interactions between two medications
Medical Research & Literature:
Search PubMed for medical research articles and retrieve detailed information by PMID
Search Google Scholar for academic papers with citation data and abstracts
Query top medical journals (NEJM, JAMA, Lancet, BMJ, Nature Medicine) for high-quality research
Conduct multi-database searches across PubMed, Google Scholar, Cochrane, and ClinicalTrials.gov simultaneously
Clinical Guidelines & Health Statistics:
Search for clinical practice recommendations from major medical organizations
Access WHO Global Health Observatory data for health indicators like life expectancy, mortality rates, and disease prevalence by country
Search Parameters: Configurable result limits (1-50 for drugs, 1-20 for articles and health stats), country-specific filtering for health statistics, and organization-specific filtering for clinical guidelines.
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 "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@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, 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, WHO, PubMed, RxNorm, Google Scholar, AAP, pediatric journals
⚡ Easy Setup – One-click install in Cursor or simple manual setup
🔬 Comprehensive – Drug info, health stats, medical literature, clinical guidelines, pediatric sources
Related MCP server: DrugWise
Ready to bring medical intelligence into your AI workflow? Install in seconds:
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 database by brand or generic name
get-drug-details – Get comprehensive drug info by NDC code
search-drug-nomenclature – Standardized drug names via RxNorm
get-health-statistics – WHO Global Health Observatory data (life expectancy, mortality, disease prevalence)
search-medical-literature – Search 30M+ PubMed articles
get-article-details – Detailed article info by PMID
search-google-scholar – Academic research with citations
search-medical-databases – Multi-database search (PubMed, Scholar, Cochrane, ClinicalTrials.gov)
search-medical-journals – Top journals (NEJM, JAMA, Lancet, BMJ, Nature Medicine)
search-clinical-guidelines – Practice recommendations from medical organizations
search-pediatric-guidelines – AAP guidelines and Bright Futures preventive care
search-pediatric-literature – Research from major pediatric journals (Pediatrics, JAMA Pediatrics, etc.)
get-child-health-statistics – Pediatric health indicators from WHO (mortality, immunization, nutrition)
search-pediatric-drugs – Drugs with pediatric labeling and dosing information
search-aap-guidelines – Comprehensive AAP guideline search (Bright Futures + Policy Statements)
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
# Clone and build
git clone https://github.com/JamesANZ/medical-mcp.git
cd medical-mcp
npm install
npm run build
# Run server
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"]
}
}
}Restart Claude Desktop after configuration.
Ask about a medication's uses, dosage, and safety information:
{
"tool": "search-drugs",
"arguments": { "query": "Tylenol", "limit": 5 }
}Retrieve global health indicators like life expectancy or mortality rates:
{
"tool": "get-health-statistics",
"arguments": {
"indicator": "Life expectancy at birth (years)",
"country": "USA"
}
}Find peer-reviewed research articles on any medical topic:
{
"tool": "search-medical-literature",
"arguments": { "query": "COVID-19 treatment", "max_results": 10 }
}Source | Coverage | Update Frequency |
FDA | All FDA-approved drugs (US) | Real-time |
WHO | Global health stats (194 countries) | Annual |
PubMed | 30M+ medical citations | Daily |
RxNorm | Standardized drug nomenclature (US) | Weekly |
Google Scholar | Academic papers across disciplines | Real-time |
AAP | Bright Futures guidelines & policy statements | Periodic |
Pediatric Journals | Major pediatric journals (Pediatrics, JAMA Pediatrics, etc.) | Daily |
✅ Localhost-only – Server runs locally, no external access
✅ No data storage – All queries are real-time, nothing saved
✅ Process isolation – Medical data stays on your machine
✅ No API keys – No credentials to manage or leak
Medical Researchers – Quick literature reviews without paywalls
Healthcare Developers – Build prototypes with real medical data
Students – Access drug information and research papers
Clinicians – Reference tool for drug details and health statistics
Pediatricians – AAP guidelines, Bright Futures, pediatric literature, and child health data
The server includes an in-memory caching layer to improve response times and reduce API calls:
Automatic Caching: All API responses are cached with source-specific TTL policies
TTL Policies:
FDA data: 24 hours
PubMed articles: 1 hour
WHO statistics: 7 days
RxNorm nomenclature: 30 days
Clinical guidelines: 7 days
Google Scholar: 1 hour
Bright Futures: 30 days
AAP Policy: 7 days
Pediatric journals: 1 hour
Child health indicators: 7 days
Pediatric drugs: 24 hours
Cache Management: Automatic cleanup of expired entries every 5 minutes
LRU Eviction: Least recently used entries are evicted when cache exceeds 1000 entries
Cache Statistics: Use get-cache-stats tool to view hit rates and memory usage
Configuration (via environment variables):
CACHE_ENABLED=true - Enable/disable caching (default: true)
CACHE_MAX_SIZE=1000 - Maximum cache entries (default: 1000)
CACHE_TTL_FDA=86400 - FDA TTL in seconds (default: 86400)
CACHE_TTL_PUBMED=3600 - PubMed TTL in seconds (default: 3600)
CACHE_TTL_WHO=604800 - WHO TTL in seconds (default: 604800)
CACHE_TTL_RXNORM=2592000 - RxNorm TTL in seconds (default: 2592000)
CACHE_CLEANUP_INTERVAL=300000 - Cleanup interval in milliseconds (default: 300000)
Performance: Cached responses typically return in <10ms vs 800-1500ms for API calls. Expected cache hit rate: 60%+ for common queries.
Built with: Node.js, TypeScript, MCP SDK
Dependencies: @modelcontextprotocol/sdk, superagent, puppeteer, zod
Platforms: macOS, Windows, Linux
Note: Google Scholar access uses web scraping with rate limiting. Other sources use official APIs.
⚠️ 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. Dates show when Glama detected each change.
v1.0.0check-drug-interactionsget-article-detailsget-drug-detailsget-health-statisticssearch-clinical-guidelinessearch-drug-nomenclaturesearch-drugssearch-google-scholarsearch-medical-databasessearch-medical-journalssearch-medical-literatureMultiple 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP gateway federating 21 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).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JamesANZ/medical-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
