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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=true, and openWorldHint=true, so the safety profile is known. The description adds only a claim that the human sends it themselves, which sits oddly against the destructive annotation, and says nothing about what confirm commits to, whether the letter is charged immediately, or what cancel/undo looks like. It does not strictly contradict the annotations, but it muddies them.

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?

It is short, but both sentences are spent on framing and a redirect to another tool rather than on this tool's action or required inputs. The content is not front-loaded with what the tool does, so brevity here is under-specification rather than conciseness.

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?

An output schema exists, so return values need not be explained, but this is a destructive mutation with two required parameters and an explicit confirmation flag. The definition never explains what confirm or draftId mean, when the destructive write actually occurs, or how it interacts with request_send, leaving an agent without enough to invoke it safely.

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 50%: contentVersion and sendAnotherCopy carry good inline descriptions, but the required 'confirm' boolean and 'draftId' have no schema description at all, and the description mentions neither. With the two required parameters undocumented, the description fails to compensate for the coverage gap, leaving an agent unable to know what confirm authorizes.

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 never states what send_letter itself does. It describes app-wide behavior (a call returns a link, the person sends it themselves) and then tells the caller to invoke request_send, so an agent cannot tell whether send_letter sends, prepares, or aliases another action. The name/title say 'send a letter' but the body redirects elsewhere.

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?

There is a conditional instruction, but it points at a sibling tool (request_send) rather than explaining when to use send_letter or how it differs from request_send, send_postcard, or quote_and_preview_letter. The guidance effectively discourages use of the tool it documents without saying what that tool is for.

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