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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so the safety profile is covered by structured data. The description adds the endpoint and the fact that this is legal reference data, but says nothing about the shape of the returned records (code/name pairs) beyond the schema's hint that names may be localized.

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?

Two compact sentences with zero filler: purpose and downstream usage are front-loaded, and the raw endpoint is appended as a trailing identifier. Nothing is redundant.

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 zero-required-param lookup with full schema coverage and no output schema, the description covers purpose and the consuming tool, which is enough to call it correctly. A brief note on what a returned reason record contains would close the last gap, since there is no output schema to fall back on.

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% and the single `language` parameter carries its own enum and explanation (bg default, en where available), so the schema does the heavy lifting. The description adds nothing about the parameter, which is the expected baseline for a one-param tool with full schema coverage.

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 identifies the resource precisely (legal reasons for issuing a document without VAT) and the endpoint GET /invoices/without-vat-reasons, which tells an agent this is a reference-data lookup. It is distinguishable from most siblings, though it does not explicitly contrast with the other list_* enumeration tools (invoice_types, payment_methods, item_units).

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?

It explicitly states the downstream use: pick one as vat_exemption_reason in invbg_create_invoice, which is exactly the when-to-use context an agent needs. There are no stated exclusions or prerequisites, but for a pure enumeration tool that is a minor gap.

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