Medical Terminologies MCP

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

Annotations already show readOnly, idempotent, non-destructive. Description adds details about source (NLM RxClass), return logic (one entry per ATC code, combination products), and hierarchy information.

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?

Tight structure: main sentence then bullet points. No superfluous text, all sentences earn their place.

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

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

With an output schema present, description covers essential behavior: source, per-code return, combination handling. Well-rounded for a lookup 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?

Single parameter drug_name has 100% schema coverage. Description adds value by clarifying input can be brand or generic, and gives an example (metformin).

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?

Clearly states it looks up ATC classifications by drug name with examples. Does not explicitly differentiate from sibling tools like atc_lookup or atc_members, but the focus on drug-to-code mapping is clear.

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

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

Provides usage scenarios in bullet points, such as finding ATC codes and therapeutic hierarchy. Lacks explicit guidance on when not to use or comparison with sibling 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, idempotentHint, and destructiveHint. The description adds useful context on accepted code lengths, hierarchy levels, and the exclusion of substance codes, but does not elaborate on error handling or rate limits.

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, uses bullet points for readability, and front-loads the core purpose. Every sentence adds value without redundancy.

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

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

For a simple one-parameter tool with an output schema, the description fully explains functionality, valid inputs, and exclusions. It is complete given the tool's complexity and available metadata.

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 description already contains the same information as the tool description about code format and limitations. The description adds no new parameter semantics beyond what the schema provides.

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

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

The description states 'Look up an ATC code at level 1-4 to get its name and hierarchy level,' providing a specific verb and resource. It distinguishes from siblings by mentioning the alternative tool atc_classify for substance-level codes.

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

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

Explicitly lists use cases (resolve, confirm, identify) and includes a clear when-not-to-use: substance-level codes should use atc_classify. This provides both context and 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 adds value beyond annotations by explaining that RxNorm is US-centric and that each member includes a source_atc_code for disambiguation. It does not contradict any annotations.

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

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

The description is concise and well-structured with a clear lead sentence, bullet points for use cases, and an explanatory note. Every sentence contributes meaning without redundancy.

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

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

Given the simple single-parameter tool with complete schema coverage, annotations, and the presence of an output schema, the description fully covers the tool's behavior, return value specifics, and caveats. No gaps remain.

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

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

The schema already describes the parameter 'atc_code' with a pattern, but the description adds crucial semantic details: higher levels return all substances, level 5 returns a single substance, and the output includes source_atc_code. This compensates for the otherwise minimal 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 lists drugs/substances belonging to an ATC class, with specific examples like 'A10BA' → metformin. It distinguishes itself from sibling tools like atc_classify and atc_lookup by focusing on enumerating members.

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

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

The description explicitly states when to use this tool (e.g., enumerate members, build a drug list) and notes a limitation (US-centric RxNorm catalog but international codes). It does not explicitly mention when not to use it, but the use cases are sufficiently clear.

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

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

Annotations already indicate read-only, idempotent, and non-destructive behavior. The description adds that it returns groups but does not detail response structure or error handling. With good annotations, this is adequate.

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

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

Description is concise, uses bullet points for clarity, and includes an illustrative example. Every sentence provides 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 simple lookup tool with a clear annotation set and output schema, the description is sufficient. It covers the primary use cases and parameter requirements without missing critical context.

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

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

Schema coverage is 100% with a description for the single parameter 'num'. The tool description does not add new semantic info beyond the schema, so baseline score of 3 applies.

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

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

Description clearly states the tool retrieves a CID-10 chapter and its groups, with specific verb 'Get' and resource. It distinguishes from sibling 'cid10_chapters' by focusing on a single chapter. The example reinforces the 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?

Description explicitly lists use cases: drilling into groups, building hierarchical browsers, and finding code ranges. It does not mention when not to use, but the context from sibling tools makes alternatives apparent.

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, open-world, idempotent, and non-destructive behavior. The description adds context that the tool returns exactly 22 entries and that CID-10 V2008 has not been updated since 2008, which is valuable beyond annotations.

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

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

