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

The annotations declare destructiveHint=false, i.e. merely additive updates, but the description states 'the cancellation cannot be undone' and that the original's 'booking is reversed' and its number 'stays blocked even if you change the number range'. This describes an irreversible, status-altering mutation, directly contradicting the non-destructive annotation, so per the rubric this is scored 1.

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 core action and its irreversibility are front-loaded, and most sentences carry real operational information (Storno stamp, blocked number, role limits, confirmation default). It is a bit long and the trailing 'Needs the user's Cotlet API key with access to this app' is generic boilerplate, but overall it is dense rather than padded.

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?

With one parameter, no output schema, and existing annotations, the description covers everything an agent needs: irreversibility, the Storno mechanics, prerequisite payment deletion, role restrictions, the sibling to use instead, the per-call confirmation requirement, and the external-reaching nature of the call.

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?

There is a single parameter with 100% schema description coverage ('Document ID from list_documents or create_invoice'), so the schema already carries the semantics. The description adds no further parameter detail, which is the expected baseline of 3 when the schema does the work.

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?

States a specific verb (cancel/stornieren) applied to a specific resource (a finalised invoice) and distinguishes itself from the sibling create_invoice, which it names explicitly for the corrected invoice. An agent can separate this from other lexware-office invoice tools without opening any schema.

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?

Gives concrete prerequisites and conditions: the invoice must be finalised, a paid invoice requires its payment be deleted first, and the restricted 'Belege, Kontakte & Produkte' role cannot cancel paid invoices. It also names the alternative (create_invoice) for issuing the corrected document, so when-to-use and when-not-to-use are both covered.

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