ryaker/outlook-mcp: an MCP server that puts Outlook, OneDrive and Power Automate inside Claude

What ryaker/outlook-mcp actually solves

Claude has no native path into a Microsoft 365 mailbox. The M365 Assistant MCP Server fills that gap by speaking the Model Context Protocol to Claude on one side and the Microsoft Graph API on the other. It is a bridge, not a mail client, and it assumes you already have a Microsoft account and an Azure tenant where you can register an application.

The intended user is an engineer or power user who runs Claude Desktop or a similar MCP host on their own machine and wants the assistant to answer questions like which meetings are on Thursday, or to send a message without leaving the conversation. Everything runs locally: the server is a Node.js process started from the repository, and the credentials live in a .env file on the same machine. Nothing is proxied through a third party, which is the main reason to pick this over a hosted connector.

The scope is broader than the name suggests. The README lists three service families: Outlook (email, calendar, folders and inbox rules), OneDrive (files, folders, search, sharing) and Power Automate (environments, flows, run history). That breadth is unusual for an MCP server of this kind, and it is also where the setup cost sits, because Power Automate needs additional Azure AD configuration beyond the Graph permissions.

How the server is put together and how a tool call flows

The repository is deliberately modular. index.js is the entry point, config.js holds settings, and each service gets its own directory: email/, calendar/, folder/, rules/, onedrive/ and power-automate/. Inside those directories every operation is a separate file, so list.js, search.js, read.js, send.js and mark-as-read.js each implement one tool. The README's directory listing makes that pattern explicit, and it is the clearest signal of how the project expects to grow.

Two shared layers sit underneath. utils/graph-api.js is the Microsoft Graph helper used by the Outlook and OneDrive tools, and utils/odata-helpers.js builds OData queries, which is how filters and paging reach Graph. Authentication is split out into auth/token-manager.js, which the README describes as handling token storage and refresh for both Graph and Flow, plus auth/tools.js for the authentication tools exposed to Claude. Power Automate does not go through Graph; power-automate/flow-api.js is its own client.

A tool call therefore travels: Claude invokes a named tool such as search-emails, the matching module builds an OData query, graph-api.js sends it with a token from token-manager.js, and the result comes back as tool output. The token manager is the piece that matters most in practice, because refresh behaviour determines whether a long session keeps working or dies partway through. The README does not document the refresh window or what happens when a refresh token is revoked, so treat that as an open question rather than a solved one.

Installing ryaker/outlook-mcp and running a first search

The README requires Node.js 14.0.0 or higher, npm or yarn, and an Azure account for app registration. Start by installing dependencies from the repository root:

npm install

Before the server can talk to Microsoft, you register an application in the Azure Portal. The README gives the exact steps: name it, choose the account type that covers any organisational directory plus personal Microsoft accounts, and set the redirect URI to a web platform at http://localhost:3333/auth/callback. Copy the Application (client) ID. Then add delegated Microsoft Graph permissions: offline_access, User.Read, Mail.Read, Mail.ReadWrite, Mail.Send, Calendars.Read, Calendars.ReadWrite, Files.Read and Files.ReadWrite. Finally create a client secret and copy the secret VALUE, not the Secret ID.

Credentials go into a .env file copied from the example:

cp .env.example .env

The keys are MS_CLIENT_ID, MS_CLIENT_SECRET and MS_TENANT_ID, with an optional USE_TEST_MODE flag. The example file notes that single-tenant apps should set MS_TENANT_ID to the tenant GUID so that /common is not used. That detail matters: leaving it as a placeholder changes which accounts can authenticate.

With credentials in place, start the separate authentication server, which is what serves the callback on port 3333:

npm run auth-server

Then, from Claude, call the authenticate tool to get the OAuth URL and complete consent in a browser. The README's quick start lists this as step six, after the Claude Desktop config has been pointed at the server path. If you want to exercise the tool surface without touching a real mailbox, the package defines a test mode:

npm run test-mode

That runs index.js with USE_TEST_MODE=true, and utils/mock-data.js supplies simulated responses. It is the fastest way to confirm the server starts and registers its tools before you debug Azure permissions.

The tool surface, and where it stops

Count the tools in the README tables and you get fifteen for Outlook, eight for OneDrive and five for Power Automate. The Outlook set is the most complete: list-emails, search-emails, read-email, send-email and mark-as-read cover the mail loop, while list-events, create-event, accept-event, decline-event and delete-event cover calendar. Folders get list-folders, create-folder and move-emails, and rules get list-rules and create-rule. OneDrive covers listing, searching, download URLs, upload, sharing links and folder creation and deletion, with upload split into onedrive-upload for files under 4MB and onedrive-upload-large for chunked uploads above that threshold.

