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

Annotations cover only the safety flags (readOnly=false, destructive=false, idempotent=false), and the description adds the substantive side effects: the draft's text is copied to the activity trail, the draft becomes immutable, and the account status transitions to approaching. It also cites the governing rules (CRM-5, CRM-15), which is 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?

Front-loaded with a one-line purpose, then cleanly segmented by SENT/DISCARDED blocks and closed with an 'Effects' summary. The cautionary paragraph about not fabricating a send is slightly discursive, but it is doing real work rather than padding.

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?

The 'Effects' line substitutes well for a missing output schema, and the mutation consequences are fully spelled out. It does not address edge cases an agent may hit, such as what happens if the draft was already recorded sent/discarded (relevant given idempotentHint=false) or what error surfaces when sent_at is omitted on a send.

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 earns more: it clarifies sent_at means when the message actually went rather than when the record was typed (CRM-5), and it gives concrete guidance on rejected_because ('too long, and it opened on us rather than on them' is worth typing and 'no' is not). This is real semantic value beyond the schema's terse property 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?

States a specific verb+resource ('Record that a person sent a draft, or that they rejected it') and explicitly scopes itself apart from the sending action itself ('Sending happens in their mailbox; this records it'), which separates it from siblings like crm_draft_message and crm_update_draft. The two enum branches are named and defined inline.

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?

Gives clear when-to-use conditions for each branch (SENT vs DISCARDED) plus an explicit when-not-to-use guard: 'Never record a send you were told about by nobody... If you did not hear it from your human, ask.' It also implicitly routes the actual send elsewhere rather than through this tool.

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