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

Annotations only provide destructiveHint=true; the description goes well beyond that by disclosing that the reversal is reported to NAV, cannot be undone, leaves the original in the books, and must not be retried. These are consequential traits not derivable from the structured fields.

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?

Front-loads the core action and fiscal consequence, then the prerequisite, then the retry policy; every sentence carries information. Minor redundancy in the title/description overlap and the trailing internal action tag, but nothing wasteful enough to penalize heavily.

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 an irreversible fiscal mutation with no output schema, the description covers consequences, prerequisites, and a verification path. It stops short of saying what the response contains (e.g. the new reversal invoice number), which would help an agent confirm success.

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 baseline is 3, but the description adds a real constraint beyond the schema: the invoice_number must belong to a real/issued invoice, not an arbitrary string. The other parameters (reason, e_invoice, issue_date) are left to the schema.

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 (ISSUES a reversal/storno invoice) and the exact resource/effect (cancels one issued invoice, original stays in the books). It is easily separable from siblings like szamlazz_create_invoice, szamlazz_delete_proforma, and szamlazz_reverse_receipt.

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?

Explicitly conditions use (requires the number of a real invoice) and gives a when-not/alternative path: never retry, and verify with szamlazz_get_invoice when the result is unclear. This is exactly the kind of routing an agent needs for an irreversible fiscal operation.

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