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

Annotations already declare destructiveHint=false and idempotentHint=true, so the safety profile is covered. The description reinforces non-persistence with 'without publishing', but it does not explain readOnlyHint=false, i.e. that this preview invokes AI generation and therefore is not a free/no-side-effect read, nor does it mention rate or cost implications.

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?

A single front-loaded sentence that communicates the core action and the key constraint ('without publishing') with no filler. It is appropriately sized for what it attempts, even if it omits detail.

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 three-parameter tool with no output schema, zero schema description coverage, and a non-read-only hint, one sentence is not enough. It never says what the preview returns, what email_type values are valid, or what request_id/idempotency_key are for.

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 0% and three parameters, the description must carry parameter meaning and does not. email_type is self-describing by name, but request_id and idempotency_key are entirely unexplained, including the expected email_type pattern/format.

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 names a specific verb (preview) and resource (AI sample customization for an email), so the basic operation is understandable. However, it does not distinguish this tool from the closely named sibling yardstick_email_templates_preview, leaving an agent unable to tell which preview variant to pick without opening both 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 phrase 'without publishing' implies a contrast with publish, but there is no explicit when-to-use statement, no mention of prerequisites, and no routing to alternatives such as email_templates_preview or email_templates_create. The agent must infer the selection criteria.

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