Microsoft 365 MCP Server

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

Adds substantial behavioral context beyond annotations: RFC 2822 replyTo handling logic, Sent Items folder side effect, HTTP 400 error condition for invalid parameter combinations, and base64 encoding requirements for MIME. Aligns with destructiveHint=true (mutation) by describing the sending action.

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?

Contains valuable information but is somewhat verbose with multiple sections (JSON rules, MIME rules, alternatives, TIP). Structure is logical but could be more front-loaded; the TIP section at the end repeats information from earlier bullets. Every sentence provides value, but tighter integration would improve scannability.

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 complex dual-format operation with nested parameters and no output schema, description adequately covers format selection, validation constraints, RFC-compliant routing behavior, and storage side effects. Missing explicit description of return values or success indicators, but annotations cover the safety profile.

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 has 75% coverage with complex nesting. Description adds critical constraint that 'comment' and 'body' are mutually exclusive in JSON mode (HTTP 400 if both provided), and clarifies that 'comment' represents the reply text. Compensates for complexity of the nested Message object structure within the body parameter.

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?

Opens with specific verb ('Reply to all recipients') and resource ('message'), explicitly distinguishing from sibling 'reply-mail-message' by emphasizing 'all recipients'. Also distinguishes from 'create-reply-all-draft' by noting immediate sending to Sent Items vs. draft creation.

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 references sibling alternative 'create a draft to reply-all... and send it later'. Details when to use JSON vs. MIME format and warns about HTTP 400 error conditions. Could more explicitly contrast with 'forward-mail-message' or single-reply scenarios.

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