The description is concise and front-loaded. The first sentence states the core purpose, followed by bullet points for usage, and a final note about the static nature. No redundant or unnecessary words.

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 low complexity (no parameters, fixed 22 results), and the presence of an output schema, the description covers all needed aspects: purpose, usage, and behavioral notes. It is fully sufficient for an agent to invoke correctly.

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

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

The tool has no parameters, and schema coverage is 100% (vacuously). The description adds no parameter information, but none is needed. It provides context about the fixed output (22 entries). Baseline 4 for zero parameters.

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 action 'List' and a specific resource 'chapters of CID-10' with details on what is returned (code ranges and Portuguese titles). It clearly distinguishes from siblings like cid10_chapter (singular) and cid10_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 explicit use cases in bullet points (see top-level structure, map code to chapter, build table of contents). It does not explicitly state when not to use, but the sibling tools imply alternatives (e.g., cid10_chapter for a specific chapter).

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false. The description adds that the tool returns the canonical display and can include gender/cause-of-death restriction flags. This provides useful behavioral context beyond the annotations, such as the normalization of input formats (accepting both forms) and the inclusion of optional restriction information.

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 (4 sentences), uses bullet points for use cases, and avoids unnecessary details. Every sentence adds value: purpose, usage list, and input format clarification. The structure is well-organized with a clear heading and subpoints, making it 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?

Given the simplicity of the tool (1 parameter, clear input validation), the description is thorough enough. It covers purpose, usage, and input formatting. Since an output schema exists, the return structure is likely documented there. Minor omission: it does not mention error handling for invalid codes, but that is acceptable given the schema's pattern constraint and the output schema's likely inclusion of error responses.

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 description adds that the tool accepts both dotted and undotted forms and returns the canonical display. This goes beyond the schema's pattern and description, clarifying input flexibility and output normalization. The single parameter is well-documented both in schema and 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 clearly states it looks up a specific CID-10 code and returns its Portuguese name. It provides concrete examples ("I21" → "Infarto agudo do miocárdio") and specifies accepted formats (dotted and undotted), distinguishing it from sibling tools like cid10_search (which searches by text) and cid10_chapter (which lists chapter codes).

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

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

The description explicitly lists three use cases: resolving a code to its Brazilian description, confirming code existence, and retrieving restriction flags. It states it accepts both dotted and undotted forms. However, it does not explicitly mention when not to use it or suggest alternatives among siblings (e.g., cid10_search for textual queries). The guidance is clear but lacks exclusionary context.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint. The description adds valuable behavioral details: search returns categories/subcategories, is diacritic-insensitive, and uses V2008 version. 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 concise (about 100 words) and well-structured with bullet points for use cases. Every sentence adds value without redundancy.

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

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

Given the presence of an output schema, the description covers all necessary aspects: purpose, usage context, version, sibling differentiation. No gaps for a search tool.

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

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

Schema coverage is 100%, but the description adds context for the query parameter (Portuguese term, diacritic insensitivity) which supplements the schema. The note about diacritics is not in the schema 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 clearly states the tool searches Brazilian CID-10 by Portuguese text. It lists specific use cases (SUS/ANVISA, official translation, billing) and distinguishes from icd11_search by version and language.

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

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

Explicitly states when to use (Brazilian contexts, Portuguese) and when to use icd11_search instead. However, no guidance is given for when to prefer this over other CID-10 siblings like cid10_lookup or cid10_chapter.

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 readOnly, openWorld, idempotent, and non-destructive behavior. The description adds context about the terminologies searched and parameter combination logic, which supplements but does not 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 two paragraphs with a clear opening sentence and bullet points for use cases. Every sentence serves a purpose without unnecessary verbosity.

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

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

Given the complexity (3 parameters, output schema exists), the description covers purpose, usage, parameter behavior, and lists terminologies. The output schema handles return value documentation.

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 description clarifies the interplay between 'source_terminology' and 'target_terminologies' ('source is subtracted from targets'), adding meaning beyond the schema's individual 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 clearly states 'Search for equivalent terms across multiple medical terminologies,' using specific verbs and resources. It distinguishes from sibling tools that are specific to individual terminologies or mappings.

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

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

