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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so the description's added value comes from behavior beyond that: sorting semantics for `nur_offen` ('sortiert nach Alter der Überfälligkeit') and the downstream-handling constraint that internal UUIDs must only be passed between tools and never recited to humans ('einen Menschen niemals bitten, eine UUID einzugeben oder zu wiederholen'). Both are genuinely informative and consistent with 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?

Three sentences with zero waste: core function first, then usage guidance, then a compact behavioral rule. The UUID constraint is compressed into a single imperative ('ausschließlich selbst für Folgewerkzeuge verwenden; einen Menschen niemals bitten...'), so every sentence earns its 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?

For a read-only search tool with all-optional parameters and no output schema, the description compensates well by listing the returned fields and adding the UUID-handling rule that addresses a real human-in-the-loop concern. Minor gaps: it does not route explicitly to rechnung_ansehen for single-invoice detail and does not mention the default/grenze of anzahl, though the schema covers both.

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?

All 5 parameters are described in the schema (100% coverage), so the baseline of 3 applies. The description adds only marginal interpretive value by framing `nur_offen` as the canonical entry point for open items; it does not clarify bis, von, anzahl, or nur_ueberfaellig beyond what the schema already states.

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: 'Listet Rechnungen mit Nummer, Kunde, Betrag, Status und Fälligkeit' — it states exactly what is listed and which fields are returned. This distinguishes it from siblings like rechnung_ansehen (view single), rechnung_anlegen (create), and rechnung_versenden (send) without opening their schemas.

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 actionable routing context: 'Mit `nur_offen` die unbezahlten ... das ist der übliche Einstieg für offene Posten' signals the standard entry point for open-items work and how to invoke it. However, it does not explicitly name alternatives or exclusion conditions (e.g., when to use rechnung_ansehen for a single invoice instead), so the routing is implied rather than exhaustive.

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