medical-mcp

by JamesANZ

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation2/5
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.
Naming Consistency4/5
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.
Tool Count4/5
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.
Completeness3/5
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.
Average 3/5 across 11 of 11 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 0 of 1 community issues answered or closed in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
Tools from this server were used 35 times in the last 30 days.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives 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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![medical-mcp MCP server](https://glama.ai/mcp/servers/JamesANZ/medical-mcp/badges/card.svg)](https://glama.ai/mcp/servers/JamesANZ/medical-mcp)

Score Badge

Copy to your README.md:

[![medical-mcp MCP server](https://glama.ai/mcp/servers/JamesANZ/medical-mcp/badges/score.svg)](https://glama.ai/mcp/servers/JamesANZ/medical-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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