outlook_send_draft

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation risk is communicated structurally and the description does not contradict it. However, the description adds nothing about the irreversible nature of sending, whether the draft is consumed/removed afterward, or what happens if draft_id is stale — meaningful context for a send operation that would have earned a higher score.

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?

One sentence, verb-first, with the workflow hint in parentheses so it can be skipped by an agent that already knows the pattern. Every clause earns its place with no preamble.

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 one-parameter tool with annotations covering the safety profile and no output schema, the essentials are present. Still missing is post-send behavior (does the draft disappear from outlook_list_drafts?) and failure modes for an invalid or already-sent draft_id, which matter for a destructive action.

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?

The single draft_id parameter has 0% schema description coverage, so the description carries the burden. 'Existing draft' does convey that the id must reference a pre-created draft, and the outlook_create_draft pairing hints at provenance, but it never says how to obtain a valid draft_id (e.g. via outlook_list_drafts) or what format it takes.

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: 'Send an existing draft'. The qualifier 'existing' implicitly separates it from outlook_send_message and outlook_send_with_attachments, which compose new mail, but the siblings are never named so the agent must infer the distinction.

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 parenthetical gives a concrete workflow: pair with outlook_create_draft for a human-review send flow, which tells the agent this is the second half of a two-step pattern. It stops short of an explicit exclusion (e.g. 'use outlook_send_message instead when no draft exists'), so the guidance is clear context rather than full when/when-not routing.

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