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

Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds meaningful behavioral/data-scope context beyond that: Germany-only coverage, inclusion of announced future years ('verkündete Folgejahre eingeschlossen'), and the percent unit. It does not disclose return structure or error behavior, but for a simple lookup these are minor gaps given the strong annotation coverage.

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

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

The description is compact, front-loads the geographic restriction, and gives the core definition before supplementary context. The bilingual English translation duplicates the German content and the payer sentence is background rather than call-critical, introducing slight redundancy, but it remains efficient and scannable.

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

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

For a simple read-only lookup with zero required parameters, fully documented optional parameters, and comprehensive annotations, the description covers the essential facts: what is returned (a percentage rate), the temporal and geographic scope, and the legal context. Without an output schema, a description of the exact response shape would be nice, but the expected value is simple enough that the gap is minor.

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%; jahr, datum, and bestandteil each have descriptions covering ranges, formats, defaults, and allowed values. The tool description adds no parameter-level detail, so the schema carries the full burden, which fits the baseline-3 case exactly.

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 names the resource – the Künstlersozialabgabe rate in percent per calendar year since 2015 – and scopes it to Germany ('Nur Deutschland'). It does not state an explicit verb like 'liefert' or 'returns', and it does not explicitly distinguish itself from siblings such as hr_beitragssaetze or hr_ausgleichsabgabe, though the specific levy makes the purpose reasonably unambiguous.

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

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

The description provides contextual signals that help an agent infer when to use the tool (needing the artists' social security levy rate in Germany for a given year) but never states explicit when-to-use versus alternative conditions. It names no sibling tools or exclusions, leaving usage guidance implied rather than explicit.

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