How do I use outlook-mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@outlook-mcp-server Check my latest emails from my inbox." 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.

de en es ja ko ru zh

outlook-mcp-server

by acangialosi

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

outlook-mcp-server

A local MCP server that gives Claude (Desktop or Code) read/write access to a personal Hotmail / Outlook.com mailbox via the Microsoft Graph API, using the OAuth 2.0 authorization code flow (with PKCE) against the Microsoft identity platform.

It exposes six tools: list_messages, get_message, search_messages, send_message, create_draft, and list_folders.

Everything runs locally over stdio — there is no hosted service, and your mail never passes through anything but your machine and Microsoft's own Graph API.

How it works

Auth: MSAL Node runs an authorization-code + PKCE flow against https://login.microsoftonline.com/consumers (personal accounts only — see Tenant choice), using a short-lived local HTTP server as the redirect target. Tokens (including the offline_access refresh token) are cached and silently refreshed on future runs.
Storage: the token cache is serialized by MSAL, encrypted with AES-256-GCM using a locally-generated key, and written to ~/.outlook-mcp-server/token-cache.enc (mode 0600). The key itself lives in ~/.outlook-mcp-server/cache.key (also 0600). See Security notes for the threat model this does (and doesn't) cover.
Graph calls: a thin fetch-based client calls https://graph.microsoft.com/v1.0/... with the current access token.
MCP server: built on @modelcontextprotocol/sdk, speaking stdio, so it can be launched directly by Claude Desktop / Claude Code as a child process.

Related MCP server: Outlook MCP Python

Prerequisites

Node.js 18+
A Microsoft account (Hotmail, Outlook.com, or Live) — the mailbox you want Claude to access.
A free Azure account to register the app (any Microsoft account can do this — it does not need to be a paid Azure subscription).

1. Install

git clone <this repo>
cd outlook-mcp-server
npm install

2. Register an app in the Azure Portal

This registration is what issues the client ID this server uses to talk to Microsoft Graph on your behalf. npm run setup (below) walks you through this interactively, but the steps are:

Go to portal.azure.com and sign in with any Microsoft account.
Search for App registrations → + New registration.
Fill in the form:
- Name: anything, e.g. outlook-mcp-server.
- Supported account types: "Personal Microsoft accounts only". This is what restricts the app to Hotmail/Outlook.com/Live accounts rather than a work/school (Azure AD) tenant.
- Redirect URI: platform "Public client/native (mobile & desktop)", value http://localhost:8765/callback (or another port — just be consistent when the setup script asks).
Click Register, then copy the Application (client) ID from the Overview page.
Go to API permissions → + Add a permission → Microsoft Graph → Delegated permissions, and add:
- Mail.Read
- Mail.ReadWrite
- Mail.Send
- offline_access (often present by default)
Personal Microsoft account delegated permissions like these don't need admin consent — you consent yourself during sign-in in step 3 below.
(Optional, advanced) If you'd rather use a confidential client with a client secret instead of the public-client PKCE flow, add a Web platform redirect URI and create a secret under Certificates & secrets. Most people should skip this.

3. Run setup (auth + config)

npm run setup

This will:

Print the walkthrough above.
Prompt for the client ID (and optional secret / tenant / redirect URI), and save it to ~/.outlook-mcp-server/config.json.
Open your browser to sign in and consent.
Verify the token works by calling GET /me, printing your name/email.
Print the JSON snippet to add to your Claude config (see below).

To re-authenticate later (revoked token, switching accounts, etc.) without re-entering the app registration details:

npm run login

4. Build and register with Claude

npm run build

Claude Desktop — add to claude_desktop_config.json (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):

{
  "mcpServers": {
    "outlook": {
      "command": "node",
      "args": ["/absolute/path/to/outlook-mcp-server/dist/src/index.js"]
    }
  }
}

Claude Code:

claude mcp add outlook -- node /absolute/path/to/outlook-mcp-server/dist/src/index.js

Restart Claude Desktop / Claude Code. The tools below should now be available.

Tools

Tool	Description
`list_messages`	List messages from a folder (default `inbox`), with `since`/`until` date filters, `unreadOnly`, sorting, and pagination.
`get_message`	Fetch the full content (body, all recipients) of one message by ID.
`search_messages`	Free-text search (`$search`) across mail, optionally scoped to a folder.
`send_message`	Send an email immediately (`to`/`cc`/`bcc`, subject, text or HTML body).
`create_draft`	Create a draft in the Drafts folder without sending.
`list_folders`	List mail folders and their IDs, for use with the `folder` parameter above.

All tools return JSON (as MCP text content) and surface Graph API errors as tool errors rather than crashing the server.

Tenant choice

By default this uses the consumers tenant (https://login.microsoftonline.com/consumers), which only accepts personal Microsoft accounts (Hotmail/Outlook.com/Live) — a work/school account will be rejected at sign-in. If you need to support both personal and Azure AD accounts, set the tenant to common during npm run setup (or via OUTLOOK_MCP_TENANT=common). This project is designed and tested for the personal-account (consumers) case.

Configuration reference

Everything can be set via npm run setup (written to ~/.outlook-mcp-server/config.json) or via environment variables, which take precedence — see .env.example:

Variable	Purpose
`OUTLOOK_MCP_CLIENT_ID`	Azure app registration's client ID.
`OUTLOOK_MCP_CLIENT_SECRET`	Only if using a confidential client (Web platform).
`OUTLOOK_MCP_TENANT`	`consumers` (default) or `common`.
`OUTLOOK_MCP_REDIRECT_URI`	Must match the Azure app registration.
`OUTLOOK_MCP_CONFIG_DIR`	Where config/token cache are stored. Defaults to `~/.outlook-mcp-server`.

Security notes

The token cache is encrypted at rest with a locally-generated AES-256-GCM key (~/.outlook-mcp-server/cache.key, mode 0600). This protects against casual disclosure — accidental commits, backups, other unprivileged users on a shared machine — but not against an attacker who already has read access to your user account's files, since the key sits next to the encrypted cache. For stronger protection, swap the ICachePlugin in src/auth/tokenCache.ts for one backed by your OS keychain (e.g. via keytar) — the plugin interface is intentionally isolated to that one file.
Never commit ~/.outlook-mcp-server/ (it's outside the repo by default) or a .env file containing OUTLOOK_MCP_CLIENT_SECRET.
send_message sends immediately with no confirmation step inside this server — Claude is expected to confirm intent with you before calling it for anything sensitive. Prefer create_draft when you want a review step.
Requested scopes are limited to Mail.Read, Mail.ReadWrite, Mail.Send, and offline_access — no calendar, contacts, or broader Mail.* application-level access.

Troubleshooting

AADSTS50020 / "user account ... does not exist in tenant" — you're hitting a tenant that doesn't accept personal accounts, or you're signing in with a work/school account against consumers. Confirm the app registration's "Supported account types" is "Personal Microsoft accounts only" and that OUTLOOK_MCP_TENANT is consumers (or common if you intentionally want both).
AADSTS50011 / redirect URI mismatch — the redirectUri in ~/.outlook-mcp-server/config.json must exactly match a redirect URI configured on the Azure app registration, including the port.
"Not signed in" tool errors — run npm run login.
Port already in use during setup/login — another process is using the redirect URI's port; stop it, or reconfigure the app registration and npm run setup with a different port.

Development

npm run dev     # run the MCP server directly from TypeScript (stdio)
npm run build   # compile to dist/
npm run clean   # remove dist/

Project structure

src/
  index.ts            MCP server entrypoint (stdio transport)
  config.ts            Config loading (env + config file)
  auth/
    crypto.ts           AES-256-GCM file encryption helpers
    tokenCache.ts        MSAL ICachePlugin backed by crypto.ts
    msalClient.ts        MSAL app factory + silent token acquisition
    loginFlow.ts          Interactive loopback OAuth flow
  graph/
    client.ts            Generic Microsoft Graph fetch wrapper
    mail.ts               Mail-specific Graph calls
    types.ts              Graph response types
  tools/                 One file per MCP tool, registered in index.ts
scripts/
  setup.ts              Interactive one-time (and re-runnable) setup

Available Tools

6 tools

create_draftCreate a draft emailA

Create a draft message in the mailbox's Drafts folder without sending it. Prefer this over send_message whenever the user should review the email first.

ParametersJSON Schema

Name	Required	Description
`cc`	No	List of email addresses.
`to`	No	List of email addresses.
`bcc`	No	List of email addresses.
`body`	No	Email body content.
`subject`	No	Email subject line.
`bodyType`	No	Content type of `body` (default text).

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description must convey behavioral traits on its own. It clearly discloses that the email is not sent and is instead stored in the Drafts folder. While it does not mention potential side effects (e.g., overwriting existing drafts) or required permissions, these are not critical for a draft-creation tool. The disclosure is sufficient for a simple operation, earning a 4 rather than 3.

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?

The description is two sentences: the first states the core purpose, the second gives usage guidance. It is front-loaded and every word earns its place. No fluff or redundancy.

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?

The tool is relatively simple with six well-documented parameters and no output schema. The description provides the essential purpose and usage context. It could mention what the tool returns (e.g., draft ID) but that is not crucial for the agent's selection decision. The description covers the action, location, and when to use it, making it mostly complete for this tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so the input schema already documents all six parameters (to, cc, bcc, body, subject, bodyType) with their types and semantics. The description adds no additional parameter details, but it also does not need to because the schema is complete. Baseline of 3 is appropriate.

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?

The description clearly states the action: 'Create a draft message in the mailbox's Drafts folder without sending it.' It specifies the verb (create), the resource (draft message), the location (Drafts folder), and the key distinction from sending. This unambiguously differentiates it from its sibling send_message.

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?

The description explicitly says 'Prefer this over send_message whenever the user should review the email first.' This directly instructs when to use this tool versus an alternative, making the usage context crystal clear.

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

get_messageGet full email messageA

Fetch the full content (including body, all recipients, and sender) of a single message by its Graph message ID, as returned by list_messages or search_messages.

ParametersJSON Schema

Name	Required	Description	Default
`messageId`	Yes	The Graph message ID.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It states the tool fetches full content, which implies a read operation, but does not disclose any side effects, permissions, or limitations. It adds some context (what is included in the content) but lacks details like whether it marks messages as read or requires specific scopes.

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?

The description is a single sentence, front-loaded with the action and resource, and includes the key detail about where the ID comes from. No wasted words.

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?

Given the tool is simple (one parameter, no output schema, no nested objects), the description is complete enough. It explains what the tool does, what the parameter is, and how to obtain it. It could mention return format, but the absence of an output schema and the simplicity of the tool make this acceptable.

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

Parameters3/5

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

The schema description coverage is 100% (the only parameter messageId is described as 'The Graph message ID.'). The description adds that the ID is 'as returned by list_messages or search_messages', which provides useful context beyond the schema. However, the schema already covers the parameter meaning, so the description adds marginal value.

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?

The description clearly states the tool fetches full content of a single message by its Graph message ID, specifying the resource (message) and the action (fetch full content including body, recipients, sender). It also distinguishes from siblings by referencing list_messages or search_messages as sources for the ID.

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 description implies usage: use this tool when you have a message ID from list_messages or search_messages and need full content. It does not explicitly state when not to use it or mention alternatives, but the context is clear enough for an agent to decide.

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

list_foldersList mail foldersA

List top-level mail folders in the mailbox (Inbox, Sent Items, Drafts, Archive, custom folders, etc.) along with their IDs and item counts. Use a returned folder ID with list_messages or search_messages to target that folder.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.7/5.0

Behavior4/5

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

The description implicitly indicates a read-only operation via 'list', but lacks an explicit statement about no side effects or modifications. Since no annotations are provided, the description carries full burden, and this is a minor omission.

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?

The description is a single, concise sentence that conveys the essential information without redundancy.

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?

While the description mentions IDs and item counts, it does not specify the exact return format (e.g., array, object) or potential errors. Given the absence of an output schema, a bit more detail on the return structure would be helpful, but the current level is adequate for a simple list operation.

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?

There are no parameters, so the description correctly omits any parameter details. The schema is empty, and no additional explanation is needed.

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?

The description clearly states the tool lists top-level mail folders with IDs and counts, and it distinguishes itself from sibling tools by focusing on folder enumeration rather than message operations.

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?

It explicitly instructs to use the returned folder ID with list_messages or search_messages, providing clear when-to-use and how to chain with other tools.

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

list_messagesList email messagesA

List messages from a mail folder (default: inbox), newest first by default. Supports date-range and read/unread filtering. Use list_folders first if you need a folder ID other than a well-known name like 'inbox', 'drafts', 'sentitems', 'archive', or 'junkemail'.

ParametersJSON Schema

Name	Required	Description
`top`	No	Max messages to return (default 25, max 100).
`skip`	No	Pagination offset.
`since`	No	ISO 8601 date-time; only messages received on/after this.
`until`	No	ISO 8601 date-time; only messages received on/before this.
`folder`	No	Well-known folder name (inbox, drafts, sentitems, deleteditems, archive, junkemail, outbox) or a folder ID. Defaults to inbox.
`orderBy`	No	Field to sort by (default receivedDateTime).
`unreadOnly`	No	If true, only unread messages. If false, only read ones.
`orderDirection`	No	Sort direction (default desc, i.e. newest first).

TDQS

A4.2/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It does not explicitly state side effects or read-only nature, though listing is implicitly non-destructive. It lacks details on error handling or edge cases.

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?

The description is two concise sentences, well-structured, and free of redundant information.

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?

No output schema exists, so return format is not required. The description covers main behavior and parameters, though it omits details like pagination mechanics beyond the parameters, but this is sufficient given the schema.

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

Parameters4/5

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

All parameters are described in the schema, and the description adds helpful context about folder IDs and defaults, enhancing understanding beyond the schema.

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?

Clearly states the tool lists messages from a folder, specifies default folder and ordering, and distinguishes from siblings by focusing on listing instead of searching or getting individual messages.

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?

Provides explicit guidance to use list_folders when needing a folder ID, and mentions filtering capabilities, but does not explicitly compare with search_messages or get_message for when to use them.

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

search_messagesSearch email messagesA

Full-text search across mail (subject, body, sender, recipients, attachments) using Microsoft Graph's $search, ranked by relevance. Optionally scope the search to one folder. For structured filtering (date ranges, read/unread) without free-text search, prefer list_messages instead.

ParametersJSON Schema

Name	Required	Description
`top`	No	Max results to return (default 25, max 100).
`query`	Yes	Free-text search query.
`folder`	No	Optional well-known folder name or folder ID to restrict the search to.

TDQS

A4.6/5.0

Behavior4/5

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

No annotations are provided, so the description must carry the behavioral disclosure. It adds notable behaviors: full-text scope across fields, relevance ranking, optional folder scoping. It does not mention page limits, but the top parameter is documented. The description gives enough context for a search operation without contradicting any annotations.

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?

Two sentences, front-loaded with the core function, and no redundancy. Every clause earns its place, making it an exemplar of concise tool documentation.

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?

For a search tool with a simple parameter set and no output schema, the description covers the main functionality, adds an explicit alternative, and clarifies optional folder scoping. It omits pagination details, but the top parameter is documented in the schema, so the description is sufficiently complete for practical use.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3. The description adds context by noting 'Optionally scope the search to one folder,' giving extra meaning to the folder parameter. It does not elaborate on top or query beyond schema, but the added folder context justifies a 4.

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?

The description clearly states it performs full-text search across mail fields (subject, body, sender, recipients, attachments) and specifies the ranking mechanism (relevance). It also distinguishes itself from sibling list_messages by contrasting free-text search against structured filtering, making the purpose unambiguous.

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 states when to use (free-text search) and when not to (structured filtering without free-text) and names the preferred alternative (list_messages). This gives the agent clear decision-making guidance.

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

send_messageSend an emailA

Send a new email immediately from the signed-in mailbox. This sends right away — there is no confirmation step, so only call this once you (and the user, if appropriate) are sure about the recipients and content. Use create_draft instead if the message should be reviewed before sending.

ParametersJSON Schema

Name	Required	Description
`cc`	No	List of email addresses.
`to`	Yes	List of email addresses.
`bcc`	No	List of email addresses.
`body`	Yes	Email body content.
`subject`	Yes	Email subject line.
`bodyType`	No	Content type of `body` (default text).
`saveToSentItems`	No	Save a copy to Sent Items (default true).

TDQS

A4.5/5.0

Behavior4/5

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

No annotations are provided, but the description discloses that sending is immediate and non-confirmatory: 'this sends right away — there is no confirmation step.' It also implies irreversibility by advising careful consideration. It does not mention failure handling or permissions, but it covers the core behavioral trait.

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?

The description is two sentences, front-loaded with the purpose, and each sentence adds value: the first states the action, the second explains the immediate nature and gives an alternative.

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

Completeness5/5

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

For a simple send action with full schema and no output schema, the description covers the purpose, usage context, and behavioral nuance. It provides sufficient context for an agent to decide when to use this tool versus create_draft.

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

Parameters3/5

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

The input schema already describes all parameters with 100% coverage, so the description adds no additional parameter meaning. The description doesn't mention any parameter specifics, but the schema suffices.

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?

The description clearly states the function: 'Send a new email immediately from the signed-in mailbox.' It distinguishes from sibling create_draft by referencing alternative usage, making the purpose unambiguous.

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?

It explicitly provides when-not to use: 'Use create_draft instead if the message should be reviewed before sending.' It also advises certainty before calling: 'only call this once you (and the user, if appropriate) are sure about the recipients and content.'

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.

6 tool updatesv1.0.0Aug 21, 2026
- First observedcreate_draft
- First observedget_message
- First observedlist_folders
- First observedlist_messages
- First observedsearch_messages
- First observedsend_message

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.3/5.0

Scored 2026-09-09 17:45 across 6 tools

Disambiguation4/5

Most tools have clearly distinct purposes: listing, fetching, searching, folder enumeration, sending, and drafting. The only possible confusion is between list_messages and search_messages, but their descriptions clearly differentiate structured filtering from full-text relevance search.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: list_messages, get_message, search_messages, list_folders, send_message, create_draft. There are no style mixups or vague verbs.

Tool Count5/5

Six tools is a well-scoped set for an Outlook mail server. Each tool covers a distinct core email operation without unnecessary bloat or missing essentials.

Completeness4/5

The tool surface covers the primary mail workflows: listing, searching, reading, sending, drafting, and folder navigation. Some common operations like reply, forward, delete, move, or updating drafts are absent, but the core read/send workflow is solid.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
nylas A
io.usefulapi
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Email Calendar Management CRM
152
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
AgentMailOAuth
to.agentmail
Email inboxes for AI agents: send, receive, reply, search, and manage threaded email over MCP.
Email Communication
2

Related MCP Servers

Claude-Read-Outlook
Email File Systems App Automation
Zacccck
A
license
B
quality
D
maintenance
A MCP server for Claude that reads Outlook emails its attachments through the Microsoft Graph API.
Updated 3 months ago (2026-06-16 17:12 UTC)
6
18
MIT
Outlook MCP Python
Email Calendar Management
cycle-sync-ai
F
license
Not graded
quality
D
maintenance
A Python-based MCP server for Microsoft Outlook integration using Microsoft Graph API, enabling email reading/sending, calendar management, and contact operations through Claude Desktop.
Updated a year ago (2025-05-27 20:14 UTC)
1
-
outlook-mcp
Email Communication
hamzashahbaz
A
license
Not graded
quality
D
maintenance
MCP server that enables Claude to manage Outlook emails, including reading, sending, organizing, drafting, and bulk operations via Microsoft Graph API.
Updated 5 months ago (2026-03-29 21:43 UTC)
15
1
MIT
outlook-personal-mcp
Email Calendar Management
salahawad
A
license
A
quality
B
maintenance
An MCP server that gives Claude Code and Codex full control of a personal Outlook.com mailbox and calendar via the Microsoft Graph API, enabling mail, draft, folder, and calendar operations through natural language.
Updated 2 months ago (2026-06-28 09:19 UTC)
31
1
MIT