All documentation
On this page
Set-up documentation
Connect your mailbox to Claude.ai
Add your mailbox to Claude on the web from its directory or as a custom connector: one URL, Continue, Add, Connect. No client ID, no secret.
Watch it done in 6 minutes
If you would rather watch than read, this is the whole thing in real time with nothing cut: an account created, an IMAP mailbox added, the connector pasted into Claude, and Claude answering its first questions about the mail in it. The steps below are the same ones, with the reasons.
Add Mailbox MCP from the Claude directory
Mailbox MCP is listed in the Claude directory, so there's a shorter route than the custom connector further down: nothing to paste. Open Mailbox MCP's listing and press Connect to Claude. You go straight to our sign-in, choose the mailbox and what Claude may do with it, and you're back in Claude with the email tools attached.
The connector the directory adds is always called Mailbox MCP, and Claude has no way to rename a connector. That's fine for one mailbox. For a second, add it as a custom connector named after that mailbox, with the steps below: we tested the 2 kinds side by side on 6 October 2026, and one chat used both.
Before you start
You need a mailbox already connected in the control panel. Claude cannot reach a mailbox we do not hold, and the panel is where the mail server credential is checked and kept. It takes about 2 minutes to connect a Microsoft 365 work mailbox with one Microsoft sign-in. A personal Outlook.com or Hotmail address, Gmail and iCloud Mail take a little longer, because each wants an app password or an IMAP switch first, and any other IMAP mailbox needs the 4 settings your mail app already has.
You do not need anything installed. Claude.ai talks to this server over
HTTPS from Anthropic's own infrastructure, so there is no bridge program,
no npx command and nothing running on your machine. That is
the difference between a remote MCP server and a local one, and it is
covered properly in
remote and local MCP servers.
Add the connector
-
Open Customize, then Connectors
Customize is in Claude.ai's left-hand menu. On the Connectors tab, press the black + Add button and choose Add custom connector. (For a first mailbox, the directory route above is shorter.)
-
Name it and paste the connector URL
Name it after the mailbox, not after us: Claude lists connectors by that name, and a second mailbox later would otherwise look the same. Paste the URL into MCP server URL and press Continue.
Connector URL One per mailbox, from its Connector tabhttps://mcp.mailbox-mcp.com/db/mcp/YOUR-MAILBOX-KEY -
Press Add without changing anything
Step 2 of 2 shows Sign in now and Use Claude's published identity, each marked Detected. Claude has read our server and picked both itself. Press Add.
Step 2 of 2 as Claude shows it for Mailbox MCP, 6 October 2026. Both choices are already made, so you press Add. The URL is blurred here. -
Press Connect and choose the mailbox
Add saves the connector but doesn't sign it in: its page says "You're not connected" with a Connect button. Press it, sign in to the control panel, and choose which mailbox this connector opens and what it may do. You're returned to Claude with the tools attached.
2 mailboxes, 2 URLs
Each mailbox has its own connector URL, on its Connector tab in the control panel. To add a second, repeat the steps with the second mailbox's URL, under a name that says which mailbox it is. Don't reuse the first URL: Claude treats 2 connectors with the same address as one. Multiple email accounts in Claude covers naming them and asking for the right one.
On Claude's Free plan
Anthropic's words: "Free users are limited to one custom connector." Each mailbox is a connector of its own, so on Free that's one mailbox by this route.
On a Team or Enterprise plan
Only an Owner or Primary Owner can add a custom connector on a Team plan, and on Enterprise also people whose custom role includes Manage access to Libraries. Anthropic puts it under Organization settings, Connectors, Add, Custom, Web.
Members then find it under Customize, Connectors and press Connect, which brings them to our sign-in like everyone else. Source: Anthropic's custom connector guide, read on 5 October 2026.
Why there's no client ID to paste
Leaving step 2 as Claude sets it is correct, not just acceptable. Its last choice, Use your own OAuth client, asks for a client ID, and most set-up guides for a remote MCP server tell you to go and fetch one.
That choice exists for a server that can't recognise Claude on its own. There, somebody has to register an application by hand and copy the credentials across.
This server reads the client details Anthropic publishes for Claude, which is what Use Claude's published identity means, and it also accepts automatic registration. So Claude marks the first one Detected, and our sign-in page shows that Claude's address was checked against Anthropic's published details.
Choosing your own client doesn't make anything more secure. It gives the connection one more thing to get wrong, and puts a credential in your clipboard that never needed to be there.
Stop Claude asking before every step
A new custom connector starts every tool at Needs approval, so Claude stops and asks before it reads, searches or files anything. That's safe, and slow. In Claude, open Customize, then Connectors, choose the connector, and under Tool permissions set both groups, Read-only tools and Write/delete tools, to Always allow. Each tool can also be set on its own, or to Blocked.
We run our own connectors at Always allow, because the real limit is the level you chose when you connected (Read only, Draft and file, or Send and delete). A tool above that level isn't offered to Claude at all, so Always allow can't reach past it.
Check that it worked
A connector that is set up correctly says nothing at all, so the way to check it is to use it. Start a new conversation and ask for something you can verify against your own mailbox at a glance.
Try this first
Summarise my 5 most recent unread emails, oldest first, and tell me which ones actually need me.
If the messages it names are the messages you expect, the connector works. Nothing is marked read by asking: reading through this server never sets the seen flag, so your own unread markers survive the test.
The control panel is the second check and the more definitive one. Open the mailbox and its connector card records when the connector was first used, so if that line has filled in, a call really did arrive here.
Let Claude attach files it makes
Ask Claude for a PDF, a spreadsheet or a chart and to email it, and it can do the whole job itself. It makes the file, asks this server for an upload link, uploads the file and attaches it.
We watched it do exactly that on : a PDF chart made and sent in 18 seconds, with nobody downloading anything.
It needs one setting: Claude's workspace has to be
allowed to reach mcp.mailbox-mcp.com.
- On your own plan: in Claude, open Settings, then Capabilities. Under
code execution and file creation, turn on Allow network egress
and set the domain allowlist to include
mcp.mailbox-mcp.com, or to all domains. - On a Team or Enterprise plan the Owner sets it for everyone: Admin
settings, Capabilities, code execution, then add
mcp.mailbox-mcp.comunder Additional allowed domains.
Without it nothing breaks: Claude gives you the upload link to drop the file on, and tells you which setting to change so the next one goes by itself.
If something goes wrong
3 things account for nearly all of it, and none of them produce a useful error message on their own.
-
Symptom
Claude says it has no email tools
Check the connector is ticked for the conversation you are in: press + in the message box, then Connectors, and tick it. Connectors are added to the account and then chosen per conversation, so a connector that exists is not necessarily one this chat can reach. If it shows "You're not connected", press Connect on its page under Customize, Connectors.
-
Symptom
The sign-in loops or ends on an error
Almost always a choice changed on step 2, usually Use your own OAuth client with a client ID pasted in. Remove the connector, add it again, and this time press Add without changing anything.
-
Symptom
Tools appear but every call fails
The mailbox credential we hold has stopped working, which usually means the mailbox password changed or an app password was revoked. The panel says so on the mailbox card; update it there and nothing in Claude needs touching, because the connector URL has not changed.
No account yet? The free tier is 5 MCP calls a day on any mailbox, with no card, which is enough to get to the end of this page and see your own mail in Claude.
For Claude Team and Enterprise administrators: single sign-on with no consent screen
Everything above is one person connecting their own mailbox. There is a second route, for an organisation. A Claude Team or Enterprise administrator enables Mailbox MCP for the organisation once. Each person's mailbox is then connected in Claude with no sign-in here and no consent screen.
Here is how. Claude presents this server with an identity assertion: a signed token from your identity provider, vouching for who the person is. The server verifies it and issues a connection to the mailbox, or the shared mailbox, that person already has on our side, at the level its owner already set.
Anthropic calls this Enterprise Managed Auth, and its page describes the exchange from Claude's side. Underneath, it is the MCP enterprise managed authorisation extension over the JWT bearer grant of RFC 7523.
What it needs
2 things, and the first is probably in place already.
-
In Claude
A Claude Team or Enterprise organisation whose members sign in through Okta
That is Claude's own single sign-on, set up under Organization and access, Setup SSO in the Claude admin console, with the organisation's domains verified.
Require SSO does not have to be on. What does matter is that each person has signed in through it at least once. Claude's test of the connector needs that session, and offers "Sign in again with SSO" to an administrator who has not.
The steps below are Okta's because Okta is where this was walked, and its Cross App Access is how it issues the identity assertion. Mailbox MCP has no app in the Okta Integration Network, so the connector is set up there as a custom app, which step 1 makes.
-
With us
A Mailbox MCP account with Team Access
Single sign-on lets the people on the account in, and people on an account are what Team Access provides.
The account's owner switches single sign-on on under Settings, in step 5. The owner and the Claude administrator need not be the same person.
The set-up, in 7 steps
In the order they were taken. Steps 1, 3 and 4 are in Okta, 2 and 6 in the Claude admin console, 5 in our control panel, and 7 is what a member of the organisation then sees.
-
Step 1, in Okta
An application for Mailbox MCP
Any custom app will do. The one this was walked with is an OIDC web application, assigned to the people who will use the connector.
On its Resource Server tab, set Cross-app access (XAA) to Enabled. Give it our issuer URL from the Settings page of the control panel,
https://app., as the issuer URL, and leave the audience empty.mailbox-mcp. com Okta shows a warning that its support for XAA apps is limited, and saves.
-
Step 2, in the Claude admin console
The connector
Connectors, Add connector, Custom, Web: a name, and the mailbox's own connector URL from its Connector tab in our control panel. Switch Managed authorization on.
Claude detected "Sign in now" and "Use Claude's published identity" from this server's metadata, so neither is typed. The connector can be added before its test passes.
Then Open WorkOS setup, which is the step-by-step guide the console opens for the Okta side. The next 2 steps are what it walks you through, with the values it shows.
-
Step 3, in Okta
The AI agent, from that guide
Directory, AI Agents, Register manually, named for Anthropic, with user access through the application people already sign in to Claude with.
Under Client registration choose Public/private key, Okta-managed, and add the public key the guide shows; Done, then Activate. Copy the agent's client id, which starts
wlp, back into the guide where it asks for it. -
Step 4, in Okta
The resource connection
On the agent, Resource connections, Add, Application, and choose the application from step 1, which Okta lists with "- XAA" after its name. The resource indicator is the same connector URL as in step 2.
The AI agent's client id is Claude's own,
https://claude., the published client this server already trusts. Scopes: Allow any. Then Actions, Activate, so the agent is active.ai/ oauth/ mcp-oauth-client-metadata -
Step 5, in our control panel
Settings
The account's owner enters the issuer URL of the Okta organisation, of the form
https://<org>.okta.com, switches single sign-on on and saves.The server fetches that issuer's discovery document as the setting is saved, and refuses one whose document does not name it. So a mistyped URL is caught here rather than at somebody's first call. The confirmation names the issuer whose assertions are now accepted.
A provider with no discovery document can be given its key set (JWKS) URL instead.
Nothing else is set on our side. There is no separate level for people who arrive this way, because the mailbox and the share decide it, as below.
-
Step 6, in the Claude admin console
The test
Run test walks 4 steps against this server: discovery, the identity assertion, the exchange and a probe of the connector. If it fails and offers "Sign in again with SSO", that is the prerequisite above; sign in that way and run it again.
When all 4 pass, choose which roles in the organisation get the connector and press Save & turn on.
-
Step 7, for each member
What the person sees
Under Customize, Connectors, the connector is listed as Managed and Connected, with no Connect button ever pressed.
In a chat, the first call to the mailbox brings Claude's usual per-tool permission and nothing else: no sign-in here and no consent screen.
On our side the connection appears on the mailbox's Connector tab like any other, labelled with your identity provider's host and the level it was given. Every call is recorded under the person's name, as it is for any connection.
The values behind those steps, which the control panel shows beside the switch: the issuer is what step 1 enters in Okta, and the token endpoint and the grant type are what Claude found in this server's metadata and used in the test's exchange.
| Issuer | https://app. |
| Token endpoint | https://mcp. |
| Grant type | urn:ietf:params:oauth:grant-type:jwt-bearer |
| Connector URL | The mailbox's own URL from its Connector tab, of the form A person's own URL from People also works and connects that person only. Never the bare server address. |
The connector URL matters more here than in the steps at the top of the page. On the consent screen the mailbox is chosen during the sign-in. With no sign-in, the URL is the only thing that says which mailbox the token is for.
That is why it is entered twice above: as the connector's URL in the Claude admin console, and as the resource indicator of Okta's resource connection. It is also why it is the mailbox's own URL and never the bare server.
It reaches the exchange as the resource parameter where your identity provider passes it through, and otherwise as the resource the assertion itself names. In the live set-up, the request Claude made to Okta for the assertion carried no resource, and the exchange still passed; the resource indicator on Okta's resource connection is where the URL was entered.
A provider that can carry neither has no mailbox to name, and cannot use this route.
The grant is also published in the server's authorisation server
metadata, under grant_types_supported and
authorization_grant_profiles_supported, which is how Claude
discovers that it is offered.
Who is let in
Who gets in is decided here, not by the assertion. The server matches the email address in the assertion against the mailbox the connector URL names.
| Who | What happens |
|---|---|
| The mailbox's owner, on their own mailbox | Connected at the mailbox's limit. |
| A colleague who holds an active share of it | Connected at the level set for them under People. The share is theirs if they were invited at that address under People, or signed up with it as their confirmed account address. |
| Anyone else, however valid their assertion | Refused, with a sentence the Claude admin console can show, quoted below. |
alice@acme.com has not been given access to sales@acme.com. The account owner can add them under People.
So single sign-on never adds a person to a mailbox, never widens a level and never reaches a mailbox that has not been shared. It replaces the sign-in and the consent screen, and nothing else; the security page says the same from the owner's side.
Removing someone
2 doors, and either one closes it. The access token lasts an hour and there is no refresh token. Claude gets a new one by presenting a fresh assertion.
| What you do | What happens |
|---|---|
| Remove the person at your identity provider | Their access ends at the next exchange, within the hour, with nothing to do on our side. |
| Remove them under People | It ends at the next call, because the share behind the connection is gone. |
| Pause them under People | The same, until they are resumed. |
| Revoke the connection on the Connector tab | It ends the token that connection holds. But while the person is still asserted by your provider and still has access here, Claude's next exchange mints a new one. Revoke is for a token you think has leaked, not for a person you want out. |
| Switch single sign-on off under Settings | The next exchange is refused for everyone at once, and any token already issued runs out within the hour. |
Verified, and when
Verified live on 15 September 2026: a Claude Team organisation signing in through an Okta organisation, set up as the administrators' section of the Claude.ai page describes; Claude's own connection test passed all 4 of its steps against this server, and a member's chat read a mailbox with no consent screen. Before that, on 14 September, Okta's Cross App Access playground and the server's own tests.
Questions about adding email to Claude.ai
How do I add email to Claude.ai?
Connect your mailbox in the Mailbox MCP control panel first, which takes a couple of minutes. Then open Mailbox MCP's listing in the Claude directory and press Connect to Claude, or add it under Customize, Connectors as a custom connector with the mailbox's connector URL. Either way you sign in to us once and choose which mailbox Claude opens. There's no client ID or secret to find.
Do I need a paid Claude plan to add email to Claude?
No. On the Free plan Anthropic says "Free users are limited to one custom connector", and each mailbox is a connector of its own, so that's one mailbox. Pro and Max aren't held to one: the Max account we tested on 6 October 2026 held a Mailbox MCP custom connector for each of its mailboxes, side by side. On Team and Enterprise an Owner adds the connector for the organisation and members press Connect.
Can I add a personal Outlook.com or Hotmail address to Claude?
Yes, through Mailbox MCP. Anthropic's own Microsoft 365 connector says "Personal Microsoft accounts (such as @outlook.com or @hotmail.com addresses) can't be used to connect." Mailbox MCP connects them over IMAP once you've switched IMAP on in Outlook.com's settings, and the Outlook.com guide shows where that switch is.
Should I use the Claude directory or a custom connector?
Use the directory for your first mailbox: it's one button and nothing to paste. The directory connector is always called Mailbox MCP and Claude offers no way to rename it, so add every further mailbox as a custom connector named after that mailbox. We tested the 2 side by side on 6 October 2026: they sit together under Customize, Connectors, and one chat can use both.
Will Claude Code see the email connector I added on Claude.ai?
Yes, if you sign in to Claude Code with your Claude.ai account. Anthropic's words: "MCP servers you've added in claude.ai, known as connectors, are automatically available in Claude Code". We checked on 5 October 2026 and every Mailbox MCP connector was listed there. Signed in any other way, Claude Code takes one command instead.
Why does Claude ask permission every time it uses my mailbox?
A new custom connector starts every tool at Needs approval, so Claude asks before each call. Open the connector under Customize, Connectors and set the Read-only tools and Write/delete tools groups to Always allow, or set each tool on its own. What Claude can do is still capped by the level you chose when you connected the mailbox, so a tool above that level is never offered at all.
Where to go next
The desktop app takes the same connector through the same screen, so if you use both, this is already done in both. Claude Code picks this connector up by itself if you sign in to it with the same claude.ai account, which Anthropic documents and we checked on 5 October 2026. Otherwise the Claude Code email MCP guide adds it with one command.
Cowork uses this same connector too: switch it on for a task from the + menu. Email in Claude Cowork has a recorded task and the permission settings.
If you're still deciding, can Claude read my email says what Claude does with a connected mailbox and what it doesn't. The use cases are worth a look once it is working, and the tool reference lists everything Claude can now reach and marks which of those tools are read-only.
On a paid Claude plan, an email routine can then have Claude work the mailbox on a schedule: a morning brief, or replies drafted for the people waiting on you.
Read 6 October 2026 Walked in a live Claude account on that day. The section for Claude Team and Enterprise administrators is the procedure walked on 15 September 2026 on a live Claude Team organisation and an Okta organisation, and states its own verified state. If it has changed since, tell us and we will read it again.