MCP Server for Multiple Outlook Accounts
This server lets an AI assistant manage multiple Outlook/Microsoft 365 mailboxes simultaneously through a single interface.
Email Operations:
๐
search_conversationsโ Search mailboxes with Gmail-style operators (paged results)๐
read_conversationโ Read full email conversation threadsโ๏ธ
create_draftโ Compose and save a draft (supports recipient parsing, reply threading, and large attachments via upload sessions)๐ค
send_messageโ Send an email immediately (with no-duplicate-send safety policy)๐ท๏ธ
list_labelsโ List all categories and folders (recursive)โ
create_labelโ Create a new category or folder๐
organize_mailโ Tag, move, archive, trash, mark as junk, or change read-state across a conversation๐
list_accountsโ List all connected mailboxes
CLI Account Management:
outlook-mcp-auth connectโ Connect a new mailbox via browser OAuthoutlook-mcp-auth listโ List connected accountsoutlook-mcp-auth removeโ Remove a connected account
Security highlights:
OAuth tokens stored locally only (file mode
600in a700directory)Attachment access from local paths disabled by default (requires explicit allow-list)
Tokens and credentials are never logged
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@MCP Server for Multiple Outlook Accountslist all connected mailboxes"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP Server for Multiple Outlook Accounts
A local, single-connector Model Context Protocol server that lets an AI assistant operate several Outlook / Microsoft 365 mailboxes at once โ searching, reading, drafting, sending, and organising mail โ through one safety-annotated tool surface, with OAuth tokens that never leave your machine.
This is the Outlook / Microsoft Graph provider variant of a provider-neutral specification.
๐
doc/business-specification.mdโ provider-neutral business + functional spec (the contract).๐
doc/provider-mapping.mdโ how neutral requirements bind to Microsoft Graph.๐๏ธ
doc/architecture.mdโ how this variant is designed and built.โ
doc/traceability-matrix.mdโ every requirement โ module โ test.๐
doc/ONBOARDING.mdโ operator guide: register an Entra app, handle consent, connect a mailbox.โ
doc/LIVE-ACCEPTANCE.mdโ live acceptance runbook +npm run live-smoke(the remaining work).๐ค
doc/CONTRIBUTING.mdโ handoff guide: how we work, workflow, and the per-phase record.๐
doc/HANDOVER.mdโ handover snapshot: what's done and the outstanding-work checklist.
Project status: feature-complete (offline build)
Built with TypeScript 6.0.3; build, typecheck, tests (179), and format all green. All eight capabilities are implemented and the offline build is feature-complete. What exists today:
โ Architecture design + requirements traceability matrix (
doc/).โ Auth core: Entra credential-source discovery, MSAL public-client (consent + silent refresh), secure token store (
0600/0700, atomic + cross-process-locked), account-selection registry.โ Account-management CLI:
outlook-mcp-auth connect | list | remove.โ Microsoft Graph client: thin
fetchwrapper with a per-request timeout, bounded jittered retry (with the no-duplicate-send policy), and actionable error mapping.โ Read tools:
list_accounts(C1),search_conversations(C2),read_conversation(C3) โ with Gmail-style search-operator translation and bounded, truncating output.โ Write tools:
create_draft(C4) andsend_message(C5) โ recipient parsing (Display Name <addr>), header-injection stripping, allow-listed/TOCTOU-safe attachments, local outgoing-size validation, and reply threading. Small attachments ride inline; large ones (> ~3 MB) upload to the draft via a Graph upload session, so send becomes create-draft โ upload โ send with the final/sendunder thenonDuplicableretry policy โ a retry can never double-deliver.โ Organise tools:
list_labels(C6),create_label(C7), andorganize_mail(C8) โ the label-decomposition fan-out that maps one neutral organise request to the right mix of Graph category-PATCH / read-state /movecalls (archive, trash, junk โ mutually exclusive), applied per message across a conversation under a bounded concurrency limit, reporting the union of resulting labels.list_labelsenumerates folders recursively (full paths).โ Hardening + onboarding: a secret-redaction boundary so tokens/credentials can never reach the logs (NFR-SEC-6), and the operator onboarding guide (Entra app registration, unverified-app consent, the connect CLI).
Remaining: the live acceptance runs (real browser consent + real Graph calls) that the
operator performs against an Entra app registration + Outlook mailbox. See doc/architecture.md ยง13.
Tests mock Microsoft Graph and MSAL. Live
ยง13acceptance โ real browser consent and Graph calls โ requires an Entra app registration + Outlook mailboxes and is run locally by the operator.
Related MCP server: msgraph-mcp
Capabilities (spec ยง5)
Tool | Purpose | Destructive? | Status |
| List connected mailboxes | No | โ live |
| Search a mailbox (paged) | No | โ live |
| Read a full conversation | No | โ live |
| Compose a draft (not sent) | No | โ live |
| Send immediately | Yes | โ live |
| List categories + folders | No | โ live |
| Create a category/folder | No | โ live |
| Tag / move / read-state | Yes | โ live |
Plus an out-of-band account-management CLI (outlook-mcp-auth connect | list | remove).
Development
Requires Node.js โฅ 18 (developed on Node 22).
npm install
npm run typecheck # tsc --noEmit
npm run build # compile to dist/
npm test # vitest (Graph/MSAL mocked)
npm run format:check # prettierConfiguration
All operational knobs are environment variables (see .env.example):
Env var | Meaning | Default |
| tokens + app-registration configs |
|
| pin one app registration (disables discovery) | unset |
| allow-list for | unset (disabled) |
| token-store lock wait |
|
| per-Graph-call timeout |
|
Connecting a mailbox
For the full walkthrough โ Entra app registration, the unverified-app consent policy, and troubleshooting โ see
doc/ONBOARDING.md. The short version:
Register a public-client app in Entra ID with the redirect URI
http://localhostand the delegated scopesMail.ReadWrite,Mail.Send,User.Read,offline_access.Drop a
credentials*.jsoninto the data dir (or pointOUTLOOK_OAUTH_CREDENTIALSat it):{ "clientId": "<application-client-id>", "tenant": "common" }Multiple
credentials*.jsonfiles are auto-discovered, so accounts under different app registrations each refresh with the client that authorised them.Connect, list, and remove mailboxes:
outlook-mcp-auth connect # opens the browser for consent outlook-mcp-auth connect --source acme # pick a specific app registration outlook-mcp-auth list outlook-mcp-auth remove user@example.com
Security posture
OAuth tokens are stored only on the local machine (file mode 600 in a 700 data dir). Reading
local files by path for attachments is disabled by default and only allowed from an explicit
allow-list. The server never logs tokens, credentials, or message content. See
doc/architecture.md ยง9.
License
MIT โ see LICENSE.
Available Tools
1 toollist_accountsList connected accountsARead-onlyIdempotent
List the Outlook / Microsoft 365 mailboxes connected to this server. Use the returned identities as the 'account' selector for other tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnly and idempotent; description adds context about output usage but not additional behavioral traits.
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?
Two sentences efficiently convey purpose and usage without any extraneous information.
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?
Given zero parameters and rich annotations, the description fully explains what the tool does and how to use its output.
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?
No parameters exist, and schema coverage is 100%, so baseline score of 4 applies; description adds no additional parameter info but none is needed.
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?
The description clearly states it lists Outlook/Microsoft 365 mailboxes and explains the purpose of the output.
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 tells the agent to use the returned identities as the 'account' selector for other tools, guiding correct usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
v0.1.0- First observed
list_accounts
TDQS
Scored across 1 tool
With only one tool, there is no possibility of ambiguity. Agents will always select list_accounts when any tool is needed.
The single tool follows a clear verb_noun pattern (list_accounts), making its purpose immediately understandable.
A single listing tool is far too few for a server purporting to handle multiple Outlook accounts. The user would expect tools for email operations, calendar management, or at least sending/reading messages.
The server only lists accounts and provides no way to actually interact with them. There are obvious missing operations like read_email, send_email, search_mailbox, or manage folders, leaving the surface severely incomplete.
Maintenance
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
- JustOnceOAuthai.justonce
Persistent memory for AI assistants โ one shared, OAuth-secured vault for every MCP client.
Email infrastructure for AI agents โ send, receive, search, and reply to email over MCP.
Hosted MCP server with managed OAuth for 15+ toolkits: Google Workspace, Fitbit, Oura, Kalshi, etc.
Related MCP Servers
- FlicenseAqualityCmaintenanceLocal-first MCP server for agents that need to work across multiple Gmail and Microsoft 365 accounts without cloud token storage.6-
- FlicenseBqualityBmaintenanceMCP server providing AI assistants with full access to Microsoft Outlook email and calendar via the Microsoft Graph API, featuring 26 tools for mail, calendar, contacts, and scheduling with delegated authentication.29-
- AlicenseNot gradedqualityDmaintenanceLightweight MCP server that enables AI agents to manage Microsoft Outlook email, calendar, and files using PKCE authentication with only a Client ID.MIT
- AlicenseNot gradedqualityCmaintenanceEnables reading, sending, and managing Microsoft 365/Outlook emails through MCP tools with OAuth 2.1 authentication.92MIT