Most Outlook-and-AI demos begin at the fun part. Someone asks, “What did Sarah say about the renewal?” and a tidy answer appears three seconds later.
The interesting part is everything hiding behind that answer.
Claude needs a safe way to reach Microsoft 365. Microsoft Graph needs to know which mailbox the application may access. Your company needs a way to decide who may use the connection. And nobody should paste a client secret into a desktop configuration file and hope for the best.
That is where a remote Model Context Protocol server—or remote MCP server—fits. It sits between Claude and Microsoft Graph, exposing a small set of email tools while keeping Microsoft credentials, permissions, and business rules on infrastructure you control.
This guide explains the architecture and the setup sequence. The goal is not merely to make one successful email search. It is to build a connector that you can understand, test, and safely give to another person.
What we are building
The finished flow has four participants:
- Claude decides when to use an email tool.
- Your remote MCP server describes those tools and receives Claude’s requests.
- Microsoft Entra ID authenticates the server and issues Microsoft Graph tokens.
- Microsoft Graph reads the permitted mailbox data.
The MCP server is the control point. It can expose narrow tools such as:
search_messages(query, after_date, limit)get_message(message_id)list_recent_messages(folder, limit)get_thread(message_id)
Notice what is not on that list: send_message, delete_message, or move_message. Start read-only. You can always add carefully controlled actions later; removing an overly powerful tool after people depend on it is harder.
Step 1: Decide whose identity reads the mail
Microsoft Graph offers two broad access patterns.
With delegated access, the app acts on behalf of a signed-in user. What it can do is constrained by both the app’s scopes and that user’s permissions.
With app-only access, the service acts as itself. No mailbox user has to remain signed in, which makes this useful for a shared mailbox, scheduled process, or centrally managed assistant. The tradeoff is important: application permissions can be broad, so an administrator must grant consent and should restrict the app to the intended mailbox population.
For a remote MCP server serving one shared or functional mailbox, app-only access is often the simpler operational model. For a personal assistant where every employee should see only their own mail, delegated access is usually a better fit.
Do not choose based on which sample code is shortest. Choose based on the identity and access rule you want to be true six months from now.
Step 2: Register the Microsoft Entra application
In the Microsoft Entra admin center, create an app registration for the Graph-facing service.
Record the tenant ID and application ID. Then add only the Microsoft Graph application permissions your MCP tools require. A connector that searches and reads messages needs read access; it does not need permission to send email simply because sending might be useful someday.
An administrator must grant tenant-wide consent for application permissions. This is a good moment to involve the Microsoft 365 or identity administrator instead of treating them as the final boss encountered at deployment time.
For an early prototype, a client secret is convenient. For production, prefer a certificate, workload identity, or managed identity where your hosting platform supports it. Secrets expire, get copied, and have an unfortunate habit of becoming “temporary” for several years.
Step 3: Restrict mailbox access
This is the step that separates a responsible enterprise tutorial from “congratulations, your demo can read the company directory.”
Microsoft Graph application permissions describe what the app may do. Exchange authorization should further restrict where it may do it. For new configurations, Microsoft recommends Role Based Access Control for Applications in Exchange Online, which can pair an application role such as Application Mail.Read with a resource scope containing only the intended mailboxes. Application Access Policies are now the legacy path.
One detail can defeat an otherwise careful scope: Exchange application-RBAC grants and unscoped Microsoft Entra application permissions are additive. If the service principal still has tenant-wide Mail.Read through Entra, adding a mailbox-scoped Exchange role does not narrow that existing grant. Remove the unscoped permission when moving the authorization into scoped Exchange RBAC.
The principle is stable even when the administration screen changes: create an explicit mailbox scope, add the one or few mailboxes the connector needs, and test both an allowed and a denied mailbox.
Your negative test matters. A successful read proves that the app works. A rejected read proves that the boundary works.
Step 4: Build small Graph-backed tools
Inside the MCP server, acquire a Graph token using a supported Microsoft identity library. For app-only authentication, request the https://graph.microsoft.com/.default scope; the token will contain the application roles already granted to the Entra app.
Then keep each MCP tool boring and explicit.
A search tool should validate its inputs, cap the result count, select only the fields Claude needs, and return stable identifiers that another tool can use. A message-reading tool should accept one identifier and return a clean text representation rather than dumping the entire Graph response into the model’s context.
This is not only a performance improvement. Smaller results reduce accidental exposure of irrelevant recipients, headers, and attachments. They also make Claude’s answers better because the important text is not buried in metadata.
Useful response fields usually include:
- Subject
- Sender and recipients
- Sent or received time
- A plain-text body or carefully converted HTML body
- A stable message or conversation ID
- A browser link back to Outlook, if appropriate
Never log access tokens or full message bodies by default. Log the tool name, request correlation ID, timing, result count, and a sanitized error category.
Step 5: Put OAuth in front of the MCP server
Microsoft Graph authentication protects the downstream mailbox. You still need to control who can connect Claude to your MCP server.
Claude’s remote custom connectors support OAuth. Your server therefore needs to participate in the MCP authorization flow: advertise its protected-resource metadata, direct the client to an authorization server, validate access tokens on the MCP endpoint, and handle expiry and refresh correctly.
In an enterprise deployment, Microsoft Entra ID is a natural authorization server. Some architectures can use it directly. Others use a small OAuth broker that presents the client-facing authorization endpoints and delegates sign-in to Entra. The broker pattern is useful when the client behaves like a public PKCE client but your Entra configuration or downstream service also requires confidential-client behavior.
Keep these two identities separate in your head:
- The employee connecting Claude to the MCP server
- The service identity used by the MCP server to call Graph
They may both involve Entra, but they answer different questions: “Who may use this connector?” and “What mailbox data may the service read?”
Step 6: Deploy it somewhere Claude can reach
A remote MCP server needs a stable public HTTPS URL. Azure Container Apps is a sensible choice if the rest of your identity and data live in Microsoft’s ecosystem, but the same principles apply to other hosts.
Configure:
- HTTPS ingress
- A health endpoint that does not reveal configuration details
- Secrets or identity bindings outside the image
- Structured application logs
- Reasonable request timeouts
- At least one rollback-ready image or revision
If you build the container on an Apple Silicon Mac, explicitly target the architecture expected by the hosting environment. An image can build perfectly and then fail instantly in the cloud because it contains the wrong machine architecture—a surprisingly sophisticated way to produce a very short log.
Step 7: Add the connector to Claude
In Claude, open Settings → Connectors and add a custom connector using the remote MCP URL. On Team or Enterprise plans, an owner may first need to add or enable the connector for the organization; users then connect their individual accounts.
Complete the OAuth flow, enable only the email tools you intend to test, and start with deterministic prompts:
- “List the five most recent messages in the inbox.”
- “Find messages received after July 1 containing ‘Project Atlas.’”
- “Open the newest result and return its sender, date, and first paragraph.”
These are better tests than “What should I know?” because each failure points to a narrower layer.
The verification checklist
Before calling the connector finished, verify all of the following:
- A permitted user can add and authenticate the connector.
- A user who is not assigned cannot use it.
- The server can read the intended mailbox.
- The server cannot read an out-of-scope mailbox.
- Claude discovers only the tools you meant to expose.
- Large searches are capped and paginated.
- Tokens and message bodies do not appear in routine logs.
- Expired tokens refresh or fail with an understandable recovery path.
- Removing a user or mailbox from an allowlist actually revokes access.
The flashy moment is Claude summarizing an inbox. The real accomplishment is knowing exactly why it was allowed to do so—and knowing that the same request against the wrong mailbox or by the wrong user will fail.
That is the difference between an AI demo and an enterprise integration.