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

Annotations already declare destructiveHint=true and idempotentHint=false; the description usefully corroborates this ('cannot be undone') and adds non-annotation facts: draft spends tokens, send requires a connected Gmail/Outlook, and the timeout/retry recovery path. That is real added value beyond the safety flags, but it does not describe what a send actually returns or how the history cursor behaves over time.

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 purpose, then action semantics, then the safety procedure and sibling exclusion — nothing is decorative. It is a dense single paragraph with several interleaved policies (auth, retry, approval), which would scan better as discrete clauses, but no sentence is filler.

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?

An output schema exists, so return shapes need no explanation; annotations carry the risk profile and the description supplies the operational layer agents actually need (token cost, mailbox prerequisite, irreversibility, retry path, next step). For an 8-param, 5-action mutation tool this is complete.

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 per-parameter 'For send:'/'For record_sent:' hints already do the heavy lifting and the baseline would be 3. The description adds a genuine cross-parameter constraint the schema cannot express: the subject and body passed to send must be the exact text the user approved, and 'to' is the address the user supplied.

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?

Starts with a specific verb+resource ('Follow up on applications that have gone quiet') and then enumerates each of the five action modes with what each returns or does. It explicitly carves out the sibling boundary: 'Do not use it to answer an email an employer sent; use getmattered_reply_to_email.'

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 explicit when-to-use per action, an exclusion for the nearest sibling, a required approval sequence for send ('show the exact subject and text first, then send it only after they say yes'), a fallback path when no mailbox is connected, and a recovery rule ('On a timeout or an error from send, call action history before sending again'). Little 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.