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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds useful behavioral detail: returns one entry per ATC code, single-ingradient vs combination mapping, and the NLM RxClass source. No contradiction with annotations is present.

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 with the core action and example, uses concise bullets for use cases, then adds relevant return and source notes. Every sentence contributes 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 one-parameter, read-only tool with an output schema, the description covers purpose, usage contexts, return cardinality, and provenance. It does not address sibling-tool routing exclusions, but the explicit use cases make it sufficiently complete for an agent.

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

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

Input schema has 100% coverage for drug_name, including brand/generic example. The description repeats the example but does not add new parameter-level semantics, 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?

States a specific action: 'Look up the WHO ATC classification(s) for a drug by name.' It includes a concrete example ('metformin' → A10BA02) and clarifies output cardiniality. It does not explicitly contrast with sibling tools like atc_lookup or atc_members, but the 'by name' scoping and return behavior make it largely distinguishable.

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?

A bulleted list of use cases (find code, identify hierarchy, cross-reference international codes) gives clear when-to-use context. There is no explicit exclusion or naming of alternatives, such as atc_lookup or atc_members, 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 indicate read-only, idempotent, non-destructive behavior. The description adds useful behavioral boundaries: accepted code lengths, the levels covered, and the fact that substance-level codes are not returned by this endpoint. This is meaningful context beyond the annotations, though not exhaustive about not-found behavior.

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

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

The description is well-structured with a clear opening line, a bulleted use list, and a compact code-length explanation. It is slightly redundant because the schema already covers the same 7-character exclusion, but overall every sentence contributes useful guidance.

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 an output schema and strong annotations, the description is complete. It covers accepted input formats, level semantics, alternatives for unsupported codes, and the tool's scope. No critical calling information 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?

Schema description coverage is 100%, so the baseline is 3. The description adds concrete examples ('A', 'A10', 'A10B', 'A10BA') and maps them to level names, plus an example of resolving A10BA to 'Biguanides'. This reinforces schema semantics but is somewhat redundant with the parameter description.

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: 'Look up an ATC code at level 1-4 to get its name and hierarchy level.' It clearly distinguishes itself from siblings by explicitly stating that substance-level codes (7 characters) are not exposed and that atc_classify should be used instead.

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 when-to-use scenarios: resolving a code to a class name, confirming code existence, and identifying the hierarchy level. It also gives a clear exclusion and alternative: 7-character substance codes should go to atc_classify.

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 mark this as read-only, idempotent, and non-destructive. The description adds useful behavioral detail beyond those annotations: each member includes a 7-char substance-level code via source_atc_code, this helps disambiguate level 1-4 queries, and RxNorm's catalog is US-centric while ATC names/codes are international. This gives agents important open-world and output-format context.

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 efficient and well organized: a one-sentence definition, a focused bulleted list of use cases, then a concise note on the returned source_atc_code and US-centric limitations. Each sentence carries information that helps an agent select or invoke the tool correctly, with 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?

For a single-parameter, read-only tool with a full input schema and output schema, the description is complete: it covers what the tool does, when to use it, what the results include, and a key caveat about the curating catalog. An agent has enough to invoke it correctly without digging elsewhere.

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%, and the schema already explains that atc_code can be any level, with level 5 returning a single substance and levels 1-4 returning all members. The tool description mentions 'ATC class' and gives an example code but does not add meaningful parameter meaning beyond what the schema already provides. 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?

Description opens with a clear verb and resource: 'List the drugs (substances) that belong to an ATC class.' It differentiates itself from siblings by focusing on enumerating members of an ATC class, with concrete examples like 'A10BA' → metformin, phenformin. This makes the tool's role distinct from atc_lookup or atc_classify.

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 give clear contexts: enumerating class members, building drug lists by mechanism, and exploring ATC subtrees. However, it does not explicitly say when to prefer an alternative sibling tool or mention when not to use it, so it lacks the explicit exclusion guidance needed for 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, so the safety profile is covered. The description adds useful scope details (returns one chapter and its groups), but does not discuss error behavior, response size, or coverage caveats.

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 main action appears in the first sentence, followed by helpful bullet use cases and a short parameter instruction. Minor redundancy with the schema, but no wasted content.

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 one-parameter read tool with a rich output schema and strong annotations, the description is essentially complete. It could more explicitly distinguish itself from cid10_chapters, but 'one chapter' plus the use cases is sufficient.

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 num fully described by type, min, max, and meaning. The description only repeats 'chapter number (1-22),' adding no semantic value 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 uses a specific verb-resource pair: 'Get one CID-10 chapter and its constituent groups,' with a concrete example. It clearly differentiates from sibling cid10_chapters by emphasizing 'one' chapter rather than a collection.

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 listed: drilling from chapter to groups, building hierarchical browsers, and finding which group contains a code range. It does not mention alternatives/exclusions, but the context is clear enough for 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 convey read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: exactly 22 entries are returned and CID-10 V2008 has not been updated since 2008, which gives an agent stability expectations it could not infer from the schema. 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 core purpose is front-loaded in the first sentence, followed by a tight bullet list of use cases and a single version/status note. Every sentence contributes either scope, usage context, or stability information with no 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 zero-parameter, read-only listing tool with an output schema, the description fully covers purpose, expected result count, typical use cases, and data currency. Nothing important for selection or invocation 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 input schema has zero parameters, so there is no parameter semantics burden on the description. The baseline for 0-param tools is 4, and the description does not need to add parameter-level detail.

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 is unambiguous about scope, but it does not explicitly contrast itself with the sibling cid10_chapter, so differentiation depends on inference.

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?

A dedicated 'Use this tool to' section names concrete contexts: top-level structure, code-to-chapter mapping via ranges, and building a table of contents. It does not explicitly say when not to use the tool or name alternative tools, 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 readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral detail beyond annotations: accepts dotted and undotted forms, returns the canonical display, and may include gender/cause-of-death flags. 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 compact and well-structured: an opening sentence states the core function, followed by bullet use cases and a final formatting note. Every sentence adds value with no 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 lookup tool with a full input schema, truthful annotations, and an output schema, the description covers what an agent needs: purpose, input format variants, and additional returned flags. 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?

Schema description coverage is 100%, so the schema already fully documents the 'code' parameter. The description reinforces the dotted/undotted acceptance and canonical output but does not add substantial new parameter semantics 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 ('Look up'), a clear resource (a CID-10 code), and a concrete outcome (return its Portuguese name and restriction flags). It also distinguishes this tool from siblings like cid10_search by focusing on exact code resolution rather than 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 explicitly lists when to use the tool: resolving codes, confirming existence, and retrieving restriction flags. It does not mention alternatives or exclusions, but the use-case list is clear enough for an agent to select this over search/chapter 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds meaningful behavioral detail beyond them: matches come from categories/subcategories, search is diacritic-insensitive, and it searches the Brazilian Portuguese CID-10 V2008. No contradiction exists.

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, followed by bulleted use cases, behavior notes, and sibling routing. It is slightly repetitive with the schema's query examples, but overall every section earns its place and 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?

Given the output schema exists and annotations cover the safety profile, the description is complete enough: it states the language, version, match granularity, diacritic behavior, and the key alternative tool. An agent can decide when to invoke cid10_search and what to expect from it.

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

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

Schema description coverage is 100%, so the schema already documents query, level, and max_results. The description adds helpful context like diacritic-insensitivity and Portuguese examples, but it does not substantially extend the parameter-level meaning beyond what the schema provides. 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 pair: 'Search the Brazilian CID-10 ... by Portuguese text.' It also names concrete use cases and explicitly contrasts with icd11_search, making it easy for an agent to distinguish this tool from the international ICD-11 search sibling.

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 clearly states when to use the tool: Brazilian SUS/ANVISA contexts, Portuguese translations, and billing/epidemiology/documentation. It also gives an explicit alternative: 'for the international ICD-11 ... use icd11_search.' This gives the agent actionable routing 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, openWorldHint, idempotentHint, and destructiveHint false. The description adds substantial behavioral context beyond that: match_score and rank are server-computed because upstreams lack comparable scores, limit is explicitly a cap not a page due to no stable cursor across five upstreams, groups indicate lexical-identical titles with the caveat that absence of group is NOT non-equivalence, and upstream search is English-only. 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 well-structured with size-leaded bullets and each major section serves a purpose. It loses a point because some schema facts are repeated (default limit 5, max 10, source subtracted from targets), creating mild redundancy. Still, it is far from verbose and the code-formatted parameter names improve scannability.

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 that an output schema exists and annotations cover safety and idempotency, the description is thorough: it explains all parameter interactions, the English-only nature of upstream search, the meaning of match_score and rank, the grouping semantics, and the absense of a stable cursor. No critical information for invoking the tool correctly 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?

Schema coverage is 100%, so baseline is 3. The description adds a meaningful caveat for `limit`—'This is a cap, not a page'—and explains the source/target subtraction relationship, though the schema itself already states the subtraction behavior. It does not add much beyond schema for `term` or `target_terminologies`, but the added paging guidance is valuable for correct invocation.

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: 'Ranked unified search for equivalent terms across multiple medical terminologies.' It then states the exact terminologies searched (ICD-11, SNOMED CT, LOINC, RxNorm, MeSH) and enumerates three concrete use cases. This clearly differentiates it from the single-terminology search siblings like icd11_search or loinc_search.

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

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

The description gives clear when-to-use guidance ('Find the same concept in different coding systems', 'Compare how terminologies represent a concept', 'Support terminology mapping and data integration') and an explicit when-not-to-use for official pt-BR content, routing to icd11_search, mesh_search, and cid10_search. However, it does not explicitly position itself against the dedicated mapping siblings (map_icd10_to_icd11, map_loinc_to_snomed), which an agent might also consider for mapping tasks.

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 operation as read-only, idempotent, and non-destructive, so the description does not need to repeat that. It adds minor context by noting there are 28 chapters and that they are top-level categories, but it does not meaningfully expand 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, front-loaded with the core action, and uses a short bullet list for usage context. Every sentence contributes value, and the final note about 28 chapters adds useful scope without unnecessary elaboration.

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 listing tool with one optional parameter, full schema coverage, rich annotations, and an output schema, the description provides sufficient context. It covers what the tool returns conceptually, why to use it, and enough structural detail for an agent to invoke it correctly.

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

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

Schema coverage for the single optional language parameter is 100%, so the schema already fully explains the parameter. The description does not add extra semantic detail about the language behavior beyond what the schema provides, making the baseline 3 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 begins with a specific verb and resource: 'List all ICD-11 chapters (top-level categories).' It clearly states what the tool does and distinguishes it from search, hierarchy, and lookup siblings by describing the chapter-level overview purpose.

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 clear contexts: overview of structure, finding a chapter by body system, and navigating to disease categories. It does not explicitly mention when not to use it or name alternative tools, so it stops short of a 5.

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

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 useful semantic context by explaining that 'parents' returns ancestors and 'children' returns subcategories. However, it does not disclose details like whether all ancestor levels are returned, ordering, or pagination, though with the output schema present this is less critical.

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 an intro, a bullet list, and a clarifying sentence. Some redundancy exists between the opening line and the bullets, and the closing sentence repeats schema enum descriptions, but the overall length is reasonable 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?

This is a simple tool with two parameters, full schema descriptions, an output schema, and annotations covering read-only/idempotent behavior. The description covers the purpose, usage scenarios, and direction semantics adequately. Any missing return-value details are covered by the output schema, making this sufficiently 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?

Schema description coverage is 100%, so both 'code' and 'direction' are already documented. The description's closing sentence restates the enum semantics ('Direction 'parents' returns ancestor categories, 'children' returns subcategories') but adds little beyond the schema. No additional parameter-specific meaning is provided for 'code'.

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

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

The description clearly states the tool's purpose: 'Navigate the ICD-11 hierarchy to find parent or child entities.' This concrete verb-resource pairing distinguishes it from sibling tools like icd11_lookup, icd11_search, and icd11_chapters. The bullet list further emphasizes finding broader or narrower categories, leaving no ambiguity about what the tool does.

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 guidance with the 'Use this tool to:' bullet list, covering the main scenarios for parents, children, and understanding the classification structure. It does not explicitly name alternative tools or state when not to use it, but the clear use cases are sufficient for an agent to select the tool appropriately.

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, openWorldHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context (retrieval of definitions, notes, exclusions, synonyms, and official translation selection), but it does not disclose edge cases or limitations beyond what the schema and annotations already convey.

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 front-loaded main action, a bulleted list of use cases, and a short input instruction. It is compact and mostly non-redundant, though 'by code or URI' and 'Provide either an ICD-11 code or a full foundation URI' express the same constraint twice.

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 rich schema (100% parameter coverage), available output schema, and safety annotations, the description is largely complete for a lookup tool. It explains what data is returned, how to provide input, and how language selection works. It slightly lacks sibling routing guidance, but this is a minor gap rather than a fundamental omission.

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 baseline is 3. The description adds meaningful relational guidance by stating 'Provide either an ICD-11 code or a full foundation URI,' clarifying the one-of expectation that the schema does not encode structurally. It also provides a concrete code example, reinforcing the schema's format hints.

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 and resource: 'Get detailed information about a specific ICD-11 entity by code or URI.' It enumerates concrete outputs (full definition, coding notes and exclusions, official title and synonyms), making the tool's scope clear and distinguishing it from search or hierarchy siblings by emphasizing specific entities rather than discovery.

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 clear context for when to use the tool through 'Use this tool to' bullets and states the required input pattern: provide either an ICD-11 code or a foundation URI. However, it never explicitly mentions alternatives or exclusions, such as using icd11_search when the code/URI is unknown.

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, so the safety profile is covered. The description adds useful conceptual context about what postcoordination is ('adding severity, laterality, anatomy, etc.'), but it does not disclose details like error behavior, handling of invalid codes, or the exact response structure beyond what the output schema likely 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 compact and front-loaded with the core action. The bullet list is scannable and each line adds distinct information. The final sentence clarifies the general concept without unnecessary 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 one-parameter query tool with an output schema and comprehensive safety annotations, the description provides sufficient context: what the tool retrieves, why it is used, and the key decision points. No critical information appears to be missing for an agent to select and invoke it 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%, and the single parameter 'code' is already described as 'ICD-11 code to get postcoordination info for'. The description does not add meaning beyond the schema, 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 begins with a specific verb phrase, 'Get postcoordination information for an ICD-11 code', identifying both the action and the resource. The three bullet points further clarify the exact capabilities (axes, required vs optional postcoordination, extension possibilities), and the postcoordination focus cleanly distinguishes it from sibling tools like icd11_lookup, icd11_hierarchy, and icd11_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 bulleted 'Use this tool to' list gives clear scenarios for when this tool is appropriate. It does not explicitly name alternatives or state when not to use it, but the postcoordination-specific framing and sibling list make the intended usage obvious enough.

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. The description adds useful behavioral detail beyond annotations: it specifies that results include codes, titles, and relevance scores, and emphasizes that language support uses official WHO translations only, never machine-translated 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 well-structured: a clear opening sentence, a compact bulleted list of uses, a focused example of the language parameter, and a closing sentence about return values. Every sentence contributes useful information without unnecessary padding.

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 read-only search tool with rich annotations, a fully covered input schema, and an output schema, the description is complete. It explains the domain, language behavior, result contents, and supported use cases, leaving no critical gap for an agent deciding whether and how to invoke it.

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

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

Schema description coverage is 100%, so the schema fully documents query, language, and max_results. The description adds a concrete language example ('language: "pt"') and clarifies the official-translation behavior, but this largely duplicates the schema's own parameter descriptions, so value added is marginal.

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 searches ICD-11 for medical conditions, diseases, and health problems, with specific use cases like finding codes and searching by name/keyword. It is unambiguous about the resource and action, though it does not explicitly distinguish itself from the sibling icd11_lookup beyond the general implication that this tool performs free-text searching.

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' bullets covering code lookup, keyword search, and multilingual lookups. It gives clear context for when to use the tool, though it does not state when not to use it or mention alternatives like icd11_lookup, mesh_search, or loinc_search.

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, so the safety profile is covered. The description adds the useful limitation that the tool works only for LOINC codes with defined answer sets. However, it does not disclose behavior for non-applicable codes, empty results, or error handling, and it never contradicts 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 front-loaded with the main action, followed by scannable use-case bullets and an applicability constraint. The three bullets partially restate the first sentence ('valid response options,' 'answer codes,' 'answer lists' overlap), but the overall structure is still efficient and readable.

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 that has a full output schema and rich annotations, the description plus schema provide everything required: input format, purpose, and the critical applicability condition. No practical gap remains that would prevent an agent from selecting and invoking 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 coverage is 100%: the only parameter 'loinc_num' has a format pattern and a concrete example. The description's 'questionnaire item' phrasing adds domain context, but it adds no format or syntactic detail beyond what the schema already provides. This matches the baseline score for high schema coverage.

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

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

The description names a specific verb and resource: 'Get the list of valid answers for a LOINC questionnaire item.' It also adds a clear scoping constraint, 'Only applicable to LOINC codes that represent questions with defined answer sets,' which helps distinguish it from sibling search/detail/panel tools even though no sibling is named.

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 bullets explicitly state when to use the tool ('Find valid response options for survey questions,' 'Get answer codes for data entry validation,' 'Look up standardized answer lists'). The final sentence provides a clear applicability boundary ('Only applicable to LOINC codes that represent questions with defined answer sets'). It lacks explicit alternatives or when-not-to-use contrast with sibling tools, so it does not earn 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful detail about what information is returned, but it does not disclose operational behavior such as error handling for unknown codes or whether partial matches are returned.

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, front-loaded with the main purpose, and uses a compact bullet list to convey the tool's uses. Every sentence contributes useful information with 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?

For a single-parameter, read-only lookup tool with a rich output schema and comprehensive annotations, the description is complete: it states the purpose, the input format, and the kind of information available. No critical information needed to invoke the tool correctly 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 loinc_num parameter fully with a regex pattern and an example. The description adds value by giving a human-readable format 'XXXXX-X' and a meaningful domain example ('2339-0' for Glucose), reinforcing the expected input 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 clearly states a specific verb and resource: 'Get detailed information about a specific LOINC code,' and then enumerates the exact details returned (name, description, component, property, timing, system, scale, method). This sufficiently distinguishes it from search-oriented siblings like loinc_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 clear usage context: use it when you need full details for a specific LOINC code and supplies the required input format. However, it does not explicitly name sibling alternatives such as loinc_search, loinc_answers, or loinc_panels, nor does it state when not 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructiveness, so the safety profile is covered. The description adds useful behavioral context by stating what the tool returns and that it covers panels and forms. It does not describe edge cases or behavior for invalid or non-panel LOINC codes, but this is acceptable given 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 reasonably concise and front-loaded with the main purpose. The bullet list adds concrete use cases without excessive length, though the last bullet, 'Find related observations grouped together,' is somewhat vague and adds limited value.

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, one-parameter lookup with an output schema and strong annotations, the description is largely complete. It explains what the tool does, what it returns, and provides example use cases. A small gap is that it does not explicitly state that loinc_num must refer to a panel or form rather than any LOINC code.

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 100% coverage with a description, pattern, and example for loinc_num. The tool description adds no additional meaning about the parameter beyond what the schema already states, 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 identifies a specific verb and resource: 'Get the structure of a LOINC panel or form.' It clarifies the output as the list of LOINC codes in the panel and provides concrete examples like CBC and metabolic panel. It does not explicitly contrast itself with siblings such as loinc_details or loinc_answers, but the panel-structure focus is clear enough to distinguish it.

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 'Use this tool to' section with three concrete use cases: seeing all tests in a panel, getting assessment form structures, and finding grouped observations. This gives clear context for when to use it, though it does not explicitly state when not to use it or name an alternative 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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds that the tool returns matching codes with names, components, and properties, but it does not disclose additional behavioral details such as result ranking, truncation, or handling of partial matches. It does not contradict the annotations.

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

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

The description is moderately concise and front-loaded with the core purpose in the first sentence. The bullet list is useful but somewhat redundant with the opening line (e.g., 'Find LOINC codes' restates the search purpose). Overall, every sentence contributes useful context.

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 two-parameter read-only search tool with an output schema and strong annotations, the description is complete enough for an agent to select and invoke it correctly. It could more explicitly distinguish when to use loinc_search versus loinc_details or loinc_panels, but the core search intent is well covered.

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 schema already documents both parameters ('query' as search term and 'max_results' with range/default). The description adds example search terms but no deeper semantic guidance beyond what the schema provides, 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 clearly identifies the tool as a search over LOINC for laboratory tests, clinical observations, and measurements, with a specific verb ('Search') and resource. It gives concrete examples like 'glucose' and 'hemoglobin' and states the return type. However, it does not explicitly differentiate itself from sibling tools such as loinc_details or loinc_panels.

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 clear use cases: finding LOINC codes for lab tests, clinical measurements, vital signs, and diagnostic observations. This establishes appropriate search scenarios, but it does not mention exclusions or suggest alternatives like loinc_details for retrieving full code details or loinc_panels for panel searches.

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 read-only, idempotent, open-world, and non-destructive hints. The description adds valuable behavior beyond those: WHO release 2025-01 is bundled with the server, coverage excludes chapters/blocks, both dotted and undotted codes are accepted, and unknown codes produce an error by design. No contradiction exists with 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 descriptionis well-structured and front-loaded, with the core purpose in the first sentence. It contains useful detail on coverage, input format, and error handling. It loses one point for a minor redundancy: 'rather than text-search candidates' and 'rather than a fuzzy search fallback' make the same point twice.

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 one-parameter read-only tool with an output schema, the description is nearly complete. It covers the source table, return contents, coverage limitations, realistic input examples, and the error contract. An agent has enough context to select this tool and invoke it correctly without ambiguity.

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 is already fully described in the schema with examples. The description adds useful semantic detail by explicitly stating that both dotted and undotted forms are accepted and that no fuzzy matching is attempted, clarifying the exact input contract. This goes slightly beyond the schema without being redundant.

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 precise function statement: 'Authoritative ICD-10 → ICD-11 mapping using WHO transition tables'. It clearly describes what is returned (primary 1:1 ICD-11 category plus alternative candidates) and distinguishes itself from text-search tools by positioning itself as authoritative mapping rather than fuzzy 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 explicitly lists use cases: clinical coding, billing migration, retrospective analysis, and any workflow needing authoritative mapping. It also gives a clear when-not condition: no fuzzy matching is attempted, and unknown codes return an error by design. However, it does not explicitly name which sibling tool should be used instead for text-search candidates, so the alternative guidance is slightly implicit.

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 mark read-only/idempotent/open-world, so the bar focuses on added context. The description discloses that direct mappings are not freely available via API, licensing constraints, that the tool returns guidance only, and external resources; this exceeds annotation coverage and prevents false expectations.

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?

Four paragraphs, but each contributes: purpose, licensing caveat, alternative routes, and input format. No filler; key limitations appear right after the core sentence. Could be trimmed slightly but the length is justified by the caveats.

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 an output schema present and one well-documented parameter, the description's caveats about licensing, actual mapping availability, and alternatives fully equip an agent to decide whether to call and how to interpret the result. Nothing critical 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 input schema is 100% covered with a pattern and example, so the baseline is 3. The description adds a second concrete example ('718-7' Hemoglobin) and a 'like' format hint, which is useful but not substantially richer.

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 ('looks up') and resource ('LOINC code in NLM Clinical Tables') and states the deliverable is guidance, not a mapping. It explicitly distinguishes itself from mapping tools by saying 'It does not perform the mapping'.

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?

Gives explicit when-to-use (need guidance on obtaining a mapping) and when-not-to-use (need actual mapping), plus named alternatives: UMLS, LOINC Expression Association, SNOMED CT browser, and RELMA. This is model routing guidance for an agent.

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 meaningful context about language handling: official translations are returned 'where they exist', and 'content is never machine-translated', which shapes expectations about fallback behavior. It doesn't describe return structure, but the output schema covers that.

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 core purpose is front-loaded in the first sentence, followed by a compact bullet list of use cases and a single usage instruction. No redundant wording skills; every sentence adds 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?

For a two-parameter read-only lookup with a complete input schema and an output schema, the description covers the essential invocation details: required ID, optional language, and the semantics of translations. It is sufficient for an agent to select and call it 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 the baseline is 3. The description adds an example ID (D015242) and repeats the language translation behavior, but does not substantially expand on the schema's parameter documentation for language or mesh_id.

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?

States a specific verb and resource: 'Get detailed information about a MeSH descriptor by ID.' The bullet list enumerates distinct outputs (scope note, tree numbers, related concepts/synonyms), which differentiates it from siblings like mesh_search or mesh_tree that retrieve sets or hierarchy rather than a single descriptor's details.

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' list gives clear contexts: retrieving definitions, tree numbers, and synonyms. It does not mention exclusions or name alternative tools (e.g., 'use mesh_search when you don't have an ID'), so it stops short of explicit when-not 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, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds context that qualifiers refine descriptors and gives a concrete example, but it does not describe any nuances like potential result variability or output behavior beyond the 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: a clear opening sentence, bulleted use cases, and a short explanatory example. It is mostly front-loaded and free of fluff, though one bullet ('Understand aspects that can be specified') is somewhat redundant with the first bullet.

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 single-parameter read-only lookup tool with a full output schema and comprehensive annotations, the description provides enough context for an agent to select and invoke it correctly. 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 input schema covers the single parameter mesh_id completely with a pattern and concrete examples. The description does not need to add parameter details, but also does not enrich them. Since schema coverage is 100%, the 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 starts with a precise verb and resource: 'Get allowed qualifiers (subheadings) for a MeSH descriptor.' It then clarifies intended use cases like finding combinable qualifiers and building precise search queries, which clearly separates it from sibling tools like mesh_search or mesh_descriptor.

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 tool explicitly lists when to use it: finding which qualifiers can be combined with a descriptor, building precise MeSH search queries, and understanding specifiable aspects. It does not explicitly mention alternatives or when not to use it, so it misses the full 'when-not' guidance needed for 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 mark the operation read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond annotations, notably that language values request NLM's official translations and that content is never machine-translated, plus the kind of data returned.

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 action and uses a scannable bullet list for use cases. The three bullets are somewhat synonymous, creating minor redundancy, but the overall length and structure are still efficient.

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 rich annotations and an output schema, the description is complete enough: it states the purpose, return type, and the unique translation behavior. It doesn't need to explain return structures or auth, leaving only sibling-routing nuance as a minor gap.

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?

Input schema coverage is 100%, so the baseline is 3. The 'language' explanation in the description largely repeats the schema's own language parameter description, and it adds no new detail about query, match, or max_results.

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 identifies the verb ('Search') and resource ('MeSH descriptors'), and states it returns matching descriptors with MeSH IDs and labels. It doesn't explicitly differentiate itself from sibling tools like mesh_descriptor or mesh_tree, though the return-value phrase hints at a search-level result.

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?

A dedicated 'Use this tool to' section lists concrete scenarios: indexing medical literature, PubMed subject headings, and controlled-vocabulary lookups. It gives clear context but does not mention alternatives or when not to use this tool, so it stops short of 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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value by explaining that tree numbers represent hierarchical paths and giving a concrete example, but it does not go deeper into behavior such as pagination, number of multiple tree locations returned, or any edge cases. This is acceptable given the annotations but not exceptional.

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

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

The description is compact and well-structured: a single-sentence definition, a short bullet list of use cases, and an illustrative example. Every sentence earns its place, and the core 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?

For a read-only lookup tool with a complete input schema, output schema, and comprehensive annotations, the description provides enough context for an agent to call it correctly. The explanatory example of tree numbering adds helpful domain context without overloading.

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 parameter, including a regex pattern and examples, so the schema already fully documents mesh_id. The description does not need to add parameter-level detail, and indeed does not. Baseline 3 is appropriate when the schema carries the full semantic load.

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 the exact action ('Get the tree hierarchy location(s)') and the resource ('a MeSH descriptor'), making the tool's purpose unambiguous. It also differentiates from sibling tools like mesh_descriptor and mesh_search by focusing specifically on tree locations, and the tree-number example reinforces what makes this tool unique.

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 ('See where a term fits...', 'Understand broader/narrower relationships', 'Find related terms in the same branch'), effectively telling an agent when this tool is appropriate. However, it does not explicitly name alternative sibling tools or state when to avoid this tool, so it falls short of full explicit routing 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, idempotentHint=true, and openWorldHint=true, so the safety profile is known. The description adds that the tool returns class IDs, names, and classification sources, which tells the agent what output to expect. There is no mention of side effects because none exist, and the description reinforces the read-only nature.

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 with the core purpose. The bullet list adds value by giving concrete examples, and the return line is a single efficient sentence. Some bullets overlap conceptually, but overall it is well-structured and not verbose.

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 and no output schema, the description provides sufficient information: main purpose, use cases, and return contents. It lacks edge-case behavior like empty results, but this is a minor gap for a simple lookup tool. The provided description, combined with the annotations, gives an agent everything needed to call and interpret 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?

The only parameter, rxcui, is already well described in the schema with a regex pattern and label. The description adds no extra semantic detail about how to obtain the RxCUI or format requirements. Given 100% schema coverage, the 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 opening sentence uses a specific verb ('Get') and identifies the exact resource: therapeutic and pharmacologic classes for a drug. Examples like 'Beta-blockers' and 'NSAIDs' clarify the intended output. It does not explicitly name sibling tools, but the RxNorm scope and classification-type language make it distinguishable.

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' list provides three concrete scenarios: finding drug class, therapeutic categories, and mechanism of action. This gives clear context for when to invoke it. It stops short of naming alternative tools or exclusion criteria, so it does not fully reach the top tier.

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 destructiveHint=false, so the safe, read-onily nature is already machine-readable. The description adds relevant output context like checking active or remapped status, but does not disclose additional behavioral traits such as not-found behavior, pagination, or rate limits; with the annotations covering safety, this is 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 concise and well organized: a direct summary sentence, a short bulleted purpose list, and a final usage note. Every sentence adds value, and the most important 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?

For a read-only, single-concept lookup tool, the description fully covers what the tool does, the key use cases, and how to provide the identifier. An output schema exists to handle return-value expectations, and annotations cover the safety and idempotency profile, so nothing crucial 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 both parameters at 100% coverage, so the baseline is 3. The description adds a concrete usage example for rxcui — 'like 161' — and clarifies that related concepts include ingredients, brands, and forms, which reinforces the include_related parameter's meaning. This extra guidance nudges the score above the schema-only 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 opens with a clear verb-resource pair: 'Get detailed information about a specific RxNorm concept by RxCUI.' This directly distinguishes the tool from search-oriented siblings like rxnorm_search and from resource-specific siblings like rxnorm_ingredients. The bulleted use cases add concrete scope: names, synonyms, status, and related concepts.

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' guidance with specific use cases, making the intended invocation context clear. However, it does not name alternatives or state when not to use this tool versus a sibling such as rxnorm_search, so it stops short of full routing 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds the return format (ingredient RxCUIs and names) and implies multi-result behavior for multi-ingredient drugs, but does not disclose edge cases like invalid RxCUI or empty results. This is acceptable for a simple read-only lookup.

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 primary action is in the first sentence, followed by a bulleted use-case list and a one-line return summary. Every sentence earns its place; 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?

For a single-parameter read-only tool with annotations covering safety and an output schema present, the description is fully adequate. It states what the tool does, when to use it, what input is expected, and what it returns. 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?

Schema description coverage is 100%: the only parameter 'rxcui' is already described as 'RxCUI of the drug' with a numeric pattern. The description merely restates 'by RxCUI' without adding format, examples, or constraints beyond the schema, so baseline 3 is appropriate.

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

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 active ingredients for a drug by RxCUI.' It further specifies three concrete use cases (find active ingredients, check single vs. multiple ingredient products, identify generic components) and states the return type (ingredient RxCUIs and names). This clearly distinguishes it from siblings like rxnorm_search, rxnorm_concept, and rxnorm_classes.

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 gives explicit contexts for when this tool is appropriate, such as identifying active ingredients and determining single vs. multi-ingredient products. It does not explicitly name alternatives or state when not to use it, but the context is clear enough that an agent can route to it correctly.

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 non-destructive behavior. The description adds value by clarifying the two-way mapping relationship and the either/or parameter expectation. It does not over-extend or contradict 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, uses bullets for scannability, front-loads the main verb/resource, and contains no filler or repetition of structured fields.

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 two-parameter, no-required-parameter mapping tool with an output schema and full annotations, the description covers the invocation directions suffciently. It does not address edge cases like both parameters being provided, but those are minor for this use 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%, so the baseline is 3. The descriptions of ndc and rxcui in the schema already convey their meanings and alternatives. The tool description reinforces the either/or relationship but adds little beyond the schema's own parameter descriptions.

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 ('Map') and explicitly states the resource (RxNorm concepts and National Drug Codes). It then itemizes the two main operations: getting NDCs for an RxCUI and finding an RxCUI from an NDC, making its 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 bulleted 'Use this tool to' section gives clear contexts for invocation, and the final line explains which parameter to provide for each direction. It does not explicitly name sibling alternatives or exclude when not to use it, but the directive is clear enough.

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 modest context by stating results include RxCUI identifiers, names, and term types, but it does not disclose additional behavioral traits such as matching behavior or limitations.

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 main purpose, followed by concise bullets and a clear return summary. It is well organized and reasonably sized, though the bullets are somewhat repetitive with the opening sentence.

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 search tool with full schema coverage, strong annotations, and an output schema, the description covers purpose, usage contexts, and return contents reasonably well. It could be more complete by pointing to sibling tools for related lookups, but nothing critical 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 input schema already provides full descriptions for both parameters (query and max_results), so the description adds little beyond what the schema contains. It reinforces that query can be a brand or generic name, but this is already in 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 the tool searches for drugs in RxNorm by brand or generic name, which is a specific verb+resource. It does not explicitly differentiate itself from sibling tools like rxnorm_concept or rxnorm_ingredients, so it misses the highest score for sibling differentiation.

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

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

Explicit use cases are listed under 'Use this tool to', including finding drug concepts, looking up medications for prescribing, and searching formulations. However, it does not state when to avoid this tool in favor of siblings such as rxnorm_concept or rxnorm_ndc, so it lacks exclusions/alternatives.

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 annotations. It explains that the server doesn't ship historical snapshots, so most results are guidance only; it introduces `bundled_versions` as the server-side truth; it details the ICD-10/ICD-11 cross-revision special behavior; and it explicitly states the tool is intentionally not a diff engine. These are meaningful behavioral traits not available in the annotations or 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: an opening sentence states the purpose, a paragraph handles the general vs ICD-specific behavior, a bulleted input section explains parameters, and a closing caveat frames limits. No sentence is wasted; each one contributes either parameter behavior, output details, or usage boundaries. It's longer than two sentences but the complexity justifies it.

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 (three parameters, a special ICD case, external authoritative fallback, and a non-diff engine posture), the description covers all important aspects. It explains what the tool returns, when to expect guidance vs actual data, what the omitted parameters do, and why the tool should not be used as a diff engine. Since an output schema exists, the missing structured return-format details are not a gap.

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 schema coverage is 100%, the description adds real semantic value beyond the schema's short descriptions: it defines what each optional parameter means ('If omitted, the tool reports against the currently-bundled version' / 'publisher's latest known release'), and it documents a parameter combination (`terminology: "icd10"` with no `to_version`) that triggers the special cross-revision output. This is exactly the kind of usage nuance schema fields rarely convey.

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 says exactly what the tool does: 'Report what diff data is available between two versions of a terminology.' It clearly distinguishes this from actual mapping/diff siblings by calling itself a 'metadata + guidance layer, not a diff engine' and by separating the ordinary guidance case from the ICD-10 vs ICD-11 special case.

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 usage guidance: for most terminologies it is guidance-only and points to the publisher's changelog as authoritative; for ICD-10 vs ICD-11 it names the exact inputs (`terminology: "icd10"` with no `to_version`) and the expected output. It does not explicitly name an alternative sibling like `map_icd10_to_icd11`, but its when-not phrasing ('not a diff engine') is clear. One small gap: no direct comparison to the `terminology_versions` sibling for simply listing available versions.

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 say readOnly/openWorld/idempotent/non-destructive; the description adds genuinely useful behavior: the tool returns the full set of 8 unless filtered, the ICD-10→ICD-11 entry is read live from the bundled dataset, and everything else is project metadata. This exceeds annotation coverage without contradiction.

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 function, uses bullets for the target audience, and ends with a concise usage/behavior note. Every sentence earns its place with no tautology 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 one-parameter, read-only list tool with an output schema present, the description covers the return scope, filtering behavior, special frozen-value case, and live-vs-metadata distinction. No important caller-facing gap remains.

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 describes the filter parameter, so the baseline is 3. The description adds meaning by clarifying that CID-10 is frozen at V2008 and by associating the display terminologies (ICD-11, SNOMED, LOINC, RxNorm, MeSH, ATC) with their enum values, which helps agents choose correctly.

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 opening sentence states a precise verb (List) with a specific resource (terminology versions) and enumerates the exact data fields (version, release date, publisher, source URL, update cadence). This is clearly distinct from the sibling lookup/search/diff tools and from terminology_diff.

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 concrete use cases: pre-flight checks, verifying frozen CID-10 and ICD-10→ICD-11 transition tables, and citing versions in research. It does not explicitly name sibling alternatives to avoid, but the context is specific enouugh to route an agent correctly.

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?

Even though annotations already declare readOnly and idempotent hints, the description adds substantial behavioral context beyond them: the exact meaning of valid/active/title/replaced_by/source/error, terminology-specific null behavior, ICD-10-only replacement mapping today, error semantics distinguishing 'not found' from 'couldn't validate', and worst-case timing due to parallel upstream calls. This is far beyond what annotations alone provide.

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 long but tightly structured: purpose first, then use case, then a clear field-by-field output breakdown, then constraints and performance expectations. Every sentence adds useful information, and the bullet formatting makes the return semantics easy for an agent to parse.

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 complex, with one nested parameter, eight terminologies, nuanced output fields, and multiple sibling tools, yet the description leaves no practical gap. It explains return semantics, error interpretation, terminology requirements, batch limits, and latency behavior, making it fully actionable for an agent even before inspecting 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?

Schema coverage is 100%, and the schema already documents the code field, the terminology enum, the required-term logic, and the maxItems constraint. The description restates and reinforces these details but does not add materially new input-parameter semantics beyond what the schema provides, so the baseline of 3 is appropriate.

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

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

The description names a specific verb and resource: validate a mixed batch of medical codes against their source terminologies. It clearly distinguishes itself from the many single-terminology lookup/search siblings by emphasizing batch, mixed-terminology validation and features like replacement surfacing and activity grading.

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 a clear use case ('retrospective analysis of legacy databases') and explains when the tool is appropriate, including the hard 50-code cap and parallel execution behavior. It does not explicitly name sibling alternatives or state when not to use this tool, but the context is clear enough for an agent to select it correctly.

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