The gaps are worth naming. There is no reply or forward tool, so answering a thread means composing a fresh message. There is no attachment handling on the email side, even though the OneDrive tools can produce download URLs. Calendar supports accept, decline and delete but the README does not list an update or reschedule tool. And the rules tools only list and create; there is no delete or modify for an existing inbox rule, which is a real constraint if you experiment and want to undo.

Power Automate is the thinnest area and the one most likely to disappoint. flow-run triggers a manual flow, flow-list and flow-list-environments enumerate what exists, flow-list-runs reads history and flow-toggle enables or disables a flow. The README states that Power Automate requires additional Azure AD configuration with a Flow API scope, and points to a section for details. If your goal is only mail and calendar, you can skip that entirely.

Where this server is the wrong choice

The authentication model is the main limitation. Every permission listed is a delegated scope, which means the server acts as the signed-in user. That is fine for a personal mailbox and awkward for shared mailboxes, service accounts or anything that needs to run unattended on a schedule. There is no application-permission path documented, so a headless deployment is not something the README supports.

Setup weight is the second issue. You need an Azure app registration, a client secret with an expiry date, a redirect URI on localhost, and a separate auth server process running on port 3333 before consent will work. That is a lot of moving parts compared with an MCP server that takes an API key. Teams that cannot create app registrations in their tenant, or whose policy blocks localhost redirect URIs, will not get past step two.

Maintenance status deserves a plain statement. The repository is not archived, but the last push was on 2026-03-30, which is roughly six months before today. There are no retrieved releases, so there is no tagged version to pin and no changelog to read. The package version in package.json is 2.0.0, and the licence field there says MIT, but the repository metadata does not confirm a licence file. If you need a dependency with a release cadence and a published security process, this is not it.

Finally, the README is thin on failure modes. It does not document what happens when a token expires mid-session, how rate limiting from Graph is surfaced to Claude, or whether a failed send reports an error or silently returns. Those are the questions you will hit in week one.

How it compares with the Microsoft 365 MCP server

The obvious alternative is Microsoft's own Microsoft 365 MCP server, which appears in the same search results people use to find this project. The difference in approach is architectural rather than cosmetic. Microsoft's server is a vendor-maintained component that you point at your tenant; this project is a self-hosted Node.js process you clone, configure and run yourself, with the OAuth flow terminating on your own machine.

That distinction drives everything else. Self-hosting means your client secret and tokens never leave your infrastructure, and you can read every line of the code that touches your mailbox. It also means you own the Azure app registration, the secret rotation, the Node.js version and the upgrade path. A vendor-maintained server shifts that operational load elsewhere, at the cost of running someone else's code against your data and accepting their tool surface and their release schedule.

The tool coverage is the other axis. This project bundles OneDrive and Power Automate alongside Outlook, which a mail-focused connector may not. If your workflow is mostly email triage and calendar, the extra surface is dead weight you still have to configure. If you want Claude to search a OneDrive folder and then send a summary by email in one conversation, the breadth is the reason to choose it.

Licence, upgrades and what maintenance costs you

package.json declares "license": "MIT", and the repository metadata does not list a licence, so the MIT declaration in the manifest is the only signal available. That is a permissive licence in the ordinary sense, but a manifest field is not the same as a LICENSE file at the repository root, and the top-level listing does not show one. If your organisation requires a reviewed licence file before adoption, that is a gap to raise rather than assume away. Nothing here is legal advice.

Upgrade cost is low in dependency terms and high in operational terms. There are exactly two runtime dependencies: @modelcontextprotocol/sdk at ^1.27.1 and dotenv at ^16.5.0. The caret ranges mean a fresh npm install can pull newer minor versions, and the MCP SDK is the one that matters, because protocol changes land there. With no tagged releases, upgrading means pulling the main branch and reading the diff yourself.

The recurring cost is the Azure side. Client secrets expire, and the README instructs you to select an expiration when creating one. When it lapses, authentication fails and you repeat the registration steps. Rotating a secret is a manual edit to .env plus a restart of both the auth server and the MCP server. Budget for that, and for the possibility that the repository does not move again before your next rotation.

Editorial conclusion

Adopt ryaker/outlook-mcp if you want Claude to read mail, manage calendar events and touch OneDrive files under a delegated Microsoft Graph identity you control, and you are willing to run a local Node.js process and register an Azure app. Do not adopt it if you need a vendor-hosted connector, a documented consent story for shared mailboxes, or a project with a visible release history. Before committing, verify three things in your own tenant: that the app registration can be created with the delegated permissions the README lists, that the redirect URI http://localhost:3333/auth/callback survives your organisation's policy, and that you can pin the repository to a commit, because there are no tagged releases to fall back on.

Frequently asked questions

Official sources

1. Issues
2. README
3. ryaker/outlook-mcp on GitHub