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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond that: returned artifacts (inline PNGs, PDF link, designRender), the free-of-charge property, and the stationery-selection behavior (designId or unsaved design). No contradiction with annotations.

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 core German text is front-loaded and functional, with the primary purpose in sentence one and sibling routing in the middle. However, the full bilingual duplication doubles the length, and the closing meta-note about searching for template_save if the client unloaded it is unusual agent-environment noise that doesn't belong in a tool description.

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 7-parameter tool with a nested design object and no output schema, the description covers the essentials: what is rendered, what is returned, how stationery is chosen, form mode, cost, and alternative tools. The main gap is that 'designRender' is listed as an output but never explained, and there is no mention of invalid/unknown templateId handling, though the versionId fallback is documented in the schema.

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 86%, so the schema already documents most parameters. The description adds cross-parameter relationship semantics not present in the schema: designId OR an unsaved design object determines the stationery ('designId oder ein ungespeichertes design bestimmen das Briefpapier'), and documentMode: 'form' maps to standalone forms. This goes beyond individual field descriptions.

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 opens with a specific action ('Rendert eine GESPEICHERTE Vorlage mit Beispielwerten') and names concrete outputs (Inline-PNGs, PDF-Link, designRender). It emphasizes 'stored' template and contrasts with letter_preview for in-progress block layouts, making the tool's scope unmistakable among 70+ siblings.

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 explicitly routes to alternatives with conditions: 'Fuer ein blocks-Layout, das erst im Entstehen ist, nimm letter_preview' and 'Zum Persistieren einer fertigen Version template_save aufrufen'. It also states the cost/inspection context ('kostenfrei und rein zum Ansehen'), so an agent knows this is the right choice for view-only previews.

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