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

Annotations already declare destructiveHint/idempotentHint, but the description adds substantial context beyond them: the delete happens 'at once, with no approval', the template reverts to Gemmein's default design, Live's copy is unaffected because go-live/promote never remove templates, and the action is recorded on the founder's Logs. This discloses effect, reversibility, and blast radius.

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?

Front-loads the core action and stays information-dense despite em-dash-heavy prose. The inline enum list is redundant with the schema and slightly inflates length, but no sentence is purely 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 one-parameter destructive tool with annotations and no output schema, the description covers environment isolation, immediacy, resulting state, reversibility, and audit logging. Nothing an agent needs to invoke it correctly is missing.

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 0%, but the single parameter is an enum whose eight values are restated verbatim in the description, adding no meaning beyond the schema. The description does clarify that 'name' selects the template kind, but nothing about selection criteria or defaults is added.

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 a specific verb (deletes) and resource (Development's email templates), enumerates the affected template kinds, and explicitly scopes it to the Development environment versus Live. An agent can distinguish it from put_email_template and the live_* siblings without opening a schema.

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?

Gives a clear environment condition (Development only, never Live) and names put_email_template as the inverse operation for re-saving. It does not explicitly state prerequisites or when-not to use it beyond the Live exclusion, but the routing signal is clear.

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