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

The annotations only declare the safety profile (destructive, open-world, idempotent), while the description supplies the outcome semantics an agent actually needs: POSTED means sent, SENDING plus DELIVERY_UNCONFIRMED means it may have gone out and must not be retried by drafting a replacement, and a refused send returns the draft to review with a reason. It also explains that updatedAt must be passed as expectedUpdatedAt, i.e. the call is guarded by an optimistic-concurrency check.

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 action and its approval precondition come first, followed by outcome semantics and the failure path. It is dense with four sentences of edge-case detail, but each sentence carries distinct operational information and nothing is repeated from the schema or annotations.

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, open-world send with only two parameters, the description covers the approval gate, the concurrency contract, the success signal, the ambiguous-failure case with an explicit no-retry rule, and the refusal path. An output schema exists, so return values need no further explanation, and nothing material is missing for correct invocation.

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%, so the description must carry the meaning, and it does the harder half well: it states that the draft's updatedAt is supplied as expectedUpdatedAt, which is not inferable from the schema. draftId is only implied by 'one saved direct-message reply' and gets no explicit statement that it identifies which draft is sent.

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 gives a specific verb and resource ('Send one saved direct-message reply from the writer's own account'), and the qualifier 'direct-message' separates it from the reader-reply siblings such as send_reader_reply_draft. An agent can identify the action and its scope 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?

The precondition is explicit and unusually strict: send 'only after the writer has read and approved its full text and recipient'. It also gives negative guidance in the delivery-uncertain case ('never draft a replacement to retry'). It stops short of naming a sibling alternative for the cases where this tool is wrong, so it is clear context rather than a full when/when-not routing rule.

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