The description provides explicit use cases (e.g., 'Find the same concept in different coding systems') and explains how to use parameters, including their interaction. It lacks explicit 'when not to use,' but the context of numerous sibling tools implies it.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true. The description adds that it lists all chapters and mentions there are 28 chapters, which is consistent but does not reveal additional behavioral traits 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 very concise: one sentence for the main action, three bullet points for use cases, and one sentence about the number of chapters. Every sentence adds value and 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?

The tool is simple with one optional parameter and an output schema exists. The description covers purpose and use cases adequately, but could add a note about the language parameter to be fully self-contained.

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% (language parameter described in schema). The description does not mention the language parameter or add meaning beyond the schema, so 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 states 'List all ICD-11 chapters (top-level categories)' with a specific verb and resource. It distinguishes from siblings like cid10_chapters and icd11_hierarchy by explicitly naming ICD-11 and listing use cases.

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 (overview, finding chapters, navigation) but does not explicitly mention when not to use or compare to alternatives like icd11_lookup or icd11_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=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false. The description adds that the tool returns parent/children entities but does not provide additional behavioral context beyond what annotations and schema cover. 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 short, well-structured with bullet points for use cases, and front-loaded with the main action. Every sentence adds value without redundancy.

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

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

Given the simple two-parameter tool, the presence of an output schema (not shown), and clear annotations, the description adequately covers the tool's purpose and usage. No gaps identified.

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 minimal meaning beyond the schema, only clarifying that 'parents' returns ancestors and 'children' returns subtypes, which is already described in the enum 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 clearly states that the tool navigates the ICD-11 hierarchy to find parent or child entities, using specific verbs and resource. It distinguishes itself from sibling tools like icd11_lookup or icd11_search by focusing on hierarchical relationships.

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

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

The description lists concrete use cases (finding broader categories, specific subtypes, understanding structure) and explains the direction parameter. While it doesn't explicitly state when not to use it, the sibling context provides alternatives for other 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 readOnlyHint, idempotentHint, and destructiveHint, so the description does not need to repeat those. The description adds useful behavioral context: it retrieves definitions, notes, exclusions, titles, and synonyms. No contradictions with annotations.

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

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

Very concise: two sentences with a bullet-like list for use cases. Every sentence adds information. No redundancy or filler.

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

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

Given that an output schema exists, description need not explain return values. It covers purpose, parameters, and usage. Minor gap: schema shows zero required parameters, but description implies at least code or URI is needed, which could confuse an agent. Overall adequately complete for a lookup tool with rich annotations.

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

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

Schema coverage is 100% with descriptions for all parameters. The description adds value by explaining that either code or URI can be provided and includes example codes. This helps clarify usage beyond what the schema alone provides.

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

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

Description clearly states it gets detailed information about a specific ICD-11 entity by code or URI, listing specific use cases like definition, coding notes, exclusions, titles, and synonyms. It distinguishes from sibling tools that cover other terminologies (ATC, CID10, LOINC).

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?

Description explains when to use (to get detailed info on a specific entity) and how to provide input (code or URI). But it does not explicitly guide when not to use or mention alternatives among siblings (e.g., icd11_search for searching, icd11_hierarchy for tree navigation). Usage is implied but lacks exclusion criteria.

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 no destructive action. The description adds context about postcoordination (severity, laterality, anatomy) but does not disclose additional behavioral traits beyond what annotations provide. This is adequate but not enhanced.

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 with four sentences, front-loaded with the main action. It uses bullet-style listing for use cases, making it easily scannable. No superfluous 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?

Given the complexity of postcoordination, the description adequately explains the concept and lists intended use cases. With an output schema present, the description does not need to detail return values. It is complete for an info-retrieval tool.

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

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

Schema coverage is 100% with a single parameter 'code' described clearly. The description does not add extra meaning or examples for the parameter 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 clearly states that the tool retrieves postcoordination information for an ICD-11 code. It lists specific use cases (axes, required vs optional, extension), making the purpose distinct from sibling tools that focus on general lookup or 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 explicit guidance on when to use the tool by listing three use cases: finding axes, checking required vs optional postcoordination, and understanding extension possibilities. It does not explicitly state when not to use it or mention alternatives, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, covering safety and idempotency. The description adds return format (codes, titles, relevance scores) but no additional behavioral traits beyond what annotations imply. Bar is lowered by annotation completeness.

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 5 sentences, front-loaded with purpose, followed by explicit use cases and return value. No redundancy or filler.

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

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

The tool has an output schema (not shown but indicated) and annotations cover behavioral aspects. The description mentions return fields. For a search tool with straightforward parameters and no nested objects, this is complete. Minor omission: no mention of result limits or error states, but max_results parameter handles that.

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

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

Schema coverage is 100%, so baseline is 3. The description does not add new parameter semantics beyond the schema's own descriptions, which are already clear. The use cases imply the query parameter usage but don't add 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 clearly states the tool searches for medical conditions in ICD-11, lists specific use cases (find codes, search by name, multi-language), and distinguishes from sibling tools like icd11_lookup (exact code) and icd11_chapters (hierarchy navigation).

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 provides a bulleted list of when to use the tool (find codes, search by name/keyword, multi-language lookup). It does not explicitly mention when not to use it or name alternatives, but the context of sibling tools makes the guidance clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false. The description adds the condition of applicability (LOINC codes with defined answer sets) but does not disclose additional behavioral traits such as return format, pagination, or error handling. Given the comprehensive annotations, the description adds moderate value.

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 very concise: five sentences including a bullet-like list. It avoids redundancy and is well-structured, front-loading the main action. Every sentence serves a purpose.

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

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

Given the tool's simplicity (one parameter), existence of an output schema, and comprehensive annotations, the description covers all necessary context: what the tool does, when to use it, and its limitations. No gaps remain.

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

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

There is one parameter (loinc_num) with 100% schema description coverage (provides format and example). The tool description does not add further semantics beyond what the schema already covers. Baseline of 3 is appropriate.

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

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

The description clearly states the tool's purpose: 'Get the list of valid answers for a LOINC questionnaire item.' It specifies the action (get), resource (answers for LOINC item), and includes example use cases (find valid response options, get answer codes, look up standardized answer lists), distinguishing it from sibling tools like loinc_details 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 provides explicit usage guidance: 'Use this tool to...' followed by three scenarios, and notes applicability condition: 'Only applicable to LOINC codes that represent questions with defined answer sets.' It does not mention alternatives or when not to use, but the condition effectively excludes non-answer-set LOINC codes.

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, etc. The description adds value by specifying exactly which fields (component, property, timing, system, scale type, method) are returned. 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?

Front-loaded with clear purpose, followed by bullet-pointed use cases, and ends with a format example. Every sentence is concise and relevant.

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 output schema, the description is adequate. It lists return fields but does not mention error handling or missing code behavior. Overall sufficient for common use.

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

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

