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

Annotations already convey read-only and idempotent behavior. The description adds value by disclosing the response structure ('items', 'bund', 'focus'), the historical scope since 2014, and the data sources, which go beyond the structured annotation fields. No contradictory behavior is described.

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 and then structured by parameter-dependent scenarios. Every sentence contributes information about output shape or sources, with no filler. It is dense but appropriately sized for a tool with conditional output behavior.

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 retrieval tool with an output schema and annotations covering safety, the description is complete: it explains both invocation modes, the resulting data groups, the historical depth, and the provenance of the data. Nothing that an agent needs to call the tool effectively 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 has 100% description coverage for both parameters, so the baseline is 3. The description goes further by explaining the functional consequence of leaving 'code' empty vs. providing a state abbreviation, which adds meaning beyond the schema's type and default information. Year behavior is left to the schema, but that is acceptable because the schema documents it clearly.

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 verb and resource: it 'liefert' Basisfallwerte gemäß §10 KHEntgG, and details the two main output modes (all states vs. a specific state). It does not explicitly contrast itself with the sibling basisfallwerte_search, so it stops short of full 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?

The description gives clear usage context by explaining what happens with and without a Länderkürzel, effectively telling the agent when to omit or set the code parameter. It does not mention when to prefer basisfallwerte_search or other alternatives, so no explicit exclusions are provided.

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