Lock Outlook drafts via a draft-only tool policy

Why this matters

Microsoft does not ship a first-party mailbox MCP for Outlook as of May 2026. Their official enterprise MCP is read-only Entra and identity scope; the Microsoft Work IQ Word and Calendar servers are in preview. There is no Google-equivalent “official Outlook MCP” with a draft-only tool surface.

The result is that Outlook draft-only wiring is policy-driven, not protocol-driven. Composio Outlook is the practical path: it exposes the full Outlook mailbox surface (draft, send, reply, send-reply, delete) and the Auxot tool policy is the lock that decides which of those the agent can call.

This makes Outlook structurally less safe than Gmail. The Gmail official MCP does not request the send scope at all; the Composio Outlook MCP does request send capability and the policy is the only thing keeping the agent from using it. The pattern still works, but the discipline is tighter: the policy must be written, tested, and reviewed before any real run, and any policy rewrite has to preserve the send-exclusion.

Nothing leaves your Sent folder: you read the draft, you click send in Outlook.

Quick start

1. Connect Composio Outlook (Add an MCP server). Search for “Outlook” in the connector catalog; pick Composio Outlook. Walk through the OAuth flow using the team’s Microsoft 365 account.
2. Note which tools the MCP exposes. Composio Outlook typically exposes create_draft, create_draft_reply, send_email, send_email_reply, and a small set of mailbox-management tools. The draft tools are what the agent uses; the send tools are what the policy blocks.
3. Write the tool policy (Define a tool policy). Allow create_draft and create_draft_reply only. Block every tool with “send” in the name. Block any tool that exposes a “send now” or “auto-send” parameter even if the tool name does not include “send.”
4. Test the policy with a send attempt. Ask the agent to send a test email to your own address. The tool policy should reject the call. Then attempt the same test under a temporarily loosened policy (for verification only); the call should succeed (proving the MCP itself can send, and the policy is the lock). Restore the strict policy.
5. Write a one-paragraph operating note: explains that this MCP supports send tools and the policy is the lock. The next admin who touches the policy must preserve the send exclusion.

Done? A connected Composio Outlook MCP, a tool policy that prevents the agent from sending mail, and a written note that calls out the policy as load-bearing.

The agent can do that?

1. Inventory the Composio Outlook tool surface

Chat → Admin Agent:

I'm wiring Composio Outlook for an Auxot agent. The agent must only produce drafts; the human sends from Outlook. List the tools Composio Outlook exposes, group them as: (1) draft tools the agent should call, (2) send tools the policy must block by name, (3) tools that accept a send flag that the policy must also constrain by parameter shape, (4) mailbox-management tools the agent might need read access to. Output a paste-ready tool-policy spec.

Why it’s non-obvious: Composio’s tool surfaces change as Composio adds capabilities; the inventory the agent produces today might be incomplete next quarter. Treating the policy as a generated artifact (rebuild the spec when Composio ships new tools) is the right discipline. Saving the agent’s output as a context file beside the policy lets the next admin re-run the same exercise.

2. Build the tool policy

Tool policy target: Composio Outlook MCP. Allowed tools: `create_draft`, `create_draft_reply`. Blocked tools: any tool with "send" in the name, any tool with a send-now or auto-send parameter set to true. Mailbox-read tools: allow for thread context. List the tool-policy rules in the order they should be evaluated; the most restrictive rule wins. Flag any tool the agent might need that does not cleanly fit either bucket and recommend a default (block, allow with conditions, etc.).

Why it’s non-obvious: Composio sometimes exposes a single update-message tool that handles both draft and send via a parameter. The policy must inspect the parameter (block when the parameter says “send”), not just the tool name. The agent helps you see the parameter shape; the policy you write enforces the constraint.

3. Operating note for the team

MCP: Composio Outlook. Authenticated user: [name]. Agents using this MCP: [list]. Produce a one-paragraph operating note: (1) Microsoft has no first-party Outlook MCP for mailbox operations; Composio is the practical path; (2) Composio Outlook supports send tools; the agent's tool policy is the only lock that keeps the agent draft-only; (3) any policy rewrite must preserve the send exclusion; (4) what to do if the agent appears to have sent something (check Outlook Sent folder; if it shipped, the policy was loosened or a parameter slipped through). Tone: factual. Lives beside the policy doc.

Why it’s non-obvious: Future admins might rewrite the policy to add a new field or a new agent and accidentally drop the send-exclusion in the rewrite. The operating note flags the send-exclusion as load-bearing, which gives the rewriter a reason to preserve it rather than treating it as cruft from a previous version.

Go deeper

Why not wait for a first-party Microsoft MCP

Microsoft has signaled Word and Calendar MCPs in preview but no public timeline for a mailbox MCP as of May 2026. Waiting means leaving Outlook users without an email-draft path while the rest of the team (on Gmail) ships agents. The Composio Outlook wiring is the right move now; if Microsoft ships a first-party mailbox MCP later, migrate the agents and update the policy. The discipline (draft-only by policy) is the same; only the connector identity changes.

Composio Outlook vs Pipedream Outlook

Composio is the more widely used Outlook connector in Auxot deployments as of May 2026. Pipedream offers a similar surface; if your team already uses Pipedream for other workflows, the Pipedream Outlook connector is a reasonable alternative. The same tool-policy discipline applies to both. The choice between them is usually about which platform your team already pays for, not which connector is technically superior.

Distribution lists, shared mailboxes, and delegated access

