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

Goes well beyond the annotations by declaring there is no outbound channel (CRM-14), that a refused list is checked against the written text at write time, and that the effect is an unsent draft recorded against the contact. What it does not disclose is the failure surface — what an invalid contact_id or a refused-list rejection returns, or whether a duplicate draft is blocked or merely discouraged.

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?

Purpose is front-loaded in the first sentence and the rule blocks are scannable tags (CRM-14, CRM-10, CRM-16). Some redundancy creeps in — 'nothing is sent' is restated three times and the rationale requirement is duplicated in the schema — but on a high-stakes constrained tool most of the prose earns its place.

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?

No output schema exists, but the description supplies what the agent actually needs: the effect of a successful call, the source material allowed for the body, the reviewer-facing purpose of rationale, and the eligibility rules for contact_id. An agent can call this correctly without further context.

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 baseline is 3, but the prose adds real meaning the schema does not: rationale must name the hook or bullet the angle rests on and why this contact rather than another at the account, body carries no signature because it goes from someone else's mailbox, and contact_id must be a named live contact. The channel parameter is left entirely to the schema.

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 names a specific verb and resource — write a message draft to a contact — and immediately bounds the scope with 'for a person to read, edit and send' and 'Nothing is sent.' It is clearly separable from crm_drafts (listing), crm_update_draft (editing), and crm_draft_outcome (recording an outcome).

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?

Explicit preconditions and alternatives are spelled out: read the campaign's claims via crm_get_campaign first, use only record content, check crm_drafts before writing a second message to the same person, and restrict to named live contacts (not gap rows, not departed contacts). Nothing about when-to-use is left to inference.

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