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

Annotations only declare destructive/idempotent/not-readOnly; the description goes well beyond them by naming the required auth scope (inbox_update), spelling out which rows are destroyed ('Addresses omitted from emails are removed'), and documenting two concrete failure modes with status codes (400 forwarding_not_verified, 409 forwarding_limit including pending rows in the count). It also discloses that forwarding consumes the send path and monthly quota, which is non-obvious side-effect context an agent cannot get from structured fields.

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 front-loaded with the action, then constraints, then errors, then return/quota notes — each sentence carries a distinct fact. The one throwaway is the restatement of required inputs already fully enumerated in the schema.

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, idempotent set-replacement tool this covers everything an agent needs: permissions, verified-only precondition, removal semantics for omitted addresses, both documented error codes, and the quota side effect. An output schema exists, yet the brief return description ('destinations, unverified') is a useful pointer rather than padding.

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 100%, so the baseline is 3, but the description adds meaning the schema lacks: the count limit of 5 destinations is measured including pending rows, and an unverified member of emails yields a specific 400 code. The 'Inputs: inbox_id (required), emails (required array)' line is redundant with the schema but harmless.

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 first sentence states a specific verb and resource ('keep only some already-verified external addresses on an inbox') and the later sentence 'Addresses omitted from emails are removed' pins down replace-set semantics rather than append. Combined with 'Each address must already be verified' and 'Does not accept or return a confirmation code', an agent can tell this apart from the request/remove/list forwarding siblings without opening a 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 establishes the clear context for use (prune to a subset of already-verified destinations) and a de facto when-not via 'Pending addresses are left as they are' and the 400 forwarding_not_verified path. It stops short of naming the alternative sibling to call when an address is not yet verified (e.g. cooper_request_forwarding), so the routing decision is inferred rather than spelled out.

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