outlook-mcp

outlook_attach_to_draft

Attach files to an existing Outlook draft, automatically switching to an upload session for files over 3MB. Use it to add local or inline attachments and receive IDs for later removal.

Instructions

Add attachments to an existing draft; auto-switches to upload-session for files >3MB.

attachment_paths resolve inside the configured attachments directory (attachments_dir, an attachments folder in the settings directory by default) — a bare filename is looked up there, and a path outside it is refused. attachments: inline files [{name, content_base64, content_type?}], up to 3MB each. Returns new attachment IDs for later removal via outlook_remove_draft_attachment.

Input Schema

Name	Required	Description	Default
`draft_id`	Yes
`attachments`	No
`attachment_paths`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed12 schema fields changedv1.30.2Oct 30, 2026

removedInput schema / properties / attachment_paths / anyOf

Removed value: -[
-  {
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / attachment_paths / default
```
Removed value: -null
```
addedInput schema / properties / attachment_paths / items
```
Added value: +{
+  "type": "string"
+}
```
removedInput schema / properties / attachment_paths / title
```
Removed value: -"Attachment Paths"
```
addedInput schema / properties / attachment_paths / type
```
Added value: +"array"
```

removedInput schema / properties / attachments / anyOf

Removed value: -[
-  {
-    "items": {
-      "additionalProperties": {
-        "type": "string"
-      },
-      "type": "object"
-    },
-    "type": "array"
-  },
-  {
-    "type": "null"
-  }
-]

removedInput schema / properties / attachments / default
```
Removed value: -null
```

addedInput schema / properties / attachments / items

Added value: +{
+  "additionalProperties": {
+    "type": "string"
+  },
+  "type": "object"
+}

removedInput schema / properties / attachments / title
```
Removed value: -"Attachments"
```
addedInput schema / properties / attachments / type
```
Added value: +"array"
```
removedInput schema / properties / draft_id / title
```
Removed value: -"Draft Id"
```

removedInput schema / title

Removed value: -"outlook_attach_to_draftArguments"

Changed6 schema fields changedv1.28.0Oct 25, 2026

addedInput schema / properties / attachment_paths / anyOf

Added value: +[
+  {
+    "items": {
+      "type": "string"
+    },
+    "type": "array"
+  },
+  {
+    "type": "null"
+  }
+]

addedInput schema / properties / attachment_paths / default
```
Added value: +null
```
removedInput schema / properties / attachment_paths / items
```
Removed value: -{
-  "type": "string"
-}
```
removedInput schema / properties / attachment_paths / type
```
Removed value: -"array"
```

addedInput schema / properties / attachments

Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "additionalProperties": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Attachments"
+}

changedInput schema / required

Previous value: -[
-  "draft_id",
-  "attachment_paths"
-]New value: +[
+  "draft_id"
+]

First observedv1.11.0Jun 10, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the permissive annotations (readOnlyHint=false, destructiveHint=false), it discloses the 3MB auto-switch threshold, the attachments_dir resolution rule, that out-of-directory paths are refused, the 3MB per-inline-file cap, and the return value (new attachment IDs). That is exactly the operational context annotations cannot express.

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

Conciseness4/5

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

The purpose and the 3MB rule are front-loaded in the first sentence, and every subsequent clause carries real information. Minor deduction for the mid-sentence line wrapping that slightly fragments the `attachments` clause.

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

Completeness4/5

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

With no output schema and no schema descriptions, the description still covers all three parameters' meaning and the return value, which is sufficient to invoke it correctly. Residual gaps: whether attachments append to or replace existing ones, and any total-size limit across multiple files.

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

Parameters5/5

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

Schema coverage is 0% and the inline `attachments` schema is only an untyped additionalProperties object. The description compensates by spelling out the item shape ({name, content_base64, content_type?}), the per-item size limit, and the path-resolution/security semantics of `attachment_paths` — far more than the schema alone conveys.

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?

States a specific verb and resource ("Add attachments to an existing draft") plus a notable behavioral trait (auto-switching to upload-session above 3MB). This clearly separates it from outlook_create_draft, outlook_send_with_attachments, and outlook_attach_to_event 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.

Usage Guidelines4/5

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

The target resource (an existing draft) makes the applicable context clear, and the return-value sentence points to outlook_remove_draft_attachment as the paired follow-up tool. It stops short of stating when-not to use it (e.g., attaching to a task or message, or creating a draft with attachments in one step).

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

Deploy Server

outlook_attach_to_draft

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools