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

Annotations declare readOnlyHint=true and idempotentHint=true, which would otherwise look odd for a tool named 'create_'. The description resolves this by explaining that the actual document is assembled and rendered in the browser (style, colour, logo, A4 PDF download/print), so nothing is persisted server-side. It also discloses the VAT arithmetic performed (27/18/5%, AAM, TAM, reverse taxation) and explicitly states 'Nem számla', ruling out an invoice-issuing side effect.

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 in the first clause, followed by the document-type enumeration that maps to the enum, then the processing detail and a constraint. The list of document kinds is long but each element earns its place by mirroring the required `kind` values; there is little filler.

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 16-parameter tool with nested client/issuer/items objects and no output schema, the description supplies the missing high-level context: what is generated, where, how totals are computed, and the negative constraint that it is not an invoice. The only real omission is that the return value is never described explicitly as a URL/link the caller must surface to the user.

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 94%, so the schema already carries most parameter meaning and the baseline of 3 applies. The description adds some value by explaining that item lines are aggregated into net/VAT/gross totals with specific VAT regimes, but it does not explain which parameter groups apply to which `kind` (e.g. invoices only for fizetesi-emlekezteto, handover_items only for atadas-atveteli), which is where an agent would most need guidance.

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 states concretely what the tool produces (a prefilled link to a browser-based document generator) and enumerates the eight document kinds matching the `kind` enum, so an agent knows exactly what it gets. It does not differentiate against near siblings such as create_price_list or draft_contract, which is the only gap.

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?

Usage is implied through the downstream flow ('Ott a felhasználó stílust, színt, logót választ... PDF-et tölt le vagy nyomtat'), which tells the agent this is step one of a two-step user-driven process. There is a real content rule ('Csak a felhasználótól kapott adatokat add meg, árat ne találj ki'), but no explicit when-to-use / when-not versus the quoting and contract-drafting siblings.

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