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

Annotations only establish that this is a write operation (readOnlyHint=false) that is non-destructive. The description adds substantial behavioral context: drafts are unusable until release, the response includes the review link, letterhead/brand stay an external layer resolved only at preview/send, coverTemplateId pins the exact released version with explicit inheritance semantics, and designId is deprecated in favor of documentKind. 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 description is well front-loaded (core action in the first sentence) and topically organized, but nearly every sentence is duplicated in German and English, roughly halving information density. The tool-discovery note ('If the tool is missing, search for the exact technical name template_save') is off-topic for invoking the tool correctly and adds noise.

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 15-parameter tool with nested objects and no output schema, the description is unusually thorough: it covers version semantics, release gating, cover-template pinning and inheritance, content exclusivity, typed merge fields, and pre-save verification steps. The main gap is the response shape beyond the single mention of the review link, which is the agent's only handle on the result.

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 93%, so the baseline of 3 applies—the schema already documents every parameter including enums, limits, deprecation notes, and the contentTemplate OR blocksTemplate exclusivity. The description adds only marginal cross-parameter emphasis (merge-field typing and rowsFrom binding), most of which repeats what the schema's own property descriptions already state.

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?

States the exact operation with specific verbs—'writes a template as a DRAFT' / 'Verfasst eine Vorlage als ENTWURF'—and the resource (a template draft/version). It differentiates itself from siblings like template_release, template_get, template_archive, and template_draft_discard, and even clarifies the two internal modes: omitted templateId creates a new template, while provided templateId creates a new draft version.

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?

Provides explicit workflow context: copy a standard template with template_get, render and compare with letter_preview before saving, and preview standalone forms with a design in documentMode 'form' first. It also explains the draft-then-release sequence, but never explicitly names exclusions or an alternative tool to choose instead, so the guidance stops short of full when-not-to-use coverage.

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