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

Annotations declare destructive/idempotent/openWorld but say nothing about auth or semantics; the description fills that gap with required scope (message_send or draft_write), the omit-vs-null clearing rules, the send_at unschedule behavior, the immutable reply/forward fields, the reserved scheduled label, and the 409 draft_sending error. That is unusually rich behavioral disclosure beyond the 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?

Usage and the key non-sending constraint are front-loaded, and the enumeration of inputs is dense but each clause carries distinct information (immutability, reserved label, error code). It is a single long paragraph rather than cleanly chunked, which keeps it just short of a 5.

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 14-parameter mutation tool with no output schema, the description covers prerequisites, mutation semantics, immutability limits, the reserved label, the conflict error, and the return value ('Returns the updated draft'). Nothing an agent needs 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 100%, so the baseline is 3, but the description adds meaning the schema does not: 'Omit a field to leave it unchanged,' the general null/empty-list clearing rule, and that send_at null removes both the schedule and the scheduled label. The only reason it is not a 5 is that several per-field clear semantics are already in the schema descriptions.

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 sentence gives a specific verb+resource ('a draft should change before it sends') and immediately distinguishes the tool from its send sibling with 'This call does not send the draft.' An agent can tell this apart from cooper_create_draft, cooper_get_draft, cooper_delete_draft and cooper_send_draft 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?

The first sentence states exactly when to use it ('when a draft should change before it sends') and the exclusion ('does not send the draft') routes the agent away from a wrong choice. It stops short of explicitly naming cooper_send_draft as the alternative for actually sending, so it is clear context rather than a full when/when-not/alternative map.

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