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

The annotations only say readOnlyHint=false and destructiveHint=false; the description goes well beyond by disclosing irreversibility ('Cannot be undone'), where the reason is rendered ('at the top of the document'), failure cases, the per-call confirmation behavior, the outbound/other-people effect backing openWorldHint=true, and the required Cotlet API key scope. That is exactly the additional behavioral context annotations cannot carry.

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?

Purpose is front-loaded and every sentence carries operational information, but the confirmation idea is stated twice ('By default you confirm each call...' and 'Reaches other people: confirm with the user before each call'), which could be merged.

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 two-parameter, no-output-schema mutation, the description covers what changes, irreversibility, the eligibility edge cases, confirmation policy, and credential requirements. Nothing an agent needs to decide whether and how to call it is missing.

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 coverage is 100%, so baseline is 3, but the description adds meaning for cancel_reason ('records the reason at the top of the document') beyond the schema's 'Reason shown on the cancelled document.' It adds nothing for cancel_invoice_id beyond the schema's own 'from list_invoices' hint.

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?

Specific verb + resource + required input: 'Cancel an issued invoice with a reason.' It also pins down scope (issued invoices only, receipts excluded), which separates it from sibling reads like fakturownia_get_invoice_list / fakturownia_get_invoice and from non-cancel mutations like fakturownia_mark_invoice_paid.

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 real preconditions and exclusions: the newest document in the list cannot be cancelled (delete it in the app instead) and receipts cannot be cancelled, plus a confirmation policy. It does not name a sibling tool as the alternative, though the schema's 'Invoice ID from list_invoices' partially covers the lookup path.

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