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

Annotations declare a write (readOnlyHint=false, destructiveHint=true), and the description adds genuinely useful context beyond them: nothing is sent, the draft lands in Drafts, and chat shows a card with Open in Outlook. The 'Nothing is sent' reassurance sits in mild tension with destructiveHint=true and could have been reconciled explicitly, but it is clarifying rather than contradictory. Body-style expectations are also disclosed.

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 core action and the no-send guarantee before mode and formatting guidance. Four sentences, all doing work, though the plain-text formatting rules are slightly verbose relative to the routing-critical content.

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, and the description compensates by describing what the agent/user will see (draft in Drafts folder, chat card). Both creation modes and the required body are covered; only the optional addressing and mailbox-selection parameters rely entirely on the schema.

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, and the description does add real value by explaining the two parameter combinations (to/subject/body vs. reply_to_message_id/body with reply_all). However it never addresses cc/bcc/account, leaving the schema to carry those.

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 ('Create a DRAFT in the user's connected Outlook mailbox') and immediately narrows scope by declaring nothing is sent. This clearly separates it from send_outlook_email and create_gmail_draft without needing to inspect schemas.

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?

Explicitly says 'Use this whenever the user wants an email written to someone from their Outlook mailbox,' and breaks the two modes into concrete invocation patterns (new email vs. reply with reply_to_message_id). It stops short of naming the sibling send_outlook_email as the alternative for actually sending, which would make routing fully unambiguous.

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