Medical Terminologies MCP

Server Quality Checklist

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

Latest release: v1.8.0
Disambiguation4/5
Most tools are clearly grouped by terminology with distinct actions (search vs details vs hierarchy), but 'cid10_chapter' and 'cid10_chapters' differ only in plural and granularity, and 'map_loinc_to_snomed' may be mistaken for a real mapping tool despite being guidance only. Overall, tools are mostly distinguishable.
Naming Consistency3/5
Names are mostly lowercase snake_case with terminology prefixes, but suffix usage is inconsistent: some use verbs like 'search' or 'lookup', others use nouns like 'details' or 'concept'. Pluralization inconsistency in 'cid10_chapter' vs 'cid10_chapters' and cross-cutting tools (e.g., 'find_equivalent', 'validate_codes', map_*) break the pattern.
Tool Count3/5
31 tools is high but justified by the multi-terminology scope; however, it exceeds typical well-scoped ranges and includes near-duplicates (cid10_chapter vs cid10_chapters) and a guidance-only tool (map_loinc_to_snomed) that could be documentation. Slightly over-scoped but not unreasonable.
Completeness2/5
A significant gap exists: no direct SNOMED CT search or lookup tool despite SNOMED being listed in the server's terminology set and accepted by 'validate_codes' and 'find_equivalent'. Also, no dedicated ICD-10 search/lookup (only CID-10 and mapping), creating dead ends for agents needing those specific codes.
Average 4.3/5 across 31 of 31 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 2 of 2 community issues answered or closed in the last 6 months
- 53 commits in the last 12 weeks
- Last stable release on August 10, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
This server has been verified by its author.
View related servers

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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is known. The description adds no new behavioral details beyond what the schema already states about direction values returning ancestors or subcategories. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is logically structured but somewhat redundant: the bullet list restates the opening sentence, and the final sentence repeats the schema text. It could be condensed to two sentences without losing meaning, so it's not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple navigation tool with only two parameters, an output schema, and strong annotations, the description covers the essential purpose and usage adequately. No critical information appears missing, though it could mention output behavior if not already covered by the output schema.
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 baseline is 3. The description's explanation of 'parents' and 'children' largely duplicates the schema's parameter descriptions, providing no additional semantics beyond what's already structured.
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 explicitly states it navigates the ICD-11 hierarchy to find parent or child entities. It clearly distinguishes itself from sibling tools like icd11_search or icd11_lookup by focusing on hierarchical relationships. The bullet list further clarifies the specific use cases.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases: finding broader categories, finding subtypes, and understanding classification structure. It does not explicitly name alternative tools or say when not to use it, but the context is clear enough that an agent would understand when to select this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the safety profile is well covered. The description adds the return format (names, components, properties) but does not disclose additional behavioral characteristics beyond the annotations. With strong annotations, the description's minimal extra disclosure is acceptable. Score 3.
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 concise and well-structured, with a clear main statement, bulleted use cases, and a return summary. Every sentence contributes value, and there is no redundant fluff. Score 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward search tool with a rich output schema and strong annotations, the description covers the key use cases and return content. It could benefit from a note about when to use related LOINC tools, but that is a usage-guideline nuance rather than a completeness gap. Given the low complexity and adequate annotations/schema, the description is sufficiently complete. Score 4.
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 already documents both parameters (query and max_results) with clear descriptions, giving 100% coverage. The tool description does not add any additional parameter semantics beyond what the schema provides, so baseline 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 tool's function: searching LOINC for laboratory tests, clinical observations, and measurements. It gives concrete use cases and specifies what it returns. However, it does not explicitly distinguish this search tool from sibling LOINC tools like loinc_details or loinc_answers, so it gets a 4 rather than a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool to' section provides explicit scenarios for when to use the tool, such as finding LOINC codes for lab tests, clinical measurements, and diagnostic observations. It does not explicitly state when not to use it or mention alternatives, but the context is clear. Score 4.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey the read-only, idempotent, and non-destructive nature. The description adds useful behavioral context about the data returned (concept status, related concepts), but it does not clarify that related concepts are only returned when include_related=true, which is a minor transparency gap.
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 well-structured with a concise opening, bullet points for use cases, and a clear instruction. It avoids fluff, though it is slightly longer than necessary, which keeps it from a perfect score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description sufficiently covers purpose, usage, and parameter details. The only notable gap is the lack of explicit mention that include_related controls the 'View related concepts' bullet, but overall it is adequately complete.
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 provides complete descriptions for both parameters (100% coverage). The description adds only a concrete example RXCUI ('161') but no additional semantic meaning beyond the schema, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get detailed information about a specific RxNorm concept by RxCUI.' It uses a specific verb and resource, and the listed use cases (full name, synonyms, status, related concepts) distinguish it from sibling search tools like rxnorm_search or rxnorm_ingredients.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: 'Use this tool to...' with specific scenarios, and gives an example RXCUI. However, it does not explicitly mention alternatives or when not to use it, so it lacks exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well covered. The description adds a return-value summary but does not disclose matching semantics, pagination, external API behavior, or rate limits. No contradiction with annotations.
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 front-loaded with a clear purpose sentence, followed by a compact bulleted list of use cases and a concise return-value summary. Every sentence earns its place without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter surface, rich annotations, and presence of an output schema, the description covers what is needed for basic invocation. It could be more complete by explicitly directing users to sibling tools for concept details or NDC lookups, but that gap is not critical for a search operation.
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 both 'query' and 'max_results' already well documented (including default, min, max). The description's mention of brand/generic search aligns with the query parameter but adds no new semantic nuance beyond the schema, so baseline 3 is appropriate.
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 states a specific verb+resource ('Search for drugs in RxNorm') and enumerates concrete use cases: find by brand/generic, look up for prescribing, search formulations. It also specifies return values (RxCUI identifiers, names, term types), which clearly distinguishes it from sibling lookup tools like rxnorm_concept or rxnorm_ndc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
A bulleted list gives clear usage contexts (brand/generic search, prescribing lookups, formulation search). However, it does not explicitly state when not to use the tool or name alternatives (e.g., rxnorm_concept for code-based lookup), so it lacks full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat safety. It adds valuable behavioral details: returns one entry per ATC code, combination products map to multiple, and it retrieves data via NLM RxClass. This goes beyond the annotations and enriches the agent's understanding of the response 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 concise and well-structured: an opening statement, a bulleted list of use cases, and a brief paragraph on return behavior and data source. Every sentence contributes meaningful information without redundancy, making it efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 parameter, output schema present, non-destructive annotations), the description is fully complete. It covers purpose, usage, return behavior, and data source. No critical context is missing for an agent to select and invoke the tool correctly.
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 already provides a description for drug_name ('brand or generic, e.g., "metformin"') and schema coverage is 100%, so the baseline is 3. The description adds a concrete example in context but does not introduce new parameter semantics beyond the schema. It does not compensate for any missing parameter details.
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: 'Look up the WHO ATC classification(s) for a drug by name.' It provides specific use cases and examples (e.g., metformin → A10BA02), making the verb and resource clear. However, it does not explicitly distinguish from sibling tools like atc_lookup or atc_members, so it misses the top score for sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear use context with a bulleted list of when to use the tool (find ATC code, identify hierarchy, cross-reference drugs). It does not, however, mention any exclusions or alternatives, such as when to use atc_lookup instead. This is clear context without explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds meaningful behavioral context by specifying that the tool returns a chapter's constituent groups and includes an example showing the output structure, which goes beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loads the core purpose, and uses a clear bulleted list for usage scenarios. The example is somewhat lengthy but adds valuable concreteness. It could be tightened slightly by removing the redundant 'Provide a chapter number (1-22)' since the schema already covers this.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and an output schema available, so the description does not need to detail return fields. It clearly communicates what the tool does and its primary usage contexts. This is sufficient for an agent to select and invoke the tool correctly.
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 fully documents the only parameter 'num' with type, range, and description, achieving 100% schema coverage. The description repeats the range (1-22) and provides an example, but adds no new semantic information beyond what the schema already offers, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('one CID-10 chapter and its constituent groups'), clearly distinguishing this from the sibling tool cid10_chapters (which likely lists all chapters) and cid10_lookup. The example with Chapter IX and its groups further clarifies what is returned.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context with a 'Use this tool to' list covering three practical scenarios (drill into groups, build hierarchical browsers, find containing group). It does not explicitly mention when not to use it or name alternative tools, but the purpose is distinct enough that context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the agent knows the operation is safe. The description adds scope details (28 chapters, all areas of medicine, top-level) but does not disclose further behavioral characteristics like ordering, pagination, or output structure. This is acceptable given the annotations, but the added behavioral context is minimal.
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 concise and well-structured. The first sentence clearly states the action, followed by a bulleted list of use cases. The final sentence provides factual context about the 28 chapters. Every sentence serves a purpose, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with no required parameters, a full output schema, and comprehensive sibling context, the description covers the essential aspects: what it does, when to use it, and its scope. The use cases are sufficient for an agent to select this tool over siblings. The output schema handles return value expectations.
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 a single 'language' parameter with 100% description coverage, including default, enum values, and behavior (official translations, no machine translation). The description adds no additional parameter semantics beyond the schema, so the baseline of 3 is appropriate.
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 'List all ICD-11 chapters (top-level categories)', specifying the exact verb and resource. It distinguishes this tool from siblings like icd11_lookup (which looks up specific codes) by emphasizing top-level categories and offering use cases like 'overview' and 'navigate to disease categories'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: get an overview, find which chapter covers a body system, and navigate to specific disease categories. This gives clear context for when to use the tool. It does not name alternative tools, but the implied boundaries (e.g., not for code-level lookup) are evident from the use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds detail about the returned fields but does not disclose additional behavioral traits such as error behavior, prerequisites, or rate limits. This meets the lower bar for annotated tools but offers no extra behavioral context.
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 concise and well-structured: a front-loaded purpose statement, a scannable bullet list of use cases, and a clear input format instruction. Every sentence earns its place, with no redundant elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple single-parameter, read-only tool with an output schema available. The description fully explains what the tool does, what information it returns, and how to provide the LOINC number. No additional context is needed for an agent to invoke it correctly.
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 for the single parameter, including pattern and an example. The tool description repeats the format and example ('XXXXX-X', '2339-0' for Glucose), which adds no meaningful information beyond what the schema already provides. Baseline of 3 applies.
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 'Get detailed information about a specific LOINC code' — a specific verb and resource. It enumerates the exact fields returned (full name, description, component, property, timing, system, scale type, method), which distinguishes it from siblings like loinc_search or loinc_answers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a 'Use this tool to' list with clear scenarios, implying when to use it (when you have a specific LOINC code and need details). However, it does not explicitly mention when not to use it or name alternative tools, so it falls short of full exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns a list of LOINC codes, which is useful context, but does not disclose error handling or edge cases. This is adequate given the strong 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 concise and well-structured with a clear opening sentence followed by bullet points. It is front-loaded with the key action and contains no redundant information or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (one parameter, high schema coverage, and rich annotations), the description is complete enough. It explains the purpose, use cases, and return value, and an output schema exists, so detailed return documentation is not required. The description covers all essential aspects for an AI agent to invoke it correctly.
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% coverage with a clear description for loinc_num including format and example. The tool description does not add extra semantic value beyond what the schema already provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('structure of a LOINC panel or form'). It also provides concrete examples (CBC, metabolic panel) and explicitly mentions returning the list of LOINC codes, which distinguishes it from sibling tools like loinc_search and loinc_details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear use cases ('See all tests included in a panel', 'Get the structure of assessment forms', 'Find related observations grouped together'), which implies when to use it over searching or details. However, it does not explicitly mention alternatives or exclusions, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds the example and the concept that qualifiers refine descriptors, but does not disclose additional behavioral traits such as pagination, rate limits, or error handling. This is sufficient given the annotation coverage, but not exceptional.
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 efficient: a single opening sentence, a bullet list of use cases, and a one-line example. Every sentence contributes to understanding the tool, with no wasted words. The structure is front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and an output schema, the description covers the purpose, usage context, and gives a concrete example. It does not need to explain return values because an output schema exists. The annotations provide safety context. The description is complete for its complexity.
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 for 'mesh_id' is 100% coverage, including pattern and example. The tool description mentions 'MeSH descriptor' and provides an example, but does not add meaning beyond what the schema already captures. Baseline 3 is appropriate.
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 tool's function: 'Get allowed qualifiers (subheadings) for a MeSH descriptor.' This is a specific verb+resource combination that distinguishes it from sibling tools like mesh_descriptor or mesh_tree, which have different purposes. The example 'Diabetes Mellitus/drug therapy' further clarifies the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The bullet-point list explicitly says when to use this tool: to find combinable qualifiers, build precise search queries, and understand specifiable aspects. It provides clear context, but does not explicitly mention when not to use it or name alternative tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already thoroughly cover safety traits (readOnlyHint, idempotentHint, destructiveHint), lowering the bar for behavioral disclosure. The description adds a sentence about return contents (class IDs, names, sources) but does not discuss error handling, rate limits, or other behavioral nuances. This provides some extra value without contradicting annotations.
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 compact and well-structured: a single-sentence purpose, a bulleted list of use cases, and a final sentence on return values. Every section adds value and there is no redundant or verbose phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter), extensive annotations, and presence of an output schema, the description adequately covers purpose, usage, and return content. It does not exhaustively describe edge cases, but that is not necessary given the schema and annotation richness.
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 fully documents the only parameter, rxcui, with a description ('RxCUI of the drug') and a regex pattern. The description does not add additional semantics beyond restating that the tool operates on a drug. With 100% schema coverage, a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource, 'Get therapeutic and pharmacologic classes for a drug,' and includes concrete examples ('Beta-blockers', 'NSAIDs'). This clearly distinguishes it from sibling tools like rxnorm_search or rxnorm_ingredients by focusing on classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool to' section provides explicit use cases: finding drug class, therapeutic categories, and mechanism of action classifications. This gives clear context for invocation, though it does not explicitly name alternative tools or state exclusions, so it lacks the full 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds that it returns ingredient RxCUIs and names, which is useful but not extensive behavioral disclosure (e.g., error handling, rate limits). This is acceptable given the strong 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 opens with a clear one-sentence summary, followed by concise use-case bullets and a return statement. Every sentence adds value, with no redundancy or padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter read-only tool with an output schema available, this description sufficiently covers input, purpose, and return type. The presence of the output schema means return values don't need further elaboration in the description.
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 for 'rxcui' is complete ('RxCUI of the drug') and covers 100% of the parameter. The tool description reiterates 'by RxCUI' without adding new semantics, so it does not exceed the baseline for high schema coverage.
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?
Description uses a specific verb ('Get') with a clear resource ('active ingredients') and input ('by RxCUI'). The use-case bullets clearly differentiate it from sibling tools like rxnorm_search and rxnorm_concept, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The bullet list provides clear scenarios (finding ingredients, checking single vs. multiple, identifying generic components of brand drugs), offering solid context on when to use it. It stops short of explicitly stating when not to use it or naming alternative tools, so it lacks full exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable context: each member includes a substance-level 7-char ATC code via source_atc_code for disambiguation at levels 1-4, and the RxNorm catalog is US-centric while ATC codes are international. This goes beyond the schema and annotations, providing behavioral and data-scope 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 well-structured and front-loaded with the main purpose. The bullet-point list of use cases is concise and scannable. The final caveat about US-centric data is relevant and non-repetitive, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool with an output schema and strong annotations, the description covers purpose, use cases, return field nuance, and data scope caveat. It doesn't mention pagination or limiting, but such details are typically not critical for a straightforward listing operation, and the existing schema and annotations fill the gap.
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 provides 100% coverage for atc_code, including a full description of level behavior (levels 1-4 return all members, level 5 returns a single substance). The description reinforces this with an example but doesn't add substantial new information about the parameter itself, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('drugs that belong to an ATC class'), making the tool's purpose immediately clear. It distinguishes from sibling tools like atc_lookup (which likely provides code details) and atc_classify (which assigns ATC classes) by focusing on enumerating class members. A concrete example (A10BA → metformin, phenformin) further anchors the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides three explicit use cases ('Enumerate all members...', 'Build a list of drugs sharing a pharmacological mechanism', 'Explore an ATC subtree at any level'), which clearly establish when to use the tool. However, it does not explicitly mention alternatives or when not to use it, such as differentiating from atc_lookup for single-code lookups.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only/idempotent safety. The description adds the language translation nuance (official translations only, example 'pt') but doesn't disclose much beyond what the schema already states. No contradiction.
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?
Very concise, two sentences with a bulleted list. Front-loaded with purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and annotations are good, the description adequately covers input rules and intended use. Could mention searching for an entity first, but that's a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema documents all three parameters at 100% coverage, but the description adds the key constraint that code and URI are mutually exclusive alternatives, plus an example language value. This exceeds the baseline.
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 opens with a specific verb+resource ('Get detailed information about an ICD-11 entity by code or URI') and lists concrete use cases (definition, coding notes, exclusions, synonyms), clearly distinguishing it from sibling search/hierarchy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear 'Use this tool to' bullet list and specifies input requirements (code or URI). However, it doesn't explicitly mention when NOT to use it or suggest alternatives like icd11_search for finding entities first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, openWorld, and idempotent, so the description adds value by detailing return contents (codes, titles, relevance scores) and the language behavior (official translations, never machine-translated). This goes beyond the annotations without contradicting them.
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 well-structured with a brief opening statement, bulleted use cases, a specific language note, and a return summary. Every sentence contributes, and it is concise without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description covers purpose, use cases, language behavior, and return types. It is complete for a search tool, though it could briefly mention when to use this instead of a lookup tool, but this is a minor gap given sibling names are self-explanatory.
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 baseline is 3. The description adds a concrete example for 'language' (Portuguese) and clarifies 'query' accepts disease names, but these largely echo the schema. No new parameter-level semantics are introduced.
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 tool searches for medical conditions in ICD-11, with specific use cases like finding codes, searching by name/keyword, and multilingual lookup. The verb 'Search' and resource 'ICD-11' are explicit, and the tool is differentiated from siblings like icd11_lookup by its focus on search rather than lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool to' section provides clear scenarios (finding codes, searching by disease, multilingual lookup) and the language example gives concrete guidance. It does not explicitly compare to alternatives like icd11_lookup, but the use cases are specific enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already state readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by explaining what postcoordination means and the type of information returned (axes, required vs optional, extensions), which goes beyond the annotations without contradicting them.
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 concise and well-structured: a one-sentence summary, a bulleted list of use cases, and a clarifying sentence. No filler—every line adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter tool, rich output schema, and clear annotations, the description covers the essential purpose and use cases. It is complete for an agent to decide when and how to invoke this tool.
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 single parameter 'code' is fully described in the schema (100% coverage). The description does not add param-specific details like format or examples, but the schema already provides adequate semantics. Baseline of 3 is appropriate.
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 starts with a clear verb+resource: "Get postcoordination information for an ICD-11 code." It distinguishes itself from sibling tools like icd11_search, icd11_lookup, and icd11_hierarchy by focusing specifically on postcoordination axes, required vs optional details, and extension possibilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use guidance via a bulleted list (find axes, check required vs optional, understand extensions). It does not explicitly mention when NOT to use the tool or alternatives, but the use cases clearly differentiate it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, so the agent knows this is a safe, read-only operation. The description adds useful behavioral context about the applicability restriction (only LOINC codes with defined answer sets), which goes beyond the annotations. It does not describe return format, but an output schema exists, so that burden is reduced.
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 compact and well-organized: a one-sentence summary, three bullet use cases, and one clarifying constraint. No filler or redundant content. It is front-loaded with the core action and remains highly scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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), strong annotations, and presence of an output schema, the description is sufficiently complete. It states what the tool does, when to use it, and the applicable input scope. No critical information appears missing for an agent to select and invoke the tool correctly.
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 covers 100% of parameter information: the loinc_num parameter has a pattern and an example description. The tool description adds no further parameter semantics beyond what the schema already provides, so 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear, specific verb+resource: 'Get the list of valid answers for a LOINC questionnaire item.' It immediately distinguishes this tool from siblings like loinc_search (search) and loinc_details (details), and the following bullets reinforce the purpose without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('Find valid response options', 'Get answer codes', 'Look up standardized answer lists') and includes a key constraint: 'Only applicable to LOINC codes that represent questions with defined answer sets.' It does not explicitly name alternative tools, but the constraint implies when not to use it, and sibling tool names provide context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, covering the safety profile. The description adds value by explaining how MeSH tree numbers represent hierarchical paths with a concrete example (C14.280.647), which helps the agent understand the nature of the output.
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 concise and well-structured, leading with the core purpose, followed by a bulleted list of use cases, and a brief explanatory sentence about tree numbers. Every sentence adds value, and there is no unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, full schema coverage, existing output schema, and strong annotations, the description provides all necessary context. It explains the domain concept (tree numbers), gives an example, and lists practical use cases, making it complete for an agent to effectively use the tool.
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 already provides full parameter documentation (100% coverage) with the description 'MeSH Descriptor ID (e.g., D015242, D003920)'. The tool description does not add additional parameter semantics beyond what the schema already includes, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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: 'Get the tree hierarchy location(s) for a MeSH descriptor.' It is specific, uses a clear verb, and differentiates from sibling tools like mesh_search and mesh_descriptor by focusing solely on tree hierarchy locations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases ('See where a term fits in the MeSH hierarchy,' 'Understand broader/narrower relationships,' 'Find related terms in the same branch'), giving clear context for when to use this tool. However, it does not explicitly mention alternatives or exclusion criteria, relying on the sibling list for differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds the detail that it returns 'all NDC codes' and supports cross-referencing, which is useful. However, it does not disclose additional behavioral nuances such as error handling or normalization behavior, so the value added beyond annotations is moderate.
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 concise and well-structured: a one-sentence summary, a bullet list of use cases, and a clear input instruction. Every sentence contributes meaningful information without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 parameters, no nested objects) and the presence of an output schema, the description covers the essential scenarios and input patterns. It does not need to explain return values, and it adequately covers the two main usage modes. The description is complete for an agent to select and invoke this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes both parameters (ndc and rxcui) with full coverage. The description adds semantic meaning by explaining the mutual exclusivity ('Provide either an RxCUI... or an NDC...'), which is not evident from the schema alone. This enriches parameter understanding beyond the structured definitions.
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 'Map between RxNorm concepts and National Drug Codes (NDC)' with specific use cases (get NDCs by RxCUI, find RxCUI by NDC). This distinguishes it from sibling tools like rxnorm_search or rxnorm_concept, which focus on searching rather than bidirectional mapping.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit use cases in a bullet list and states the input requirement ('Provide either an RxCUI to get NDCs, or an NDC to get the RxCUI'). However, it does not explicitly mention when NOT to use this tool or compare it to alternatives, as none of the sibling tools are referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds rich behavioral detail beyond the annotations: it explains the exact return fields (valid, active, title, replaced_by, source, error), the semantics of active/null for different terminologies, and the error disambiguation ('valid: false + error: null' vs 'valid: false + error: set'). It also notes the hard cap and parallel execution with latency implications, and mentions the SNOMED feature flag. These are valuable context that annotations alone do not provide.
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 well-structured with a clear opening sentence, a use-case paragraph, a bulleted list of return fields, and notes on terminology and performance. It is appropriately detailed for a complex tool. It is slightly verbose, but every sentence contributes meaningful information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is comprehensive given the tool's complexity. It covers the purpose, use cases, return value semantics, error handling, accepted terminologies, input requirements, and performance characteristics. The output schema exists but is not provided, so the detailed return-field documentation in the description is essential and fully covers what an agent needs to invoke and interpret results correctly.
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 baseline is 3. The schema already documents the 'codes' array, the 'code' string, and the 'terminology' enum, including the rationale for required terminology and the 50-item cap. The description largely repeats these details (e.g., the same 'A00' example and cap rationale) without adding new parameter-specific semantics, so it earns the baseline rather than higher.
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 tool's function: 'Validate a mixed batch of medical codes against their source terminologies.' It specifies the verb (validate), the resource (medical codes), and the scope (against source terminologies). It also distinguishes itself from siblings by focusing on batch validation across terminologies rather than lookup/search of individual codes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly gives a use case: 'Useful for retrospective analysis of legacy databases — flag codes that no longer exist, surface ICD-10 → ICD-11 replacements, and grade activity status.' It implies when not to use (e.g., for singular lookups, use the individual terminology search tools) but does not explicitly name alternatives or exclusions, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so safety is covered. The description adds valuable behavioral context: returns exactly 22 entries, the dataset is static since 2008, and titles are in Portuguese. This goes beyond the annotations' safety profile.
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 front-loaded with the core purpose in the first sentence, followed by a concise bullet list of use cases, and ends with a short note on version currency. Every sentence earns its place; there is no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no parameters and an output schema present, the description sufficiently covers what the tool returns (22 chapters, code ranges, Portuguese titles) and adds the version caveat. It is complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the baseline for 0 params is 4. The description does not need to explain parameter details since none exist. It instead clarifies what the output contains, which is appropriate.
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 opens with a specific verb+resource: 'List the 22 chapters of CID-10 with their code ranges and Portuguese titles.' This clearly distinguishes from siblings like cid10_chapter (singular) and icd11_chapters by specifying the CID-10 scope, the count (22), and the output content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool to' bullets provide explicit use cases (view top-level structure, map codes to chapters, build navigable TOC). While it doesn't explicitly mention when not to use or name alternatives, the context of sibling tools makes the appropriate use clear. The guidance is concrete and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only/idempotent; description adds meaningful behavior: diacritic-insensitive matching, category/subcategory granularity, and the V2008 version being searched. These are not in the schema/annotations and help set expectations. No contradiction.
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 organized with a lead sentence, bullet list, and closing behavioral note. Each segment earns its place (examples, version, diacritics), with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With output schema present and annotations covering safety, the description covers purpose, usage guidelines, version, and behavior—everything an agent needs to decide to invoke vs. select an alternative.
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?
Input schema already describes all three parameters with 100% coverage (query minLength, level enum, max_results range). Description reiterates the level concept (categories/subcategories) but adds no new parameter semantics beyond the schema.
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?
Description opens with a specific verb+resource: 'Search the Brazilian CID-10 ... by Portuguese text.' It explicitly distinguishes from siblings by naming the ICD-11 alternative, making the tool's scope (Brazilian/Portuguese) unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Lists concrete use cases (SUS/ANVISA contexts, official translation lookup, billing/epidemiology) and explicitly states when NOT to use it: for ICD-11, use icd11_search instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and open-world. The description adds meaningful context about language handling: 'content is never machine-translated,' ensuring agents understand the official-translation limitation. This goes beyond schema information and complements the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: main purpose first, then bulleted use cases, followed by a concrete example and language note. Every sentence contributes, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (which covers return structure), the description sufficiently covers purpose, parameters, and behavioral nuances. The tool is simple and the description provides all necessary context for correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing an example ID ('D015242') and clarifying the language parameter's behavior (official translations, default en). This enriches the parameter semantics beyond the raw schema definitions.
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 opens with 'Get detailed information about a MeSH descriptor by ID,' which is a specific verb+resource combination. It further enumerates uses (scope note, tree numbers, related concepts) and provides a concrete ID example, clearly distinguishing it from sibling tools like mesh_search and mesh_tree.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool to' list provides clear context on when to use it (full definition, hierarchy location, synonyms). It does not explicitly exclude alternatives but implies its role as a details endpoint. It would benefit from naming sibling tools like mesh_tree for specialized hierarchy traversal, but current guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior. The description adds valuable context: 'content is never machine-translated' and results include MeSH IDs and labels, which are behavioral nuances not fully covered by annotations.
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 concise at five sentences, with a clear structure: summary line, bulleted use cases, a language nuance note, and a return statement. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, return values need no further explanation. The description covers core use cases, translation behavior, and matching context, making it fully sufficient for a search tool with strong annotations and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description enriches the `language` parameter by explicitly stating it returns NLM's official translations and never machine-translates, and gives an example ('pt' for Portuguese). This adds semantic value beyond the schema.
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 uses a specific verb+resource ('Search for MeSH descriptors') and immediately lists concrete use cases: indexing medical literature, PubMed searches, and finding controlled vocabulary terms. This clearly distinguishes it from sibling tools like icd11_search or loinc_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool to' bullet list explicitly frames the intended contexts (indexing, PubMed subject headings, controlled vocabulary). It does not name alternatives or exclusions, but the use cases make it evident when this tool is appropriate relative to sibling search tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, the description goes beyond by stating 'It does not perform the mapping' and explains licensing constraints (UMLS license, LOINC Expression Association download). This adds critical behavioral context about what the tool actually returns (guidance, not a mapping) and the limitations of data availability.
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 longer than average but every sentence earns its place: it covers the tool's purpose, what it does not do, licensing context, and alternative tools. The paragraph structure is clear and front-loaded with the essential purpose. It is appropriately sized for the complexity of the tool's caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter, an output schema, and complex licensing/alternative considerations. The description covers all critical aspects: what it does, what it does not do, licensing requirements, programmatic alternatives, interactive alternatives, and input format example. There are no significant gaps in context.
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 already provides a full description ('LOINC code (e.g., 2339-0 for Glucose)') and pattern. The tool description adds examples ('2339-0' and '718-7') but these are redundant with the schema's example. With 100% schema coverage, no additional parameter semantics are necessary; the description provides a small reinforcement but no new information beyond the schema.
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 tool 'looks up a LOINC code in NLM Clinical Tables and returns guidance on where to obtain a LOINC → SNOMED CT mapping. It does not perform the mapping.' This is a specific verb+resource with an explicit limitation, distinguishing it from actual mapping tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit alternatives: 'For programmatic LOINC → SNOMED mapping, use UMLS or the LOINC Expression Association files. For interactive lookup, use the SNOMED CT browser available to your organization or the Regenstrief RELMA desktop tool.' It also explains when the tool is appropriate (guidance lookup) vs alternatives, making usage conditions clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the description doesn't repeat those. It adds value by disclosing the accepted code-length range, level hierarchy, and the endpoint's limitation regarding substance-level codes. It stops short of describing return shape or error handling, but the output schema covers the response.
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 well-structured with a leading summary sentence followed by a bullet list of use cases and a final clarification. Every sentence earns its place; no fluff or redundancy. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, the presence of an output schema, and the tool's straightforward nature, the description covers all necessary context: purpose, code-level semantics, exclusions, and a pointer to the alternative tool. No significant gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema's parameter description already repeats the 1-5 char level constraint and the substance-code exclusion. The description adds semantic enrichment by mapping each code length to its hierarchy level (anatomical, therapeutic, pharmacological, chemical), which aids understanding beyond the regex pattern.
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 opens with a specific verb+resource: 'Look up an ATC code at level 1-4 to get its name and hierarchy level.' It differentiates from sibling tools by explicitly naming atc_classify as the alternative for substance-level codes, making the tool's scope clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases ('Resolve an ATC code', 'Confirm a code exists', 'Identify the level') and an explicit exclusion with a named alternative: 'Substance-level codes (7 chars) are not exposed by this endpoint — use atc_classify'. This is clear when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, but the description adds valuable behavioral details: acceptance of both dotted and undotted code forms, return of canonical display, and conditional gender/cause-of-death restriction flags. This goes beyond the annotation baseline.
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 compact and well-structured: a one-sentence purpose, three bulleted use cases, and a final note on input normalization. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool with one fully documented parameter, rich annotations, and an output schema, the description covers all necessary aspects: purpose, input format, output behavior, and edge cases (dotted/undotted). No significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/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 the 'code' parameter well. The description adds meaning by clarifying the accepted input variants and the canonical output behavior, which is not in the schema.
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 tool's function: 'Look up a specific CID-10 code and return its Portuguese name.' It uniquely identifies exact-code lookup, distinguishing it from siblings like cid10_search (term search) and icd11_lookup (ICD-11).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Use this tool to' bullets provide clear context for when to use this tool: resolving codes, confirming existence, and retrieving restriction flags. However, it does not explicitly state when not to use it or list alternative tools, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent safely. The description adds meaningful context: it identifies the bundled CID-10 as frozen at V2008, notes the ICD-10 → ICD-11 transition tables are currently 2025-01, and clarifies that the ICD-10 → ICD-11 version is read live while other entries are project-release metadata. This goes beyond annotations and helps the agent anticipate dynamic vs. static data.
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 front-loaded with the core purpose, then uses compact bullet-style use cases that are directly actionable. Every sentence earns its place; there is no filler, redundant phrasing, or repetition of schema details already present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single optional parameter, an output schema, and clear annotations, the description covers all necessary context: purpose, use cases, data provenance, default behavior, and the distinction between live and bundled metadata. It is fully self-contained for an agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already has 100% coverage with an enum and description for the single optional parameter. The description reinforces behavior by stating filtering yields a single entry and omitting returns all 8, adding the concrete count and default semantics. This is a small but real enhancement over the schema alone.
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?
Description opens with a specific verb and resource: 'List the current version, release date, publisher, source URL, and update cadence of every terminology...' This clearly identifies the tool's output and scope. It also inherently distinguishes itself from sibling search/lookup/mapping tools by focusing on version metadata rather than content operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit use cases ('Useful for pipeline maintainers who need to...') and clear filtering instructions ('Pass `terminology` to filter... otherwise the full set of 8 is returned'). It does not explicitly state when not to use this tool in favor of alternatives, but the use-case framing provides strong contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial context beyond the annotations: it explains that the tool returns primary 1:1 mappings plus alternative candidates, includes ICD-11 code/title/chapter/URIs, covers exactly 11,243 ICD-10 categories (excluding chapters/blocks), accepts both dotted and undotted code forms, and returns an honest 'no mapping' rather than a fuzzy fallback. No contradictions with the readOnly/idempotent/openWorld 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 front-loaded with a precise definition and flows logically through return details, usage, coverage, input examples, and edge-case behavior. It is somewhat lengthy (7 sentences), but each sentence contributes unique information; it could be slightly tightened without losing value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so the description is not required to detail return values, yet it still explains them. It covers input formats, coverage, use cases, and the 'no mapping' failure mode. For a single-parameter mapping tool, this is fully complete and leaves no significant questions for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides a description for icd10_code (100% coverage), but the tool description goes further by giving concrete examples ('E11', 'I21', 'A07.8'), explaining that both dotted and undotted forms are accepted, and linking the code to WHO's category-level table. This enriches the parameter semantics considerably.
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 opens with 'Authoritative ICD-10 → ICD-11 mapping using WHO transition tables', giving a specific verb (map), resource (ICD-10 to ICD-11), and scope (authoritative, WHO-based). It further distinguishes from sibling text-search tools by stating it uses 'authoritative mapping rather than text-search candidates'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'for clinical coding, billing migration, retrospective analysis, and any workflow that needs authoritative mapping rather than text-search candidates.' It also clarifies behavior when a code is absent ('Returns "no mapping"... rather than a fuzzy search fallback'), guiding the agent to choose the right tool for the job.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already declaring readOnlyHint, openWorldHint, idempotentHint, the description adds behavioral context: the server doesn't ship historical snapshots, bundled_versions lists available versions, and the tool is guidance-only for most terminologies but surfaces a real WHO transition summary for ICD-10/11. No contradictions.
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 well-structured with purpose, guidance, special case, inputs, and caveats. It's slightly redundant (the 'metadata + guidance layer' sentence repeats the earlier 'guidance only' idea) but overall each section earns its place for a nuanced tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, limitations, parameter defaults, and special cases, while the output schema handles return-value details. No significant gaps for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100%, the description adds parameter semantics beyond the schema: default behavior when from_version/to_version omitted, and the special combination of terminology='icd10' with no to_version. This enriches the agent's understanding of how parameters interact.
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 opens with a specific verb+resource: 'Report what diff data is available between two versions of a terminology.' It clearly distinguishes from siblings by framing itself as a metadata/guidance layer rather than a diff engine, and explicitly contrasts with mapping tools like map_icd10_to_icd11.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to use the tool: for most terminologies it gives guidance-only and directs to the publisher's official changelog as authoritative; it gives a specific usage instruction for ICD-10 vs ICD-11 ('Use terminology: "icd10" with no to_version'), and states its intentional limitation as not a diff engine, thereby excluding it from actual diff tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only say readOnlyHint/openWorldHint/idempotentHint; the description adds substantial non-obvious behavior: match_score and rank are server-computed (upstreams don't expose comparable relevance), candidates are clustered in groups based on lexically identical titles, and absence of a group is explicitly NOT evidence of non-equivalence. It also discloses that the live fan-out has no stable cursor, so limit should be raised instead of paging, and that searches are English-only.
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 compact for the tool's complexity, front-loaded with the core purpose and use cases, followed by tightly scoped paragraphs covering scope, scoring, grouping, and language constraints. Every sentence earns its place; no filler or repetition of schema/annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a cross-terminology search tool with 4 parameters and an output schema, the description covers all practical concerns: how results are ranked/clustered, how filtering works, what the openWorldHint means here (absence of group is not negation), and when to use sibling tools for pt-BR. It even addresses pagination limitations. The output schema can handle return-value details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description elevates parameter understanding: explains limit as a per-terminology cap (not a page) with default 5 and max 10 due to no stable cursor, and clarifies how source_terminology and target_terminologies combine via subtraction. It also explains why source_terminology is useful (when you already have a code and want equivalents elsewhere), which is not apparent from the enum alone.
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 opens with 'Ranked unified search for equivalent terms across multiple medical terminologies,' giving a sharp verb+resource+scope. It further clarifies with bullets: 'Find the same concept in different coding systems', 'Compare how terminologies represent a concept', and 'Support terminology mapping and data integration'. This clearly separates it from sibling tools like icd11_search and mesh_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use the tool ('Find the same concept in different coding systems') and gives tactical configuration guidance (target_terminologies to limit, source_terminology to exclude). It also names concrete alternatives for pt-BR content: icd11_search/mesh_search with language 'pt' and cid10_search, providing a clear when-not-to-use branch.
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-terminologies-mcp MCP server](https://glama.ai/mcp/servers/SidneyBissoli/medical-terminologies-mcp/badges/card.svg)](https://glama.ai/mcp/servers/SidneyBissoli/medical-terminologies-mcp)

Score Badge

Copy to your README.md:

[![medical-terminologies-mcp MCP server](https://glama.ai/mcp/servers/SidneyBissoli/medical-terminologies-mcp/badges/score.svg)](https://glama.ai/mcp/servers/SidneyBissoli/medical-terminologies-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/SidneyBissoli/medical-terminologies-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server