Medical Terminologies MCP

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable behavioral context on top: it explicitly states the return model ('one entry per ATC code'), explains the difference between single-ingredient and combination mapping, and discloses the data source (NLM RxClass). No contradictions 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a one-sentence primary definition followed by a bulleted usage list and a compact behavioral note. Every sentence contributes information, and the key purpose is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single parameter, rich annotations, an output schema, and a description covering purpose, usage, return multiplicity, and data source, the tool is fully contextualized. The description also anticipates the main edge case (combination products returning multiple codes).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage: the single required parameter 'drug_name' includes a description with examples. The description reinforces this by giving 'metformin' → A10BA02 and clarifying 'brand or generic', but it adds no significantly new details beyond the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Look up the WHO ATC classification(s) for a drug by name.' It specifies a distinct verb ('look up') and resource (ATC classifications), provides a concrete example, and explains the output's multiplicity, which helps distinguish it from the pool of sibling classification tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear use cases ('Find the ATC code', 'Identify the therapeutic class hierarchy', 'Cross-reference drugs') and explains the behavior for single vs. combination products. However, it does not mention when not to use this tool or explicitly point to alternatives like atc_lookup or atc_members, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare read-only, idempotent, non-destructive. The description adds key behavior beyond annotations: accepted code lengths (1-5 chars), the mapping of code patterns to hierarchy levels, and the explicit limitation that 7-character substance codes are not exposed. This is useful contextual depth, though return format and error handling are not addressed (output schema presumably covers return).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the core purpose, then uses bullet points for use cases, and clearly separates what the tool does from what it doesn't do. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup tool with output schema, annotations, and a clear alternative reference, the description covers purpose, usage, limitations, and hierarchy semantics. It is complete enough for an agent to select and invoke this tool correctly, including knowing when to fall back to `atc_classify`.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% (the schema description already explains the parameter and its format). The description adds extra semantics by explaining the hierarchy level names (anatomical, therapeutic, pharmacological, chemical) and showing example codes for each level, which enriches understanding beyond the schema's raw pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Look up an ATC code at level 1-4') and resource (ATC code), plus the returned data ('name and hierarchy level'). It clearly distinguishes from the sibling `atc_classify` by explicitly excluding substance-level codes and directing users to that tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It offers explicit 'Use this tool to' bullets with concrete use cases (resolve, confirm, identify) and a clear exclusion: substance-level codes are not exposed, with an explicit alternative (`atc_classify`). This is strong when-to-use / 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/openWorld/idempotent, and the description adds non-obvious behavior: each member includes a substance-level source_atc_code for disambiguation, and RxNorm's catalog is US-centric. This goes beyond the structured fields and gives the agent important context for interpreting results.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the primary purpose, uses a compact bullet list for usage scenarios, and each sentence provides distinct value (examples, level semantics, source caveat). There is no fluff or repetition of annotation data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one parameter, an output schema, and clear annotations, the description covers purpose, usage scenarios, return field details, and a data-scope caveat. It fully equips an agent to decide when to call this tool and what to expect, without needing to consult sibling descriptions.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a pattern and description for atc_code. The description enhances this by explicitly explaining that higher levels return all member substances while level 5 returns a single substance, plus giving a concrete example. This adds meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb+resource ('List the drugs (substances) that belong to an ATC class') and immediately provides concrete examples (A10BA → metformin, phenformin). It clearly distinguishes itself from sibling tools like atc_lookup (which likely handles single codes) and atc_classify (classification) by focusing on enumeration of class members.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists three 'Use this tool to' scenarios and clarifies behavior at different ATC levels (levels 1-4 vs 5). However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish read-only, idempotent, non-destructive behavior. The description adds useful context about the output structure (chapter plus constituent groups) and provides a concrete example ('Chapter IX → I00-I02...'). This goes beyond the minimal annotation coverage, though it does not mention edge cases like invalid chapter numbers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a leading sentence states the core purpose, followed by a tight bullet list of use cases and a final one-line instruction. No filler or redundancy; every sentence contributes to understanding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter, read-only tool with annotations and an output schema, the description is fully complete. It explains what the tool returns, how to invoke it, and when to use it, while the output schema handles return-value details. No significant gaps remain.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%—the parameter 'num' is already well-documented in the input schema ('Chapter number (1-22). CID-10 V2008 has 22 chapters.') The description only repeats this ('Provide a chapter number (1-22)') without adding deeper meaning or usage nuances, so it does not elevate above the baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb and resource: 'Get one CID-10 chapter and its constituent groups.' It further distinguishes from siblings by emphasizing chapter-level drilling ('Drill from a chapter into its groups') versus the likely list-all-chapters behavior of cid10_chapters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit usage context via the 'Use this tool to:' list, covering key scenarios like building hierarchical browsers and finding group ranges. It does not explicitly name alternatives or when-not-to-use, but the context is clear and sufficient for a simple lookup tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds useful behavioral context: it returns exactly 22 entries and notes that CID-10 V2008 has not been updated since 2008, which signals data stability. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise, well-structured, and front-loaded with the main purpose. The bulleted use cases are scannable and every sentence adds value, including the version note and entry count. No filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (no params, output schema present), the description is fully sufficient. It covers what is returned, the use cases, and a caveat about version recency, making it complete for an agent to decide and invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so per the rubric the baseline is 4. The description explains that the tool lists all chapters, implicitly clarifying that no arguments are needed. It adds minimal but sufficient semantic context for a param-less tool.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'List the 22 chapters of CID-10 with their code ranges and Portuguese titles.' It clearly distinguishes from siblings by focusing on the chapter-level overview for CID-10, separate from cid10_chapter, cid10_lookup, and icd11_chapters.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool to' bullets provide explicit use cases: viewing top-level structure, mapping codes to chapters, and building a TOC. It lacks explicit exclusions or comparisons to alternatives, such as using cid10_chapter for chapter-specific details, but the context is clear 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds useful behavioral context beyond annotations: it accepts both dotted and undotted forms, returns the canonical display, and notes that gender/cause-of-death flags are returned 'when applicable'. This informs the agent about input normalization and output nuances.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded. The first sentence states the primary function, followed by three crisp bullet points and a final note on input formats. Every sentence contributes value; no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple lookup tool with one parameter, rich annotations (readOnly, idempotent, etc.), and an output schema, the description covers all essential aspects: purpose, use cases, input normalization, and return behavior. No critical information is missing for an agent to effectively select and invoke the tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the parameter description already explains the pattern and examples. The tool description adds an extra layer by explicitly stating that both dotted and undotted forms are accepted and that the output uses the canonical display, which goes beyond the schema's literal pattern.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool resolves a specific CID-10 code to its Portuguese name, distinguishing it from siblings like cid10_search (which searches) and cid10_chapter (which lists chapters). The verb 'look up' plus the resource and examples make the purpose unmistakable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists three concrete use cases (resolve to name, confirm existence, retrieve flags), providing clear context for when to use this exact-lookup tool. It does not explicitly name alternatives or exclusion criteria, but the use cases sufficiently imply when it is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is covered. The description adds behavioral details beyond annotations: search is diacritic-insensitive ('infeccoes' matches 'infecções'), returns categories/subcategories, and scopes to the Brazilian V2008 edition. These enrich the agent's understanding of what to expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a bit longer due to the bullet list, but each bullet adds distinct value. It is front-loaded with the primary action and remains scannable; nothing is redundant except perhaps repeating the query examples already in the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 3 params, an output schema, and comprehensive annotations, the description covers the linguistic scope, revision, diacritic behavior, and provides alternative guidance. It does not detail output/response format, but the output schema handles that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers all three parameters with descriptions and enums, so the baseline is 3. The description's examples ('infarto', 'diabetes') are also present in the schema's query description, and it doesn't add new parameter-level semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Search' with the resource 'Brazilian CID-10' and clarifies it is by Portuguese text. It distinguishes from the sibling icd11_search by explicitly directing users to that tool for international ICD-11, and the context (SUS/ANVISA) differentiates it from generic lookup tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases (billing, epidemiology, clinical documentation) and an explicit alternative: 'for the international ICD-11 ... use icd11_search.' It also states the revision (V2008) which helps decide when to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Going beyond the readonly/openWorld/idempotent annotations, the description explains key behaviors: match_score and rank are server-computed because upstreams lack comparable scores, lexical-identical title clustering in groups (and explicitly warns that absence of a group is NOT evidence of non-equivalence), and that searches are English-only. It also explains that limit is a cap not a page due to no stable cursor. This is rich behavioral disclosure.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a lead sentence, a bulleted 'Use this tool to' list, then compact paragraphs for scope/parameters, output semantics, and language caveat. Every sentence carries substantive information; there is no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's cross-terminology complexity, the description covers the search scope, parameter interactions, output fields (match_score, rank, groups), language limitations, and cross-references to sibling tools. The output schema exists, so the description appropriately focuses on behavior and usage context rather than repeating return structures.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Although the schema describes all four parameters (100% coverage), the description adds crucial interaction semantics: how source_terminology and target_terminologies combine via subtraction, and the non-paging nature of limit. This information is not in the schema and directly informs correct usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific, action-oriented summary: 'Ranked unified search for equivalent terms across multiple medical terminologies.' It clearly distinguishes this from sibling per-terminology search tools (e.g., icd11_search, mesh_search) and mapping tools by emphasizing cross-terminology equivalence and ranking.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly lists three use cases (find same concept, compare representations, support mapping/integration). It gives concrete guidance on when to set source_terminology (already have a code) vs target_terminologies (limit search), and even provides an alternative path for pt-BR users (icd11_search/mesh_search with language 'pt', cid10_search). This is clear when-to-use and 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds minimal behavioral context beyond that, such as noting the 28 chapters and 'top-level categories' scope, but does not describe return format or error behavior. With strong annotation coverage, the additional value is modest.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a clear opening sentence, bullet-point use cases, and a brief fact about ICD-11's scope. Every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list operation with a single optional parameter and existing annotations, the description covers the primary purpose, usage scenarios, and scope. It does not need to explain return values given the output schema exists, though it could have mentioned that no parameters are required.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single language parameter, including a detailed description about official translations. The tool description itself does not mention the parameter, so it relies entirely on the schema. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List all ICD-11 chapters (top-level categories),' which is a specific verb+resource statement. It clearly distinguishes from sibling tools like icd11_lookup or icd11_search by focusing on the top-level chapter listing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Bullet points provide concrete use cases ('Get an overview...', 'Find which chapter covers...', 'Navigate to specific disease categories'). While it does not explicitly name alternatives or when-not-to-use cases, the intended scenarios are evident and effectively context-rich.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only, idempotent, and non-destructive. The description does not add significant behavioral context beyond restating that 'parents' returns ancestors and 'children' returns subcategories, which is already present in the schema. There is no mention of error behavior, code validity, or output structure, but given the strong annotation coverage, this is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is brief, front-loaded with the core purpose, and uses a clear bulleted list for usage. It contains no unnecessary words or repetition beyond the already-mentioned parameter semantics, which serves as a reinforcement. The structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (2 params, read-only, with output schema), and the description covers the core use cases and direction semantics. It doesn't explain the output structure, but that's covered by the output schema. It could arguably mention that it returns all ancestors/descendants, but the phrase 'ancestor categories' and 'subcategories' implies this. Overall, it's complete for the tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with both parameters described. The description essentially repeats the schema's parameter semantics ('Direction 'parents' returns ancestor categories, 'children' returns subcategories') without adding new meaning. Per the rubric, the baseline is 3 when schema coverage is high.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function with a specific verb ('Navigate') and resource ('ICD-11 hierarchy'), and explicitly mentions finding parent or child entities. This distinguishes it from sibling tools like icd11_search or icd11_lookup, which focus on lookup/search rather than hierarchy traversal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases ('Use this tool to: find broader categories... find specific subtypes... understand the classification structure'), giving clear context for when to use the tool. However, it does not name alternative tools or state when not to use it, 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.

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 a useful detail about official translations and no machine translation, but this is also present in the schema. It does not disclose precedence if both code and URI are provided, so transparency is adequate but not exhaustive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a front-loaded purpose sentence, a scannable bullet list of use cases, and a brief input guidance section. Every sentence contributes value without unnecessary repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With robust annotations, a fully described schema, and an output schema present, the description is largely complete. It gives clear usage context and input requirements. The only minor gap is lack of explicit guidance on what happens if both code and URI are supplied, which is an edge case.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for all three parameters, with clear descriptions and an enum for language. The description reinforces the code/URI options and gives a language example, but adds little meaning beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Get detailed information about a specific ICD-11 entity by code or URI.' It lists specific use cases (definition, coding notes, exclusions, title, synonyms), which distinguishes 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool to' bullet list provides explicit, actionable context for when to use this lookup tool. It also clarifies input options (code or URI) and language settings. However, it does not explicitly name sibling alternatives or state when not to use this tool, 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.

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. The description adds valuable context beyond these, explaining what postcoordination means (adding severity, laterality, anatomy) and the nature of the information provided (axes, required vs optional, extension possibilities), which helps the agent understand the semantic scope.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise and well-structured: a clear opening sentence, three bullet points for specific use cases, and a brief explanatory sentence about postcoordination. It is front-loaded and every sentence contributes useful information without redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple one-parameter schema, full schema coverage, and an output schema (not shown), the description adequately covers the tool's context. It explains the tool's purpose and key use cases without needing to detail return values, which the output schema handles. The annotations cover safety characteristics, making this description complete for its complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, with the parameter 'code' fully described as 'ICD-11 code to get postcoordination info for'. The description merely restates this by saying 'for an ICD-11 code', adding no additional meaning. Since the schema already provides complete parameter documentation, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get postcoordination information for an ICD-11 code' with a specific resource and verb. It further distinguishes from siblings by listing unique functions like checking required vs optional postcoordination and understanding code extension possibilities, which no other ICD-11 tool (lookup, search, hierarchy) covers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool to:' section provides explicit scenarios for when to invoke this tool, such as finding axes for composite codes. It does not explicitly name alternative tools to exclude, but the clear context of postcoordination needs effectively implies when this tool is appropriate versus lookup/search tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the readOnly/idempotent annotations, the description discloses that results include codes, titles, and relevance scores, and guarantees language translations are official and never machine-translated. This adds useful behavioral detail 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured: a one-sentence purpose, a short 'Use this tool to' list, a language note, and a return-value sentence. It is concise, front-loaded, and every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a free-text search tool with a documented output schema and clear annotations, the description covers the core purpose, key use cases, language behavior, and return format. It also fits well among sibling tools by distinguishing its ICD-11 search role, making it complete for agent selection.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already documents all 3 parameters with descriptions and default values (100% coverage). The description's notes on language (e.g., 'pt' for official Portuguese) reinforce the schema but do not add significant new semantic meaning; the schema already explains the translation behavior.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Search for medical conditions, diseases, and health problems in ICD-11' and provides specific use cases (find codes, search by keyword, multilingual lookup). It clearly distinguishes this from sibling tools like icd11_lookup or cid10_search by specifying ICD-11 free-text search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool to' bullet list gives clear context for when to use the search functionality (finding codes, keyword search, multilingual lookup). It does not explicitly mention when not to use it or name alternative tools, but the context is sufficient for typical selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the behavioral constraint that the tool only works for questions with defined answer sets, which is valuable context beyond annotations. It does not describe return format, but an output schema exists to fill that gap.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences plus a short bullet list), front-loads the core purpose, and every sentence adds value. There is no fluff or repetition of structured data.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one parameter, output schema present, strong annotations), the description is complete. It explains what it does, when to use it, and its applicability constraint. No additional behavioral details are necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter loinc_num is fully described in the schema with a pattern and example; schema coverage is 100%. The description adds no additional parameter-specific meaning, so the baseline of 3 is appropriate because the schema carries the full burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Get the list of valid answers') and the resource ('LOINC questionnaire item'). It distinguishes this tool from siblings like loinc_search and loinc_details by focusing specifically on answer lists, and the scope is reinforced by the applicability constraint.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases ('Use this tool to: ...') and an exclusion ('Only applicable to LOINC codes that represent questions with defined answer sets'). It does not name alternative tools, but the context is clear enough for an agent to decide when to invoke it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 the list of returned fields but does not disclose behaviors like error handling for invalid codes, possible response size, or any rate limits. Since annotations carry the main safety burden, a 3 is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-sentence summary, a bulleted list of use cases, and a format guidance sentence. Every element is necessary and useful, with no filler. The format example with a real code is concise and actionable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only lookup with a single parameter and an output schema present, the description fully covers what the tool does and what it returns (the field list). It does not need to explain return values since the output schema exists. The description is complete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already fully describes the loinc_num parameter with type, pattern, and an example. The description reinforces the format ('XXXXX-X') and gives a concrete example ('2339-0' for Glucose), which adds minor value but does not significantly exceed the schema. With 100% schema coverage, the baseline 3 is suitable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb ('Get') and resource ('detailed information about a specific LOINC code'), then enumerates the exact details returned (name, component, property, timing, system, scale, method). This clearly distinguishes it from sibling tools like loinc_search (which finds codes) and loinc_answers/panels (which retrieve related data).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides a clear 'Use this tool to' section listing three concrete use cases, and gives a format example with a real code. It does not explicitly state when not to use this tool or mention alternatives (e.g., loinc_search), but the context is sufficient for an agent to select it for a single-code lookup.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive, so the safety profile is known. The description adds that the return is a list of LOINC codes, but doesn't disclose edge cases like non-panel inputs or open-world behavior, so it's adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a short paragraph with a bullet list and a concluding return statement. It is front-loaded and every sentence contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the single parameter, existing output schema, and rich annotations, the description covers the needed context. It clearly states the return format and use cases, though it could clarify recursive expansion or hierarchical structure.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema provides 100% coverage of loinc_num with pattern and example. The description adds that the input should be a panel or form code and gives examples (CBC, metabolic panel), meaningfully extending the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Get the structure of a LOINC panel or form' with a specific verb and resource. It further lists concrete use cases (CBC, metabolic panel) and distinguishes from sibling tools like loinc_details and loinc_search by focusing on panel composition.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit 'Use this tool to' scenarios, giving clear context for when to invoke it. It does not mention when not to use it or alternative tools, so it doesn't reach the highest bar.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare the tool as read-only, idempotent, and non-destructive, so the safety profile is well-covered. The description adds behavioral context by stating that it returns matching LOINC codes with names, components, and properties, which goes beyond annotation info and sets expectations for the response content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is structured with a clear opening sentence followed by bullet points, making it scannable. It is slightly redundant (the bullets echo the opening sentence) but still concise and front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and detailed annotations, the description does not need to explain return values exhaustively. It covers the tool's scope, use cases, and basic output (codes with names/components/properties), making it sufficiently complete for a simple search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%: both 'query' and 'max_results' have explanatory descriptions. The tool description does not add extra meaning beyond the schema, so it stays at the baseline of 3 for high-coverage schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Search for laboratory tests, clinical observations, and measurements in LOINC', clearly specifying the action (search) and resource (LOINC). It distinguishes itself from sibling tools like loinc_details or loinc_panels by focusing on finding codes rather than retrieving details or panel structures.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes an explicit 'Use this tool to:' bullet list enumerating concrete use cases (lab tests, clinical measurements, diagnostic observations). It provides clear context for when to use it but does not mention exclusions or alternative tools for related lookups, such as loinc_details for a specific code.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description goes well beyond the readOnly/openWorld/idempotent annotations by adding concrete behavioral details: returns primary 1:1 category plus alternatives, includes codes/titles/chapters/URIs, accepts dotted and undotted forms, and explicitly states the 'no mapping' behavior for missing codes. This is rich, honest context with 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is appropriately sized for the tool's complexity, front-loaded with the core purpose in the first sentence. Each subsequent sentence adds critical information (alternatives, contents, coverage, formats, missing-code behavior) without fluff. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity, the presence of an output schema, and thorough annotations, the description is complete. It covers mapping methodology, coverage limits, accepted input formats, and fallback behavior, enabling correct tool selection and invocation without needing to consult external docs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, but the description adds meaningful parameter semantics: it provides concrete examples ('E11', 'I21', 'A07.8'), explicitly states that both dotted and undotted forms are accepted, and explains what the code represents in the context of WHO classification. This is valuable guidance beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Authoritative ICD-10 → ICD-11 mapping using WHO transition tables (release 2025-01, bundled with the server).' It clearly distinguishes from sibling tools by emphasizing authoritative mapping rather than text-search candidates, and from other mapping tools (e.g., map_loinc_to_snomed).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit use cases are given: 'Use this for clinical coding, billing migration, retrospective analysis, and any workflow that needs authoritative mapping rather than text-search candidates.' It also clarifies coverage (excludes chapters/blocks) and when 'no mapping' is returned instead of a fuzzy fallback, providing clear when-to-use and 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, but the description adds significant behavioral context: that the tool returns guidance rather than actual mappings, and that real mappings require licensing/authenticated downloads. This goes beyond what annotations convey and helps the agent set user expectations correctly. No contradictions 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise yet comprehensive. Each paragraph serves a purpose: stating the action, explaining licensing restrictions, offering alternatives, and giving usage examples. It is front-loaded with the core purpose and limitation, and every sentence earns its place without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (licensing constraints, non-mapping nature, alternatives), the description covers all necessary context: what it does, what it doesn't do, why, and how to use it. An output schema exists, so return-value details are not required. The description is fully self-contained and enables correct selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already defines loinc_code with a pattern and example, so the baseline is 3. The description adds an extra example ('718-7' Hemoglobin) and reinforces the expected format ('Provide a LOINC code like...'), providing a small but useful increment. It does not, however, explain the semantics of the returned guidance or the code format beyond examples, which the schema already covers.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool 'looks up a LOINC code in NLM Clinical Tables and returns guidance on where to obtain a LOINC → SNOMED CT mapping.' It explicitly clarifies that it does not perform the mapping, distinguishing it from sibling tools like map_icd10_to_icd11. The verb-resource-outcome structure is specific and unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit guidance on when to use this tool versus 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 clearly states the tool's limitation ('It does not perform the mapping') and the licensing context, giving the agent enough to avoid misuse.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations (read-only, idempotent, open world), the description adds behavioral context about language handling: NLM official translations where they exist and no machine translation. This clarifies output expectations without contradicting the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a one-sentence summary followed by a short bullet list of use cases and a final usage note. Every sentence earns its place, and the key information is front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the presence of an output schema and strong annotations, the description sufficiently covers the tool's purpose, usage scenarios, and important language behavior. It is complete for a simple lookup tool and does not need to explain return values.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema already documents parameters with examples and language behavior. The description mostly paraphrases the schema (e.g., D015242 example, 'official translations'), adding no significant new meaning beyond what structured fields provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Get detailed information about a MeSH descriptor by ID.' It further distinguishes itself from sibling tools by listing concrete content delivered (scope note, tree numbers, related concepts/synonyms) and by the ID-based access pattern, unlike mesh_search or mesh_tree.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage context via 'Use this tool to:' bullets and gives an example ID and language. It does not explicitly state when not to use it or name alternatives, but the context is strong enough to guide selection among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds helpful context by explaining what qualifiers are ('Qualifiers refine descriptors') and how they relate to descriptors (e.g., 'Diabetes Mellitus/drug therapy'), 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact, well-structured with a lead sentence and bullet points, and every sentence adds value. It avoids redundancy and gets straight to the point without unnecessary detail.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, full schema coverage, and presence of an output schema, the description provides sufficient context for an agent to select and invoke it correctly. It could mention input validation or edge cases, but these are implied by the schema's pattern and are not critical.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already provides full coverage for the single parameter (mesh_id), including a pattern and example. The description does not add significant new meaning beyond what the schema already contains, so the baseline score of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get allowed qualifiers (subheadings) for a MeSH descriptor.' This clearly distinguishes it from sibling tools like mesh_descriptor, mesh_search, and mesh_tree, which have different purposes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides explicit use cases with bullet points ('Find which qualifiers can be combined', 'Build precise MeSH search queries', 'Understand aspects that can be specified'). It gives clear context for when to use the tool, though it doesn't mention alternatives or when not to use it.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, so the description appropriately adds extra context: the language parameter uses official translations and never machine-translates, and the return format includes MeSH IDs and labels. This goes beyond the annotations, though the translation behavior is also present in the parameter schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a short intro, a bulleted list of use cases, and a final note on language behavior and return format. It is concise and front-loaded, though the bullet list repeats the same core idea of 'search for MeSH terms,' which is slightly redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has four parameters and an output schema, the description covers the main purpose, key language behavior, and output format. It does not explain the match types or max_results, but those are fully documented in the schema. It is complete enough for an agent to select and invoke the tool correctly, though sibling differentiation is not explicit.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description adds little beyond the schema: it repeats the language behavior and gives an example query, but the schema already thoroughly describes match, query, language, and max_results meaning and defaults. No significant additional parameter semantics are provided.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb and resource: 'Search for MeSH (Medical Subject Headings) descriptors.' It also lists concrete use cases, which differentiates it from a lookup tool like mesh_descriptor, though it does not explicitly name alternatives or contrast with siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear usage context via bullet points: finding MeSH terms for indexing, PubMed searches, and controlled vocabulary. This tells the agent when to use the tool, but it does not provide exclusions or explicitly compare to alternative sibling tools (e.g., mesh_descriptor).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful context about the interpretation of tree numbers (e.g., 'C14.280.647 for Myocardial Infarction'), which goes beyond the structured metadata. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is suitably compact and front-loaded with the core verb and object. The bullet list is helpful but could be slightly condensed; however, each line earns its place by clarifying distinct use cases.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With a single well-documented parameter and an output schema, the description covers all necessary context: purpose, usage scenarios, and an illustrative example of a tree number. It does not need to explain return values because the output schema provides that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter, mesh_id, is fully described in the schema with a pattern and example. The description adds no additional parameter-level guidance, so it relies on the schema. Baseline 3 applies because schema coverage is 100%.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb phrase 'Get the tree hierarchy location(s) for a MeSH descriptor,' which specifies exactly what the tool does and identifies the resource (MeSH descriptors). It distinguishes itself from siblings like mesh_descriptor or mesh_search by focusing specifically on hierarchy locations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The bulleted list provides clear context on when to use the tool: to see where a term fits, understand broader/narrower relationships, and find related terms in the same branch. It does not name alternatives or exclusions, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a note about returning class IDs, names, and sources, which is useful but somewhat redundant given the output schema. It does not discuss error behavior, data completeness, or permission requirements, but with strong annotations, a moderate score is appropriate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured, with a clear opening sentence and three bullet points that add illustrative examples without redundancy. It is front-loaded and each sentence contributes meaningful information, making it easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter, an output schema, and strong annotations, the description covers the core behavior and return details adequately. It does not mention edge cases like invalid RxCUIs or missing classifications, but these are not critical given the tool's limited scope and the presence of an output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The only parameter rxcui is fully documented in the schema with a pattern and description ('RxCUI of the drug'), giving 100% schema coverage. The description does not add additional semantic detail beyond this, so the baseline score of 3 is suitable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Get therapeutic and pharmacologic classes for a drug.' It distinguishes from sibling tools like rxnorm_search, rxnorm_concept, and atc_classify by focusing on classes, with concrete examples (Beta-blockers, NSAIDs). The purpose is unambiguous and differentiates well.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool to' section clearly lists when to use it: find drug class, identify therapeutic categories, and look up mechanism of action classifications. However, it does not explicitly mention when NOT to use it or name alternatives such as atc_classify or rxnorm_concept, so it lacks explicit exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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 behavioral context by specifying what data is returned (full name, synonyms, status, related concepts), which helps agents anticipate the response. It doesn't mention errors or limitations, but for a read-only lookup this is sufficient.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a single leading sentence followed by a bulleted list of uses and a closing example. Every sentence earns its place, and the information is front-loaded with the main verb phrase.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter set, strong annotations, and the existence of an output schema, the description adequately covers the essential usage context. It could clarify that include_related is optional and controls related-concept retrieval, but the schema handles that detail. Overall, it is complete enough 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters already have clear descriptions. The description adds an example value ('161') for rxcui and reiterates the purpose, but it doesn't add substantial new semantic detail beyond what the schema 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.

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 specific RxNorm concept by RxCUI,' a specific verb+resource+scope statement. The bullet list clarifies the exact types of information (full name, synonyms, status, related concepts), clearly distinguishing it from sibling search/list tools like rxnorm_search and rxnorm_ingredients.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'Use this tool to' section lists three concrete use cases, providing clear context for when the tool is appropriate. However, it does not explicitly name alternative tools or state when not to use it, so it lacks explicit exclusions but still gives clear context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is well-covered. The description adds useful behavioral context by stating that it returns ingredient RxCUIs and names and can identify generic components of brand drugs. No contradictions 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and well-structured: a leading sentence, a bulleted list of use cases, and a concise note about the return format. Every sentence contributes without redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only lookup with a full schema and an output schema present, the description adequately covers purpose, use cases, and return shape. It doesn't address edge cases or error handling, but the rich annotations and output schema compensate for these gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with a clear description and pattern for the rxcui parameter. The tool description only restates 'by RxCUI' without adding extra semantic meaning, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('Get active ingredients for a drug by RxCUI') and lists concrete use cases such as finding ingredients, checking single vs. multi-ingredient products, and identifying generic components. This clearly differentiates it from sibling 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides explicit 'Use this tool to' guidance with three scenarios, making the intended usage clear. It does not explicitly mention alternatives or exclusions, but the context is sufficient for most agents to decide when this tool is appropriate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and idempotentHint=true, so the agent knows this is safe. The description goes beyond by stating the bidirectional mapping behavior ('Provide either an RxCUI...or an NDC...') and that the tool returns 'all NDC codes' for an RxCUI. This adds clarity about the one-parameter-at-a-time behavior, though it doesn't mention edge cases.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single short sentence followed by three bullet points and one closing instruction. Every line contributes directly to understanding the tool's purpose and usage.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With only two optional parameters, 100% schema coverage, an output schema, and read-only annotations, the description covers the key information needed. It explains the two directions of lookup, but could be slightly more explicit about the expected behavior when both or neither parameter is provided.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters at 100% coverage. The description reinforces the direction of lookup, but adds minimal new detail beyond the schema, which already labels ndc as 'alternative to rxcui'.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Map' with two resources (RxNorm concepts and NDC), and lists three concrete use cases. This clearly distinguishes it from sibling tools like rxnorm_search or rxnorm_concept, which handle single-system lookups.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states 'Use this tool to' followed by three bullet-point use cases, and the final sentence instructs to provide 'either an RxCUI...or an NDC', clarifying the entry point. It does not name alternative tools or explicit exclusions, but the context is sufficient.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds useful behavioral context by specifying that it returns matching drugs with RxCUI, names, and term types. It does not detail search matching semantics (exact vs partial), but the annotation lowers the bar.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a lead sentence, a bulleted 'Use this tool to' list, and a return statement. It is appropriately sized, though the first line and first bullet are slightly redundant. Overall, it is efficient and easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple tool (2 parameters, full schema coverage, output schema present, and annotations), the description adequately covers purpose, usage, and return behavior. It could mention alternatives or note that NDC-specific lookups belong elsewhere, but is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides full descriptions for both parameters (query and max_results), covering 100%. The description repeats 'brand or generic' but adds no new semantic information beyond what the schema already contains, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Search for drugs in RxNorm' and specifies the resource as 'drug concepts' with return values (RxCUI identifiers, names, term types). It distinguishes itself from sibling tools like rxnorm_ndc and rxnorm_ingredients by focusing on concept-level search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides three explicit use cases: find drug concepts by brand/generic name, look up medications for prescribing, and search for drug formulations. However, it lacks exclusions or alternative tool recommendations (e.g., when to use rxnorm_ndc instead), 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable context beyond annotations: it clarifies that for most terminologies the output is guidance pointing to external changelogs, not actual diff data, and that only ICD-10 vs ICD-11 yields a real cross-revision summary. It also explains the meaning of omitted from_version/to_version parameters (bundled vs publisher's latest), giving the agent behavioral expectations. However, it doesn't detail the exact return format or output shape beyond the summary fields mentioned, which the output schema presumably covers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear intro, a bolded special case, and a bulleted input list, making it easy to scan. It's somewhat long, but every sentence serves a purpose: explaining guidance-only vs real diff, naming the exception, and detailing parameter behavior. The final sentence reinforces the tool's scope (metadata layer, not diff engine). It earns a 4 for good organization and information density, though a slight trim could make it even more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has a moderate complexity (3 parameters, 8 enums, output schema present), and the description covers the key use cases and limitations well. It explains the difference between guidance-only and real diff for ICD-10 vs ICD-11, and gives specific instructions for that case. The output schema exists, so return values need not be detailed. The description could be more complete on the exact structure of the cross-revision summary, but the summary fields (total mapped, 1:1 vs split, average alternatives) are mentioned. Overall, it's nearly complete for the given complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% for all three parameters, so the schema already documents each field. The description adds semantic value by clarifying the behavioral implications of omission: from_version omitted reports against the currently-bundled version, to_version omitted reports against the publisher's latest known release. It also gives specific usage guidance for terminology='icd10' with no to_version to trigger the cross-revision summary, which is more than the enum alone provides. Baseline 3 for full schema coverage, but the added contextual semantics justify a 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reports diff data availability between two versions of a terminology, using the specific verb 'report' and resource 'terminology'. It differentiates from siblings by highlighting the special ICD-10 vs ICD-11 cross-revision summary, and it positions itself as a metadata/guidance layer rather than a diff engine, distinguishing it from 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.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives explicit when-to-use guidance: for most terminologies it's guidance only, pointing to the publisher's changelog; for ICD-10 vs ICD-11 it surfaces real transition table data. It also names the alternative (publisher's official changelog) and specifies when to use the tool with the icd10 terminology and no to_version to get the cross-revision summary. Sibling tools like terminology_versions provide complementary context, but the description makes the tool's niche clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already indicate read-only and non-destructive behavior. The description adds valuable nuance: the ICD-10→ICD-11 version reads live from the bundled dataset while everything else is static metadata, and specific pinning (CID-10 frozen V2008, transition tables 2025-01) is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured and front-loaded with the core purpose, followed by a concise bullet list of use cases and a final parameter/behavior note. 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.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one optional parameter and an output schema (which covers return fields), the description fully covers purpose, usage contexts, filter behavior, and a subtle data-source nuance. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already documents the `terminology` parameter and its enum. The description enriches this by explicitly naming the terminology families (ICD-11, SNOMED, etc.) and clarifying that omission returns all 8 entries, which matches the schema but adds user-oriented context.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a specific verb and resource: 'List the current version, release date, publisher, source URL, and update cadence of every terminology.' This precisely defines the tool's function and clearly distinguishes it from sibling lookup/classification tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly lists use cases for pipeline maintainers (confirming versions before batch runs, verifying frozen CID-10 and transition tables, citing data versions). While it doesn't name alternative tools or provide 'when-not' instructions, the context is clear and actionable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds significant behavior beyond the readOnly/idempotent annotations: it explains null semantics for 'active' across terminologies, 'replaced_by' only for ICD-10, precise error handling ('valid: false + error: null' vs 'error: set'), parallel execution and latency, and a SNOMED feature flag. 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.

Is the description appropriately sized, front-loaded, and free of redundancy?

Although fairly long, the description is tightly organized with a bolded output list, error-semantics explanation, and terminology constraints. Every sentence carries operational value—no fluff. The bullet structure makes it easy to scan, and the density of useful information justifies the length.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex multi-terminology batch tool with an output schema, the description covers critical edge cases (null fields, error states, version provenance) and operational constraints (50-code cap, latency, feature flags). Together with the output schema, the agent has everything it needs to invoke the tool correctly and interpret results.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the input schema already documents 'codes', 'code', and 'terminology' clearly. The description reinforces the terminology requirement and the hard cap, but adds little beyond what the schema provides. It does add output interpretation context, but that doesn't directly enrich parameter semantics, so a baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Validate a mixed batch of medical codes against their source terminologies.' It clearly enumerates the tool's unique deliverables (flagging obsolete codes, surfacing ICD-10→ICD-11 replacements, grading activity status), which distinguishes it from sibling lookup/search/classification tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides clear usage context: 'Useful for retrospective analysis of legacy databases.' It also specifies when auto-detection is not supported, the required terminology parameter, and the 50-code cap. However, it does not explicitly name alternative tools or state when to prefer them, so it falls just 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.