ews_send_message

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

No annotations are provided, so the description carries the whole burden, and it does disclose a significant non-obvious behavior: a required human-in-the-loop preview/confirmation step listing To, CC, BCC, subject, rendered body, and attachments. It does not say what the call returns, what happens on partial delivery, or which account is used by default — and it references attachments even though no attachment parameter exists in the schema, a small misleading note.

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: what it does, when to use it, then the mandatory pre-call workflow. Front-loaded and nothing redundant.

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?

Output schema exists, so return values need not be explained, and the description covers protocol choice plus the confirmation gate. Remaining gaps are the nonexistent attachment parameter it implies and the lack of guidance on multi-account selection via account_id.

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 100%, so all 9 parameters including the body_html/body_text separation and threading headers are already documented in the schema. The description adds no parameter-level meaning beyond naming the preview fields, so baseline 3 applies.

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+resource ('Send email') and pins the transport ('via Exchange Web Services'), which is exactly what separates it from the smtp_send_message and graph_send_message siblings. An agent can route on protocol without opening any 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 selection condition: use this when the Microsoft tenant blocks SMTP and Graph API — i.e. the exact circumstances in which the smtp_ and graph_ siblings fail. It also mandates the operating procedure (full preview, then explicit user confirmation) before invocation.

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