Outlook’s shared-mailbox model is different from Gmail’s. Microsoft 365 supports shared mailboxes as a distinct identity; the MCP authenticates to that identity if the integration user has been granted “send as” or “send on behalf of” permission. For the draft-only pattern, the agent does not need send permission; read and draft permission are sufficient. Configure the shared mailbox to grant the integration user draft and read only, and the policy holds even if Outlook’s permission model is misconfigured.

Microsoft 365 admin app approval

Some Microsoft 365 tenants require admin approval for new OAuth apps. Composio Outlook is a third-party app from Microsoft’s perspective, so admin approval might be required. The approval is a one-time configuration; once approved, individual users can connect without re-approval. If the OAuth flow fails with an admin-consent-required error, the resolution is in the Microsoft 365 admin center, not in Auxot.

Troubleshooting

• The agent appears to have sent an email. Check the Outlook Sent folder for the authenticated user. If the email is in Sent, the tool policy was loosened or a parameter slipped through (a draft tool accepted a send-now value of true). Revoke the connection, audit the policy line by line, re-wire.
• Composio reports a quota error. The free tier allowance is exhausted. Decide whether to upgrade the Composio plan or throttle the agent’s draft rate. The throttling option works for non-time-sensitive workflows; the upgrade is the answer for high-volume production runs.
• The OAuth flow stalls at “admin approval required.” Microsoft 365 tenant has app review on. Walk the tenant admin through the Composio Outlook app entry in the admin center; the approval is a one-time configuration.
• Drafts are appearing in the wrong mailbox. The OAuth flow was completed under a different identity than expected. Composio shows the authenticated email address on the connector entry; verify it matches the intended mailbox before saving the connection.

Variations and edge cases

• The team uses Gmail, not Outlook. See Wire Gmail drafts through Google’s official MCP. The Gmail path is simpler because Google’s official MCP does not expose send tools at all.
• The agent needs to attach files to Outlook drafts. Composio Outlook supports attachments via the create-draft tool. The file payload is part of the tool call. Watch your Auxot tier’s tool-call payload size limits if the attachment is large.
• The team uses both Gmail and Outlook on different segments. Wire both. The Gmail path is structurally safer (no send scope in the MCP); the Outlook path is policy-safer (send tools blocked by policy). Either way the result is the same: agent drafts, human sends.
• The agent needs to file emails into Outlook folders. Composio Outlook exposes folder-management tools. Allow those in the policy if the agent’s job includes filing. The draft-only constraint applies to email-sending tools, not to mailbox-organization tools.

Walkthrough

Step 1: Open the MCP-server settings

Open Settings → MCP servers in Auxot. Click Add server. Search for “Outlook” in the catalog.

Step 2: Pick Composio Outlook

The catalog shows the Composio Outlook connector. Pick it. (Pipedream Outlook is a valid alternative; the rest of this walkthrough assumes Composio but the steps are equivalent.)

Step 3: Walk through the OAuth flow

Click connect. The OAuth flow opens in a new tab. Sign in with the team’s Microsoft 365 account. Review the requested permissions; Composio Outlook requests mailbox read and write. Approve. If your tenant has admin app review on, the connection will fail until the tenant admin approves Composio Outlook in the Microsoft 365 admin center.

Step 4: Verify the connection

Back in Auxot, the MCP-server entry should show “Connected” with the authenticated user’s email. Run a read tool call to verify the connector can see the inbox.

Step 5: Write the tool policy

Open Settings → Tool Policies (Define a tool policy). Create a new policy. Allow create_draft and create_draft_reply. Block every tool with “send” in the name. Block any draft tool with a send-now parameter set to true. Save.

Step 6: Test both the draft path and the send block

Ask the agent to draft a test email. Confirm the draft appears in Outlook Drafts. Then ask the agent to send a test email. The tool policy should reject the call.

What’s next

• → Wire Gmail drafts through Google’s official MCP. The Gmail counterpart of this pattern, structurally simpler because Google’s official MCP does not include send scope.
• → Keep send_email out of your agent tool policies. The cross-cutting principle: why every email-producing agent should be draft-only, with the structural argument for the pattern.
• → Set up your Monday morning briefing. A daily briefing the agent drafts and you send; works with either Gmail or Outlook wiring.
• → Triage and follow up on inbound leads. Lead-reply drafts use this wiring on the Outlook side of the team.
• → Add an MCP server. The MCP wiring foundation this tutorial builds on.
• → Define a tool policy. The send-exclusion mechanism that makes the Outlook draft-only pattern hold.

Reference

• MCP: Composio Outlook. The practical Outlook path in May 2026; Microsoft has no first-party mailbox MCP.
• Tool policy shape: allow create_draft, create_draft_reply; block any tool with “send” in the name; block any draft tool with a send-now parameter set to true.
• What the policy is doing: the MCP exposes send tools; the policy is the only lock preventing the agent from using them. Different from Gmail, where the official MCP does not expose send scope at all.
• Authentication: OAuth via Microsoft 365. Per-user; shared mailboxes need their own connection or a configured “send as” permission (and the draft-only constraint means even “send as” is fine because the policy blocks send).
• Where drafts land: the authenticated user’s Outlook Drafts folder.
• The structural review gate: the Drafts folder. No Auxot human-step needed on top, but the policy is more load-bearing than in the Gmail case.
• Operating note discipline: lives beside the policy doc; calls out the send-exclusion as load-bearing so future policy rewrites preserve it.
• Composio pricing: free tier for low-volume testing; production volume needs a paid plan. Budget per-call costs for high-volume agents.
• Microsoft 365 admin review: some tenants require admin app approval. One-time configuration; resolution is in the Microsoft 365 admin center.