Schema coverage is 100%; the description reiterates the format and provides an example, adding marginal context beyond what the schema already provides (pattern, 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?

Clearly states the tool retrieves detailed information about a specific LOINC code, listing specific attributes (full name, description, component, property, timing, system, scale type, method). This distinguishes it from siblings like loinc_search (searching) and loinc_panels (panel structure).

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

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

Explicitly lists use cases with bullet points. Does not mention when not to use or alternatives, but the context implies it is for when you have a specific code. Lacks exclusions or comparison to siblings.

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

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

Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which align with the description. The description adds value by specifying the return type (list of LOINC codes), going beyond annotation details.

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 extremely concise, with three short paragraphs front-loaded with the core action. Every sentence adds value without redundancy.

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

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

Given the tool has an output schema (not shown but present), the description adequately covers semantics. It mentions the return is a list of LOINC codes, sufficient for understanding the tool's output.

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

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

The input schema has 100% coverage with a clear description for loinc_num. The tool description provides an example format (e.g., '2339-0') but adds minimal extra meaning 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 clearly states the tool retrieves the structure of a LOINC panel or form, listing included tests. It distinguishes from sibling tools like loinc_search and loinc_details by focusing on panel composition.

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

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

The description provides explicit use cases: seeing all tests in a panel, getting assessment form structure, and finding related observations. While it doesn't explicitly state when not to use it, the context of sibling tools implies 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?

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, destructiveHint. The description adds behavioral context by stating it 'returns matching LOINC codes with names, components, and properties', which is beyond annotations.

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

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

The description is concise: two short paragraphs. It front-loads the purpose, lists use cases, and mentions return information. Every sentence adds value with no redundancy.

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

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

Given the rich annotations, 100% schema coverage, and presence of an output schema, the description is complete. It provides purpose, usage guidance, and return content without missing critical information.

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 parameters are well-documented in the schema. The description adds example search terms and the return content type, but does not significantly enhance parameter understanding beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool searches LOINC for laboratory tests, clinical observations, and measurements. It provides specific examples like 'glucose' and 'hemoglobin', and the context of sibling tools shows it is distinguished by focusing on LOINC terminology.

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

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

The description lists clear use cases: finding LOINC codes, clinical measurements, diagnostic observations. It does not explicitly state when not to use it or alternatives, but the sibling tool names and the specific LOINC focus provide implicit 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?

The description adds context beyond annotations: WHO table release, coverage of 11,243 categories, acceptance of dotted/undotted forms, and honest 'no mapping' response. No contradictions. It doesn't detail error handling for invalid inputs, but annotations already cover safety and idempotence.

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 long but well-structured: purpose first, then details, usage tips, and edge cases. Every sentence adds value. Minor tightening possible, but overall 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 output schema (mentioned but not shown), the description adequately explains mapping details, coverage, and missing code handling. It provides enough context for an agent to use the tool correctly without needing additional information.

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?

With only one parameter and 100% schema coverage, the description adds value by providing examples and noting that dotted and undotted codes are both accepted. This clarifies acceptable input formats 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 clearly states the tool's function: mapping ICD-10 to ICD-11 using authoritative WHO tables. It specifies the output includes primary and alternative mappings with codes, titles, and URIs. It distinguishes from siblings like find_equivalent and icd11_search by emphasizing authoritative mapping over text search.

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

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

The description provides explicit use cases (clinical coding, billing migration, etc.) and gives input examples. It implies when not to use (e.g., for fuzzy search, use other tools), but lacks a direct 'do not use for' statement. The guidance is clear and helpful.

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 true and destructiveHint false. The description adds significant behavioral context: it does not perform mapping, returns only guidance, and explains licensing limitations (UMLS license, LOINC license). 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 well-structured: first sentence states core purpose, then limitations, then alternatives, then example. Every sentence adds value, but it is somewhat lengthy. Front-loading is effective.

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

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

For a tool that deals with legal restrictions and indirect mapping, the description is highly complete: it explains what the tool does, what it doesn't, licensing context, alternative sources, and an input example. Output schema exists to cover return value details.

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

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

Schema description coverage is 100% with the loinc_code parameter described. The description adds value by providing example codes ('2339-0', '718-7') and clarifying the format. This exceeds the baseline of 3.

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 explicitly states the tool's purpose: it looks up a LOINC code and returns guidance on where to obtain a LOINC → SNOMED CT mapping, and importantly clarifies that it does not perform the mapping itself. This distinguishes it from mapping tools like map_icd10_to_icd11.

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

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

The description provides clear when-to-use and when-not-to-use guidance, including explicit alternatives such as UMLS or the LOINC Expression Association files for programmatic mapping and the SNOMED CT browser or RELMA for interactive lookup. This helps the agent choose 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, idempotent, openWorld, and non-destructive hints. The description adds behavioral content by specifying the type of returned information (definition, hierarchy, synonyms), which goes beyond annotations.

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

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

The description is concise (4 lines), uses bullet points for clarity, includes an example, and is front-loaded with the primary purpose.

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

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

Given the presence of an output schema (not shown), the description sufficiently covers the tool's capabilities and usage without needing to detail the return format.

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 baseline is 3. The description adds an example ID ('D015242') but no additional semantic detail for the language parameter.

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

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

The description clearly states 'Get detailed information about a MeSH descriptor by ID' and lists specific outputs (scope note, tree numbers, related concepts, synonyms). This distinguishes it from siblings like mesh_search, mesh_tree, and mesh_qualifiers.

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

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

The description provides explicit use cases ('Use this tool to:'), but does not explicitly state when not to use it or name alternative tools. However, the sibling context implies the appropriate scenarios.

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, destructiveHint. Description adds context about returning qualifiers and offers an example, enhancing transparency 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?

Description is concise with a single-sentence summary, bulleted use cases, and an example. No redundant information.

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

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

Given the presence of an output schema and clear annotations, the description is sufficient. It explains what the tool does and how to use it. Could add note about qualifiers being subheadings, but not necessary.

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

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

Schema covers the single parameter with description and pattern. Description does not add new semantic details beyond the schema; it reiterates the purpose of mesh_id in context.

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

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

The description clearly states the action ('Get allowed qualifiers') and the resource ('MeSH descriptor'). It distinguishes from sibling tools like mesh_descriptor (descriptor details) and mesh_search (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?

Provides explicit use cases ('Find which qualifiers can be combined', 'Build precise queries'). Does not mention when not to use or alternatives, but context from siblings implies alternatives exist.

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, etc. The description adds that it returns matching descriptors with MeSH IDs and labels, which is consistent. No contradictions, but does not elaborate on pagination or response structure beyond 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 description is concise (4 sentences) and front-loaded with purpose and usage. Every sentence adds value without unnecessary words.

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 is a simple search, with rich annotations and full schema coverage, the description covers the essential aspects: purpose, usage, and output summary. Output schema exists, so return values need not be detailed.

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%, all parameters have descriptions in the schema. The description does not add additional meaning beyond the schema; it sets context but not per-parameter details.

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 MeSH descriptors, listing specific use cases like indexing medical literature and PubMed searches. It distinguishes from sibling tools focused on other terminologies (ATC, ICD, LOINC, etc.).

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

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

The description explicitly lists three use cases ('Use this tool to:'), providing clear context for when to use it. It does not mention alternatives or when not to use, but the sibling tool names imply alternatives for other vocabularies.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds meaningful context about the hierarchical nature and example path, without contradicting annotations. It explains what the tool does beyond safety traits.

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 short (3 sentences and 3 bullet points), well-structured, and front-loaded with the main action. Every sentence adds value without redundancy.

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

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

Given the simple tool (one parameter, clear annotations, output schema present), the description covers the necessary context: what the hierarchy is, how tree numbers work, and typical use cases. No gaps.

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

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

Schema coverage is 100% with a well-described parameter (mesh_id). The description does not add further details about the parameter itself, so a baseline of 3 is appropriate.

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

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

The description clearly states the tool retrieves the tree hierarchy location(s) for a MeSH descriptor, with examples and specific use cases (e.g., C14.280.647). This distinguishes it from siblings like mesh_descriptor or mesh_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 three use-case bullet points ('Use this tool to: ...'), providing clear context for when to use it. It does not explicitly exclude other tools, but the purpose 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, idempotentHint, and destructiveHint as safe. The description adds the return structure ('class IDs, names, and classification sources'), which is useful but does not delve into behavioral nuances like handling multiple classes or classification sources. A 3 is appropriate given the annotations cover the safety profile.

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

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

The description is concise: a one-line purpose, three bullet points for uses, and a one-line return summary. It is front-loaded with the main action and uses minimal yet informative language.

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 low complexity (one required parameter, read-only) and the presence of both annotations and an output schema, the description covers the essential aspects: purpose, usage scenarios, and return structure. It lacks details about potential multiple classes or error conditions, but overall it 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 coverage is 100% and the parameter description 'RxCUI of the drug' is clear. The tool description does not add additional semantic context beyond what the schema provides, so a baseline score of 3 is correct.

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 explicitly states 'Get therapeutic and pharmacologic classes for a drug' and lists specific use cases with examples like 'Beta-blockers' and 'NSAIDs'. This clearly specifies the verb and resource, and while not directly comparing to siblings, the purpose is distinct from other rxnorm tools.

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

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

The 'Use this tool to' section provides clear context for when to use it, listing three specific scenarios. However, it does not explicitly exclude alternatives or mention when not to use it, which would improve guidance.

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

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

Annotations already declare readOnly, idempotent, and nondestructive behavior. The description adds context about returned information (names, status, related concepts) which aligns with annotations. 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?

Concise bullet list and example. Every sentence adds value; no wasted words. Front-loaded with main action.

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

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

Given the presence of an output schema and good annotations, the description covers the tool's core purpose and typical outputs. Lacks mention of error handling for invalid RxCUI, but this is often acceptable.

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%, baseline is 3. Description provides an example ('161') but no additional meaning beyond schema for rxcui or include_related. The use case mentions related concepts but doesn't directly explain the include_related parameter.

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 it retrieves detailed info for a specific RxNorm concept. It implicitly differentiates from sibling tools like rxnorm_search and rxnorm_ingredients by focusing on a single RxCUI, but does not explicitly contrast them.

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

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

The description lists use cases (get name, status, related concepts) but does not specify when to avoid this tool or explicitly name alternatives, leaving the guidance implied.

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, destructiveHint=false. The description adds that it returns ingredient RxCUIs and names, which is consistent. 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 short, front-loaded with the main action, and uses bulleted examples. Every sentence is meaningful and no wasted words.

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 the description explains the return format (ingredient RxCUIs and names), the description is complete enough for an agent to understand what the tool returns.

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 rxcui has schema coverage 100% with pattern and description. The description does not add extra detail about the parameter 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 clearly states the tool gets active ingredients for a drug by RxCUI, and lists specific use cases (find active ingredients, check single vs. multiple, identify generic components). It distinguishes from siblings like rxnorm_concept and rxnorm_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 explicit use cases for when to use this tool, but does not explicitly state when not to use it (e.g., for full concept details use rxnorm_concept). The examples are clear and helpful.

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, etc. Description adds minimal behavioral context (mapping direction, parameter mutual exclusivity) but does not significantly extend beyond 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?

Five tightly focused sentences with front-loaded purpose, bulleted use cases, and precise usage note. No wasted words.

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?

Adequately describes purpose and usage for a simple mapping tool. Could briefly mention output format (list or single value) but output schema likely covers that.

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

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

Schema coverage is 100% with descriptions for both parameters. Description restates the mutual exclusivity but adds no deeper semantics beyond 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?

Description clearly states bidirectional mapping between RxNorm concepts and NDC codes, with specific use cases (get NDCs for RxCUI, find RxCUI for NDC). Distinguishes from siblings like rxnorm_concept or rxnorm_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?

Explicitly states when to use: for cross-referencing coding systems by providing either rxcui or ndc. Clear context but no mention of when not to use or 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?

Annotations already declare read-only and idempotent behavior. The description adds that results include RxCUI, names, and term types, but does not mention any additional behavioral details like pagination, rate limits, or search matching algorithm, which would be helpful.

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

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

The description is concise (three sentences plus bullet points), front-loaded with the main purpose, and organized into clear sections for use cases and return information.

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

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

Given the tool's simplicity (2 parameters, output schema present), the description covers the main use cases and return format. However, it could be more complete by noting search behavior (e.g., case-insensitivity, exact vs partial match) and referencing other RxNorm tools for follow-up actions.

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

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

Schema description coverage is 100%, with clear descriptions for both 'query' and 'max_results' parameters. The description adds no extra semantics beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description clearly states the tool searches for drugs in RxNorm by brand or generic name, listing specific use cases and return fields (RxCUI, names, term types). This differentiates it from sibling RxNorm tools like rxnorm_concept or rxnorm_ingredients.

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

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

The description provides a list of when to use the tool (find drug concepts, look up medications, search formulations) but does not explain when not to use it or suggest alternative tools for specific needs, such as getting detailed concept information via rxnorm_concept.

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 behavioral context: the tool is 'guidance only,' it doesn't ship historical snapshots for most terminologies, and it points to the publisher's changelog for authoritative diffs. It also mentions 'bundled_versions' to indicate available versions on the server.

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 clear sections and examples, but it is somewhat verbose. Every sentence adds value, but it could be slightly more concise without losing clarity. Front-loading the main purpose is effective.

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

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

Given the complexity of supporting multiple terminologies with different behaviors, the description is thorough. It covers edge cases, explains the tool's limitations, and provides specific usage guidance. The presence of an output schema supports completeness by not requiring the description to explain return values.

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

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

Schema coverage is 100%, but the description adds meaning beyond the schema: it explains the behavior when from_version or to_version is omitted, and provides special instructions for the terminology parameter when dealing with ICD-10 vs ICD-11. This enriches the agent's understanding of how each parameter affects the output.

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 'Report what diff data is available between two versions of a terminology,' specifying the verb (report) and the resource (terminology diff). It distinguishes itself from the sibling tool 'map_icd10_to_icd11' by explaining that for ICD-10 vs ICD-11 it provides a cross-revision summary, while for others it's guidance only.

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

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

The description explicitly states when to use the tool (for checking available diff data) and when not to use it (for actual diffs of frequently changing terminologies, the publisher's changelog is authoritative). It provides usage examples, such as using terminology='icd10' with no to_version for cross-revision summary, and explains the limitations as a metadata layer.

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 readOnly, openWorld, and idempotent. Description adds transparency by noting that the ICD-10→ICD-11 version is read live while others are static metadata, and describes the output content (8 terminologies). 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 well-structured with a clear first sentence, followed by bullet-point use cases. It is not overly long for the information provided; every sentence adds 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?

Given the simple input (one optional param) and presence of an output schema, the description fully covers what the tool does, its two data sources, and its utility. No gaps remain.

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

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

Schema coverage is 100% and the parameter is described both there and in the description. The description restates the filtering behavior and the number of entries (8), which adds minimal value over the schema's 'Omit to return all 8'.

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 lists version metadata for all terminologies, using specific fields (version, release date, publisher, etc.). It distinguishes from siblings—none of which seem to list versions—and is not a tautology.

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?

Description provides three explicit use cases for pipeline maintainers and explains when to use the optional 'terminology' parameter. It lacks explicit when-not-to-use guidance, but no sibling tool serves the same purpose, so it's still clear.

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

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

Annotations indicate readOnlyHint=true, idempotentHint=true, destructiveHint=false. Description adds context: parallel validation, wall time scaling, worst-case latency (~10s), and semantics of null active status per terminology. 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?

Well-structured, front-loaded with purpose, then details on return values, then constraints. Every sentence adds value, no redundancy.

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

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

Given complexity (multi-terminology validation), description fully covers input schema, return fields, error handling, performance, and constraints. Complete without needing 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 description coverage is 100%, but description adds value by explaining why terminology is required, the cap of 50, and accepted values. Reiterates and clarifies beyond 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 validates a mixed batch of medical codes against their source terminologies. It specifies input (code and terminology pairs) and output fields, distinguishing it from sibling lookup/search tools by focusing on batch validation.

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

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

Explicitly mentions use case (retrospective analysis of legacy databases), explains why auto-detection isn't supported (category codes in multiple terminologies), specifies hard cap of 50 codes, and lists accepted terminology values. Provides clear guidance on when to use this tool versus alternatives.

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