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 value beyond that by guaranteeing 'versendet NIEMALS etwas' and 'verändert KEINE Daten — auch dann nicht, wenn Vollautonomie aktiv ist', which covers autonomous execution edge cases. It also discloses a short-lived protected draft PDF, a behavioral trait not present in the annotations. No contradiction.

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

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

The description is dense but every sentence earns its place: core purpose, inspection scope, negative guarantees, usage triggers, and input workflow. It is front-loaded with the read-only guarantee, then progressively adds details. The length is justified by the need to prevent accidental sends and to state safety guarantees explicitly.

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 with a single required parameter, no output schema, and rich annotations, the description covers the full call precondition, the complete inspection scope, and the safety profile. An agent can correctly select and invoke this tool without missing critical context. The only minor omission is exact return format, but that is not required given no 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%, so the schema already fully documents rechnung_id as the internal ID from rechnungen_suchen, to be passed between tools and never typed by the human. The description repeats this same guidance without adding new semantic details such as format or examples. Since the schema carries the burden, baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Prüft garantiert nur lesend') and a concrete resource ('den vollständigen Rechnungsentwurf vor dem E-Mail-Versand'), enumerating all inspected fields. It explicitly differentiates itself from siblings by listing what it never does (send, assign invoice number, freeze PDF, create release) and points to rechnungen_suchen for ID resolution. This clearly distinguishes it from rechnung_versenden and rechnung_ansehen.

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

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

The description gives explicit trigger phrases ('zeig mir die Versandvorschau', 'welcher Absender wird benutzt?', 'prüfe vor dem Versand') and mandates this tool for those queries. It also supplies an explicit workflow precondition: resolve rechnung_id via rechnungen_suchen and never ask the human for the UUID. This is strong when-to-use guidance with alternatives implicitly excluded.

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