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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write, so the safety profile is covered. The description adds genuinely new operational detail: the supported merge variables ({{first_name}}, {{agent_name}}, {{product}}) and the pipe fallback syntax, which an agent cannot learn from the schema or annotations and which directly affects how the body must be authored.

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?

Two sentences, zero filler. The purpose comes first and the templating rule follows, so the agent gets the most decision-relevant information up front.

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 simple 4-parameter create with annotations covering safety and no output schema, this is adequate but thin: it is silent on the tags and shared parameters beyond the schema, on whether a duplicate title is rejected, and on what the call returns. Nothing an agent strictly needs is missing, but the definition does not go out of its way to be 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 coverage is 75% (title, body, and shared are documented; tags is not), so the baseline would be 3. The description goes beyond the schema by specifying the templating grammar that governs valid body content, which the schema only describes as 'the reply text, up to 8,000 characters.'

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 states a specific verb and resource ('Save a reply') and clarifies the resulting artifact is a team-insertable snippet for the composer. It does not distinguish itself from close siblings like update_saved_reply, render_saved_reply, or delete_saved_reply, so an agent must infer the create-vs-edit boundary from the name alone.

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?

It says what a saved reply is for (composer insertion) but gives no when-to-use guidance, no prerequisites, and never names an alternative such as update_saved_reply for editing or render_saved_reply for previewing. This matches the calibration case of a bare 'update settings' tool, which scored 2.

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