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

Annotations already mark the tool as read-only and idempotent, and the description adds meaningful behavioral detail beyond that: it explains the response structure ('focus', 'parents', 'items'), what kinds of content each part contains, and the special no-code behavior of returning the top-level catalog for iterative browsing. This gives an agent a clear mental model of the call's 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 front-loaded with the most important information and clearly structured. It is slightly longer than necessary because the German details are repeated in a condensed English summary, but the bilingual repetition may be intentional and the core behavior remains easy 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?

For an optional-parameter read-only lookup with an output schema, the description is fully sufficient: it explains what the tool returns, how the no-code mode works, and where it fits in the search-to-inspect workflow. No critical information for selecting or calling the tool 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 documents both parameters, including the null/default behavior of 'code' for the top level and 'year' for the latest available year. The description reinforces the no-code behavior but does not need to add much parameter-level meaning; 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 opens with a specific verb and resource — 'Liefert ... alle Angaben zu einem ICD-10-GM-Kode' — and enumerates the exact kinds of data returned: coding flags, inclusions/exclusions, alphabetical index entries, ATC substances, Morbi-RSA groups, and DKR/SEG-4 references. It also differentiates this get tool from search tools by explicitly positioning it as the tool to call after a search or for top-down catalog browsing.

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 usage context: call it after a search to inspect a hit, or call it without a code to browse from the top level. It does not explicitly name the alternative search tools or state when not to use them, but the 'after a search' instruction strongly implies the intended workflow relative to the search siblings.

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