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

Annotations already declare destructive/non-idempotent/open-world, and the description adds real value on top: the action cannot be undone, it consumes plan sends (quota impact), a verified sender is required, and the backing endpoint is POST /sendmail. These are exactly the traits an agent needs before committing an irreversible write.

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 the irreversible-write warning, then prerequisites, then the endpoint. Dense and mostly waste-free, though 'WRITE, SENDS AN EMAIL NOW AND CANNOT BE UNDONE' partially duplicates the later 'send a single email' phrasing.

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 an irreversible, quota-consuming mutation with no output schema, the description covers safety, quota cost, sender verification, and the confirmation gate. It omits what a successful call returns (message id, send status) and any failure modes such as unverified sender or exhausted plan quota.

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 only 25%, so the description must carry weight. It explains the two highest-risk parameters well (confirm must be true, text_body and/or html_body at least one) and points sender_id at verified senders, but leaves to_name, reply_to, and subject undocumented beyond their obvious names.

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 and resource with tight scope: send a single email to one recipient from a verified sender. The single-recipient, non-contact framing implicitly separates it from the campaign-oriented siblings (send_campaign, send_test_campaign), so an agent can route correctly 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?

Gives an explicit precondition for use: only with the user's explicit go-ahead and confirm must be true. It also clarifies the recipient need not be a contact, removing a common gating assumption. It does not, however, name the alternative tools to use when the intent is a bulk or test send.

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