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

Annotations already declare readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the draft is not transmitted, the human sends it, and the tool still works when sending is disabled — all non-obvious operational traits.

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?

Three short sentences, front-loaded with the core action and its key constraint ('without sending'). No filler; each sentence adds distinct information.

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 7-parameter mutation tool with no output schema and sparse schema descriptions, the behavioral side is well covered but the parameter side is essentially absent — an agent gets no guidance on cc/bcc/to arrays or the reply-threading parameter from the description. Adequate but with a clear gap.

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 only 29% (7 params, only mailbox and replyToMessageId documented). With that low coverage the description should compensate, but it mentions no parameters at all — no hint about to/cc/bcc arrays, subject/body limits, or how replyToMessageId changes behavior. The burden is not met.

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 ('Write a draft into the mailbox') and immediately clarifies the key differentiator from send tools: 'without sending it.' An agent can tell this apart from send_outlook_message/send_outlook_reply. It does not, however, name its sibling create_gmail_draft/create_agentmail_draft as the parallel drafts, so sibling differentiation is only partial.

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 description gives one useful usage condition ('Works even when a workspace has switched sending off'), which hints at when to prefer a draft over sending. But it never explicitly names the alternative (send_outlook_message) or states when-not to use this tool, leaving the routing decision largely implicit.

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