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

Annotations declare a destructive, open-world, non-idempotent write; the description goes well beyond that by disclosing the authorization prerequisite (`send_internal` capability), the sandbox restriction on external delivery, and the exact non-error outcome codes `draft_pending_approval` and `blocked` with its matched rule. Telling the agent these are expected governed outcomes rather than failures is exactly the context annotations cannot supply, and it prevents erroneous retry loops.

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: scope, governed outcomes, then prerequisite. The outcome codes are front-loaded where an agent will hit them, and the 'EXPECTED ... not errors' clause is a deliberate disambiguation rather than filler. Nothing is redundant with 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?

There is no output schema, and the description compensates by naming the return states an agent must branch on, plus the capability gate that determines whether the call is legal at all. For an eight-parameter, open-world destructive write against a policy engine, the description supplies everything needed to call it and interpret the result.

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 100% and every parameter already carries its own description, including the mode enum and header allowlist. The description adds no syntax, formatting, or constraint detail beyond the schema; it only confirms the send/reply behavior that `thread_id` already documents. Baseline 3 applies.

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 opening clause names a specific verb pair and resource — 'Send or reply from a scoped inbox' — and immediately bounds it with 'subject to send policy'. Combined with the title, an agent knows this is the only delivery tool among a set of read/audit siblings, and the reply-vs-fresh distinction is carried by 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?

It clearly states the context in which the tool applies (scoped inbox, send policy, `send_internal` capability required) and pre-empts the two governed outcomes an agent will actually encounter. It stops short of routing the agent to its governance siblings — e.g. that a sandbox token blocked from external delivery should use `mailbuttons_request_promotion` or `mailbuttons_propose_sender` — so the when-not path is described but the alternative is not named.

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