outlook-mcp

outlook_send_message

Destructive

Send an email immediately without human review, with CC/BCC, HTML or Markdown body support and reply-to routing; use draft workflows when review is required.

Instructions

Send an email immediately, no human review.

For human-review workflows use outlook_create_draft + outlook_send_draft instead. For replying to an existing message use outlook_reply; for calendar invites use outlook_rsvp. Pass reply_to to route recipient replies to a different address (e.g. a shared team alias).

Input Schema

Name	Required	Default
`cc`	No
`to`	Yes
`bcc`	No
`body`	Yes
`is_html`	No
`subject`	Yes
`reply_to`	No
`importance`	No	normal
`is_markdown`	No
`request_read_receipt`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed23 schema fields changedv1.30.2Oct 30, 2026
- removedInput schema / properties / bcc / anyOf
```
Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / bcc / default
```
Removed value: -null
```
- addedInput schema / properties / bcc / items
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / bcc / title
```
Removed value: -"Bcc"
```
- addedInput schema / properties / bcc / type
```
Added value: +"array"
```
- removedInput schema / properties / body / title
```
Removed value: -"Body"
```
- removedInput schema / properties / cc / anyOf
```
Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / cc / default
```
Removed value: -null
```
- addedInput schema / properties / cc / items
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / cc / title
```
Removed value: -"Cc"
```
- addedInput schema / properties / cc / type
```
Added value: +"array"
```
- removedInput schema / properties / importance / title
```
Removed value: -"Importance"
```
- removedInput schema / properties / is_html / title
```
Removed value: -"Is Html"
```
- removedInput schema / properties / is_markdown / title
```
Removed value: -"Is Markdown"
```
- removedInput schema / properties / reply_to / anyOf
```
Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]
```
- removedInput schema / properties / reply_to / default
```
Removed value: -null
```
- addedInput schema / properties / reply_to / items
```
Added value: +{
+  "type": "string"
+}
```
- removedInput schema / properties / reply_to / title
```
Removed value: -"Reply To"
```
- addedInput schema / properties / reply_to / type
```
Added value: +"array"
```
- removedInput schema / properties / request_read_receipt / title
```
Removed value: -"Request Read Receipt"
```
- removedInput schema / properties / subject / title
```
Removed value: -"Subject"
```
- removedInput schema / properties / to / title
```
Removed value: -"To"
```
- removedInput schema / title
```
Removed value: -"outlook_send_messageArguments"
```

Changed1 schema field changedv1.28.0Oct 25, 2026

addedInput schema / properties / is_markdown

Added value: +{
+  "default": false,
+  "title": "Is Markdown",
+  "type": "boolean"
+}

Changed1 schema field changedv1.19.0Sep 9, 2026

removedInput schema / properties / sensitivity

Removed value: -{
-  "default": "normal",
-  "title": "Sensitivity",
-  "type": "string"
-}

Addedv1.14.0Sep 7, 2026
Removedv1.12.0Jul 19, 2026
First observedv1.11.0Jun 10, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, and the description reinforces that with "immediately, no human review" — meaningful because it tells the agent the commit is irreversible and unrecoverable. It doesn't note the absence of an attachment mechanism (which forces an agent to outlook_send_with_attachments) or any send rate/quota limits, so it stops just short of full coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, none wasted: the commit semantics lead, alternatives follow, and the parameter note closes. Every sentence conveys a routing or safety decision the agent must make before calling.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The safety and routing picture is complete, and no output schema exists so return values need no explanation. However, for a 10-parameter mutation with 0% schema documentation, the description should at least flag that attachments require outlook_send_with_attachments and give minimal guidance on body formatting flags.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% across 10 parameters, so the description carries the entire burden — yet it only explains reply_to (routing replies to a shared alias, a genuinely useful clarification). To, cc, bcc, is_html, is_markdown, importance, and request_read_receipt are left completely unexplained, including the format-selection ambiguity between is_html and is_markdown.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Send an email immediately, no human review" gives a specific verb (send), resource (email), and execution semantic (immediate, unreviewed). It is immediately distinguishable from the draft-based siblings it names.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes away to alternatives with conditions: human-review workflows → outlook_create_draft + outlook_send_draft; existing threads → outlook_reply; invites → outlook_rsvp. It also disambiguates the sibling outlook_send_draft, which an agent could easily confuse with this tool.

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

Deploy Server

outlook_send_message

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools