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

Annotations already declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, so the safety profile is covered. The description adds that the target must be an 'immutable version,' which clarifies the required kind of version_id, but it does not state what happens to the current template or whether published templates are affected. This is minimal but acceptable given the 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 a single front-loaded sentence with no filler. It states the action, resource, and target immediately and is appropriately sized for a simple rollback operation.

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 destructive rollback with 0% schema coverage and no output schema, the description is too thin. It omits how to obtain an immutable version_id, what the email_type enum represents, and what side effects occur beyond the generic destructiveHint. A reference to email_template_versions_list or the publish/update workflow would make it complete.

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%, and the description does not explain email_type, version_id, request_id, or idempotency_key. It only loosely maps 'candidate email template' to email_type and 'immutable version' to version_id. An agent cannot determine what the email_type enum values mean or how version_id is obtained.

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 uses a specific action verb ('rollback') with a clear resource ('candidate email template') and a clear target ('immutable version'). This is enough to distinguish it from sibling template tools such as list, read, publish, validate, and update, so an agent can select it without inspecting the 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?

No guidance is provided about when to roll back versus updating, publishing, or validating a template. There are no prerequisites, exclusions, or references to alternatives like email_template_versions_list for finding the version_id. The intended context is only implied by the operation name.

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