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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description aligns with them ('Der Lauf bleibt kostenfrei und der Brief bleibt ein Entwurf'), so no contradiction. The description adds substantial behavior beyond annotations: data substitution (real partner sender data, fictional recipient and sample body), fidelity guarantees ('dieselbe Aufloesung und denselben Composer wie ein echter Versand'), output format (inline PNG), the page-2-only-for-continuationHeader condition, and the precise claim that sampleVariant empty produces exactly the picture the dashboard shows.

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 description is long and bilingual, but every clause earns its place and it is well structured: purpose first, then fidelity, output mechanics, the sampleVariant edge case, concrete use cases, and finally the cost/draft guarantee. The EN mirror duplicates the DE text, which is conventional for this audience, and the density justifies the length given the tool's complexity.

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 9-parameter tool with nested objects and no output schema, the description covers the essential call-relevant behaviors: how to select input (saved or inline design), rendering fidelity, return format (inline PNG), paging rules, and sample-variant effects. The remaining gaps are minor but real: the resolution parameter semantics and an explicit statement of how this tool differs from letter_preview.

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?

With schema description coverage at only 22%, the description must compensate, and it partially does: it explains the design/designId distinction ('gespeichertes oder inline uebergebenes'), the page-2 trigger ('Seite 2 nur fuer continuationHeader'), and the sampleVariant empty behavior ('Kopf und Fuss stehen echt, die Textflaeche bleibt frei'). However, the resolution parameter (thumb vs full) is not explained in either the schema or the description, and sampleSubject, reference, and reasoning also receive no semantic 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 a specific verb and resource: 'Rendert ein gespeichertes oder inline uebergebenes Briefdesign' (renders a saved or inline letter design), with explicit scope of schemaVersion 1 or 2. The focus on rendering the *design* rather than a concrete letter distinguishes it from siblings like letter_preview, letter_design_save, and letter_design_delete without needing to open their schemas.

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?

The description gives clear usage context: 'So siehst du vorab, wie Kuendigung, Rechnung, Mahnung, Angebot, Vertrag und Behoerdenpost auf diesem Briefpapier aussehen' tells the agent when a preview is useful, and 'Der Lauf bleibt kostenfrei und der Brief bleibt ein Entwurf' signals a safe, pre-send scenario. However, it never names alternatives or states when-not-to-use, and it offers no explicit differentiation from the sibling letter_preview, which is the obvious competing choice.

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