ryaker/outlook-mcp: a Microsoft 365 MCP server for Claude, wired through Graph and Power Automate
MCP server for Claude to access Outlook data via Microsoft Graph API
At a glance
- What is it?
- The repository packages Outlook mail and calendar, OneDrive files, and Power Automate flows as MCP tools that Claude can call. It is a Node.js process you run locally, and every capability it exposes depends on an Azure app registration you create and consent to yourself.
- Who is it for?
- Adopt it if you want Claude to read and act on your own Outlook mailbox, calendar, and OneDrive through delegated Graph permissions, and you are willing to run a local Node process plus an OAuth callback on localhost:3333. Do not adopt it for unattended tenant-wide automation, since every permission listed is delegated and tied to a signed-in user.
- Can I use it commercially?
- Not without permission. GitHub finds no licence file in the repository, and without a licence all rights are reserved by default: you may read the code but not reuse it. Check the README, or ask the authors, before using it.
- Is it still maintained?
- Yes. The repository last received commits 169 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What ryaker/outlook-mcp exposes to a Claude session
The project is an MCP server, meaning it runs as a separate process and advertises a fixed set of callable tools that a Claude client can invoke. The README lists three service families. Outlook covers email and calendar: list-emails, search-emails, read-email, send-email, mark-as-read, list-events, create-event, accept-event, decline-event, delete-event, list-folders, create-folder, move-emails, list-rules, and create-rule. OneDrive covers onedrive-list, onedrive-search, onedrive-download, onedrive-upload, onedrive-upload-large, onedrive-share, onedrive-create-folder, and onedrive-delete. Power Automate covers flow-list-environments, flow-list, flow-run, flow-list-runs, and flow-toggle.
The audience is narrow and specific. This is for someone who already uses Claude Desktop or Claude Code as their working surface and wants it to touch their own Microsoft 365 mailbox rather than a copy of it. The tool names map closely to Graph endpoints, so the value is not abstraction but reachability: a chat client that otherwise cannot see your inbox gains the ability to list, search, read, send, and file messages. If you do not live in a Claude client, nothing here helps you.
The module layout and where the Graph calls actually live
The directory listing is the most informative part of the repository. index.js is the entry point and config.js holds settings. Under auth/, token-manager.js is described as handling token storage and refresh for both Graph and Flow, and tools.js holds auth-related tools. Under utils/, graph-api.js is described as the Microsoft Graph API helper, odata-helpers.js builds OData queries, and mock-data.js supplies test-mode data.
Each capability area is a folder of one-file-per-verb modules: email/list.js, email/search.js, email/read.js, email/send.js, email/mark-as-read.js, and so on for calendar/, folder/, rules/, and onedrive/. The onedrive folder is the one place where size is handled explicitly, with upload.js for simple upload under 4MB and upload-large.js for chunked upload above 4MB. power-automate/ is separate again, with flow-api.js as its own client rather than routing through graph-api.js.
The consequence of that split is that you are authenticating against two different APIs with two different token paths held in one token manager. The README states that Power Automate requires additional Azure AD configuration with a Flow API scope, and that it is optional. That is an honest framing: the Outlook and OneDrive tools work off the standard Graph delegated permissions, while the five flow-* tools sit behind a second consent you may not be able to obtain in a managed tenant.
Setting it up: npm install, an Azure app registration, and an auth server on port 3333
The Quick Start sequence in the README is six steps: npm install; register an app in the Azure Portal; copy .env.example to .env and add credentials; update the Claude Desktop config with the server path; run npm run auth-server; then use the authenticate tool in Claude to get the OAuth URL.
The Azure side is spelled out. Register a new app named something like M365 MCP Server, choose the account type that allows accounts in any organizational directory and personal Microsoft accounts, and set the redirect URI to Web with the value http://localhost:3333/auth/callback. Copy the Application (client) ID into .env. Under API permissions, add Microsoft Graph delegated permissions: offline_access, User.Read, Mail.Read, Mail.ReadWrite, Mail.Send, Calendars.Read, Calendars.ReadWrite, Files.Read, and Files.ReadWrite. Under Certificates and secrets, create a client secret and copy the value, not the Secret ID, because the README warns that the portal shows both.
The redirect URI is the detail to notice. The callback is plain HTTP on localhost, so authentication only completes on a machine where that port is free and reachable from the browser doing the consent. The README's configuration section begins with cp .env.example .env and then shows a commented .env block, but the supplied text is truncated at that point, so the exact variable names beyond the Azure client ID and secret cannot be confirmed from the material. The prerequisites are Node.js 14.0.0 or higher plus npm or yarn.
Delegated-only permissions and the consent problem in managed tenants
Every permission in the README's list is delegated, which means the token acts as the signed-in user, not as the application. That is the right choice for a personal assistant tool and the wrong choice for anything unattended. There is no application-permission path documented, no service principal flow, and no mention of admin consent being pre-granted. In a tenant where users cannot self-consent to Mail.ReadWrite and Files.ReadWrite, an administrator has to approve the registration before a single tool works.
The scope set is also broad relative to the tool list. Mail.ReadWrite and Files.ReadWrite are read-write grants over the mailbox and the user's OneDrive, and the server exposes send-email, move-emails, create-rule, onedrive-delete, and flow-toggle alongside the read tools. There is no documented per-tool scope reduction or read-only mode, so a session that only needs list-emails still carries the write grants. If you want a narrower grant, the material does not describe how to get one.
The README also links an MseeP.ai security assessment badge at the top. That is a third-party assessment of the project, and the repository text does not summarise its findings. Treat the badge as a pointer to read, not as a verdict.
Test mode, mock data, and what it does not cover
The features list includes a Test Mode described as simulated responses for testing without real API calls, backed by utils/mock-data.js. That is a useful affordance for verifying that Claude is calling the right tool with the right arguments before you hand over credentials. What it cannot tell you is whether your Azure registration, redirect URI, or consent scopes are correct, because those only fail against the live endpoint. A mock-data pass is a wiring check, not an integration check.
The larger gap is operational. There are no releases retrieved for the repository, no homepage, and the licence field is unknown. The README's own structure section is the primary documentation of behaviour; the configuration section is truncated in the supplied material, so the full .env surface, any token cache path, and any refresh-token persistence detail cannot be confirmed. If token-manager.js writes tokens to disk, the README text provided here does not say where or with what file permissions. That is the first thing to read in the source before running it on a shared machine.
Where a direct Graph script is the better fit
The honest alternative for a one-off job is a short Node or Python script that calls Microsoft Graph directly with the same delegated permissions. The difference is architectural: this project exists to put a model in the loop, translating natural-language intent into tool calls, and it pays for that with a long-running process, an OAuth callback server, an MCP client configuration, and a tool schema the model must select from correctly. A script that fetches today's unread mail and writes it to a file has none of that surface area and no dependency on a model choosing the right function.
Choose the script when the task is fixed and repeated. Choose this server when the task is exploratory, when the useful query is not known in advance, and when having the mailbox readable inside a conversation is the point. The other distinction is that a script can request a single scope, while this server's documented permission set is fixed and broad. A team that only needs to read a shared calendar will find the mail and file write grants hard to justify.
Maintenance, licence, and what to check before depending on it
The repository is not archived and the last push shown is 2026-03-30, so it is being touched. No releases were retrieved, which means there is no tagged version to pin to; installation is from the default branch. The licence is listed as unknown, so the terms under which you may use, modify, or redistribute the code are not established by the material provided. That is a real blocker for any commercial or redistributed use, and it is not legal advice to say so: check for a LICENSE file in the repository before you build on it.
Upgrade cost is dominated by the Azure side rather than the code. Client secrets expire, and the README tells you to choose an expiration when creating one, so a secret rotation is a recurring task tied to your app registration, not to npm. Graph API permission names and Power Automate's separate Flow API scope are the other moving parts. Because the flow-* tools sit behind additional Azure AD configuration, a tenant policy change can disable five of the tools without touching the rest of the server.
Editorial conclusion
Adopt it if you want Claude to read and act on your own Outlook mailbox, calendar, and OneDrive through delegated Graph permissions, and you are willing to run a local Node process plus an OAuth callback on localhost:3333. Do not adopt it for unattended tenant-wide automation, since every permission listed is delegated and tied to a signed-in user. Before wiring it into a daily workflow, verify that the auth-server callback on http://localhost:3333/auth/callback receives the code, that token refresh survives a restart, and that the repository actually carries a licence file.
Community notes