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

Goes well beyond the annotations (readOnlyHint=false, destructiveHint=true): it discloses the two-step confirmation gate, that the first call sends nothing, the exact return payload (summary + confirmation_token), and the sign-in prerequisite including what happens when unauthenticated. That is exactly the behavioral context an agent needs before calling a destructive tool.

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?

Three tight sentences with zero waste: what it does first, what it returns second, the confirmation gate third, and auth last. The most important constraint (nothing is sent until confirm) is front-loaded in the second sentence.

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?

Output schema exists and the description still names the two key return values, auth requirements are spelled out, and the destructive action is explicitly gated by confirm. Nothing an agent needs in order to call this 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 coverage is 60% and the description only adds meaning for the recipient generally ('someone, usually the customer's client'). recipient_name and recipient_business are undocumented in both schema and description, and include_branding's default is only in the schema. Marginal value over the schema, so the baseline 3 fits.

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 and resource: prepares emailing a saved quote's public link to a recipient. The parenthetical '(usually the customer's client)' and the mention of the public link let an agent distinguish it from share_quote or convert_quote_to_order without opening 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?

Clearly explains the two-step flow: this call only prepares and returns a summary plus confirmation_token, and nothing is sent until confirm is called after the customer agrees. It names the sibling confirm and the condition that selects it. It doesn't contrast with share_quote, which is the closest alternative for distributing a quote.

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