Mailbox MCP

All documentation

Set up in 4 steps

The same 4 steps in every client. Only the third one differs, and the page for your own client says exactly how.

1. Create an account and add a mailbox

   Sign up at the control panel, then add the mailbox you want your assistant to reach. Gmail, Microsoft 365, or anything that speaks IMAP.

2. Copy your connector URL

   Each mailbox has its own, and you copy it from the Connector tab of that mailbox in your control panel. It looks like https://mcp.mailbox-mcp.com/db/mcp/YOUR-MAILBOX-KEY, with a key at the end that identifies the mailbox. The snippets below show that placeholder, so replace it with your own. Use the right URL for each mailbox rather than the same one twice: Claude and several other clients treat 2 connectors with the same address as one connector, so a shared URL means your second mailbox refuses to be added at all.

3. Put it in your client

   A settings screen in the chat clients, a JSON or YAML file in the editors. Find your client below: the page names the file, the key and the transport value it wants.

Adding the mailbox

Step one has 3 parts and the panel walks you through them, but it is worth knowing what it is going to ask for before you start.

• Part one

  Which provider

  Microsoft 365 signs you in and there is no password to find. Gmail wants an app password. Everything else wants 4 settings your existing mail client already holds.
• Part 2

  The connection check

  The panel opens the mailbox before it saves anything, so a wrong server name or a rejected password is a message on the form rather than a tool that silently returns nothing next week.
• Part 3

  A name you will recognise

  Name it for the mailbox, not for us. Your client lists connectors by that name, and 3 of them called mcp-server tell you nothing a month later.

The step we do not have

Most set-up documentation for a remote MCP server has a step where you copy a client ID and a client secret out of one panel and paste them into another. Ours does not, and the difference is worth a paragraph because it changes what you have to keep safe afterwards.

This server does dynamic client registration, the part of the OAuth specification that lets a client introduce itself and be issued credentials on the spot. Your client asks the server who it should talk to, the server tells it, and the 2 of them settle it between themselves. You paste a URL and press a button.

So when a client shows you an advanced OAuth section with empty boxes for a client ID and a secret, leave them empty. They exist for servers that cannot do this. Filling them in here does not make the connection more secure; it gives it one more thing to get wrong, and it puts a credential in your clipboard that never needed to be there.

Find your client

Every page names the file, the key, the transport value and the UI route, and ends on the vendor page it was read from and the day it was read.

AI assistants

Chat clients. Paste a URL, sign in, done.

• Settings, Connectors, Add custom connector. One URL and a sign-in. The advanced OAuth fields stay empty, which is the opposite of what most set-up guides tell you.
• The same Connectors screen as the web, and the same URL. Worth its own page because most desktop set-up guides still send you to a JSON file and a local bridge you do not need.
• Plus needs no administrator, and we sent real mail through a Plus account on it. Business and Enterprise/Edu need an admin to switch developer mode on first. Web only.

Editors and coding agents

A JSON or YAML file, and the keys differ in every one.

• A single command, and one flag that decides whether the mailbox follows you between projects or vanishes when you change directory.

• Cursor

  URL only, probably 2 lines of JSON in mcpServers. Cursor documents a type key for local servers only, so a remote entry that carries one is copied from somewhere it did not belong.
• The one client where the top-level key is servers, not mcpServers. Paste the wrong one and nothing appears, with no error to tell you why.
• The key is context_servers, and the absence of a headers block is a setting rather than an omission. It is what tells Zed to sign in instead of expecting a token.

• Windsurf

  URL only, probably The URL key is serverUrl, which no other client uses. And the documentation you will land on is branded Devin, so you will think you have the wrong page.

• Cline

  URL and an access token The transport is streamableHttp in camel case, alone among every client here. And OAuth appears nowhere in Cline's documentation, so this one takes an access token.

Agents and automation

Platforms that run without somebody watching.

• Goose

  URL and an access token YAML rather than JSON, extensions rather than mcpServers, uri rather than url, and streamable_http with an underscore. Nothing about this one matches anything else.

• LibreChat

  URL and an access token The transport is streamable-http with a hyphen. One token gives everybody the owner's connection; Team Access gives each person their own entry, level and sign-in.

• n8n

  URL and an access token The documentation and the node disagree. Which fields you see depends on the version of the node in your workflow, and an old one cannot do MCP OAuth at all.
• Pick Dynamic discovery and it needs nothing but the URL. 2 traps first: generative orchestration is off by default, and your tenant DLP policies govern MCP servers too.

For administrators

If your organisation requires an administrator to approve third-party apps, the person connecting a mailbox is stopped at Microsoft's or Google's screen and handed a note to forward. These 2 pages are what the administrator reads: the app by its identifiers, what it asks for and why, the one-step approval, and how to revoke it.

• Microsoft 365 admins

  Read before approving Written for the administrator a Microsoft 365 user has been sent to: the app by its ID, the permissions and what each is for, the tenant-wide approval link, and how to revoke it.

• Google Workspace admins

  Read before approving Gmail needs nothing from you: an app password over IMAP, no OAuth client to allowlist. The calendar app does: its client ID, its 3 scopes, and the Admin console path to mark it Trusted.

If the approval comes with a vendor security questionnaire, the page below answers it: where the service runs and in which country, who the sub-processors are, what is kept and for how long, how a breach is notified, and what we do not have.

• For IT and security

  For the questionnaire The answers a vendor questionnaire asks for, in the order it asks them: where it runs, who the sub-processors are, what is kept and for how long, how a breach is notified, and what we do not have.

9 clients, 4 names for one key

This is the table we could not find anywhere else, which is why it is here. Every value in it was read off that vendor's own documentation on 30 August 2026, and the reason it is worth the trouble is that every one of these clients is being configured for the same server, over the same transport, and no 2 of them describe it the same way.

Client	Top-level key	URL key	Transport
Claude Code	mcpServers	url	"type": "http"
Cursor	mcpServers	url	none documented
VS Code	servers	url	"type": "http"
Zed	context_servers	url	none documented
Windsurf	mcpServers	serverUrl	none documented
Cline	mcpServers	url	"type": "streamableHttp"
Goose	extensions	uri	type: streamable_http
LibreChat	mcpServers	url	type: streamable-http
n8n	no file	Endpoint	HTTP Streamable

Read 30 August 2026 Each row comes from that vendor's own current documentation, linked at the foot of its page here. Where a client's page named a transport in prose but documented no key for it, the cell says so rather than repeating the prose as though it were a field.

One transport, 5 wordings

Every client in that table connects over Streamable HTTP. 4 of them want you to type its name into a file, and no 2 spell it alike: http, streamableHttp, streamable_http and streamable-http. Camel case, snake case, kebab case and a bare word, for one thing. n8n makes it a menu choice instead and calls it HTTP Streamable, which is a fifth wording and the only one with a space in it.

That is not carelessness on anybody's part. The protocol says how a client and a server talk once they are connected and says nothing about what the configuration file looks like, so each client invented its own vocabulary and each is right within its own program. It only becomes a trap when you set up a second client by adapting the snippet from the first, which is what everybody does, including us: the control panel shipped one JSON block for 3 clients and it worked in none of them until this reading was done.

The shape of the mistake

A wrong key does not usually produce an error. The client reads a file it does not recognise, finds nothing it understands, and starts up with no server attached, which looks exactly like a server that is down. If a client shows no tools at all, suspect the key before you suspect us.

3 docs sites that moved

If you searched for your client's MCP documentation before arriving here, there is a fair chance you landed somewhere stale. 3 of the pages this section is built on are no longer where the search results point:

• docs.claude.com/en/docs/claude-code/mcp 301 code.claude.com/docs/en/mcp
• docs.windsurf.com/windsurf/cascade/mcp 307 docs.devin.ai/desktop/cascade/mcp
• block.github.io/goose/docs/ 404 Goose documentation is at goose-docs.ai

The Windsurf one is the one to watch. Its MCP documentation is now served under Cognition's Devin brand and the page uses "Devin" and "Windsurf" interchangeably, so a reader who follows the redirect reasonably concludes they have the wrong page and goes back to searching.

What to type first

A connector that is set up correctly says nothing at all, so the honest way to check it is to use it. Ask for something you can verify against your own mailbox in one 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.

When that works, the use cases are worth a look for the things that are less obvious, and the full tool reference lists everything an assistant can reach and marks which tools are read-only.

Frequently asked questions

Do I need a client ID and a client secret?

No. This server registers your client for you the first time it connects, using the dynamic client registration part of the OAuth specification. You paste one URL and sign in. If a set-up guide asks you to copy a client ID and a secret out of a panel, it is describing a server that cannot do that, and pasting values into those fields here only gives the connection something else to get wrong.

Which config file does the snippet go in?

It differs per client and every page in this section names the file at the top of the block, because a correct snippet in the wrong file is the most common way a set-up fails silently. Cursor reads ~/.cursor/mcp.json, VS Code reads.vscode/mcp.json or a user file it opens by command, Zed reads its settings.json and Goose reads ~/.config/goose/config.yaml.

Why does the top-level key change between clients?

Because no standard names it. The protocol specifies how a client and a server talk once they are connected; it does not specify what the configuration file looks like. So Cursor, Windsurf, Cline and LibreChat use mcpServers, VS Code uses servers, Zed uses context_servers and Goose uses extensions, and all 4 are correct for their own client.

Does reading a message mark it as read?

No. Reading through this server never sets the seen flag, so an assistant can go through a backlog without destroying your own unread markers. That is a deliberate design rule rather than a side effect, and it is checked against a real mailbox rather than asserted. Marking something read is a separate tool that only runs when you ask for it.

My client is not in this list. Will it still work?

Probably. This is an ordinary remote MCP server over Streamable HTTP, so anything that speaks the protocol can hold it, and the SDKs speak it directly. The pages here exist because the settings live somewhere different in every client, not because the server needs anything special from any of them. Tell us which client you are using and we will read its documentation and add a page.

What happens to the connection if I change my mailbox password?

The mailbox stops answering and the tools start failing, because the credential we hold is the one you gave us. Update it in the control panel and the connector starts working again. The connector URL itself does not change, so nothing in your client needs touching.

Do I need ChatGPT Business to connect an MCP server?

No. ChatGPT Plus is enough, and you switch developer mode on yourself without an administrator. We connected this server to a Plus account in a browser on 1 September 2026 and it read, searched and sent. OpenAI's own FAQ says full MCP is a Business and Enterprise/Edu feature and gives even Pro read and fetch, and it does not mention Plus at all, so treat this as tested rather than promised. Free is untested.

Can ChatGPT send email through an MCP server?

Yes. The claim that MCP in ChatGPT is read-only described an earlier connector model. We asked a Plus account to send an email with no tool and no folder named, and the message was delivered from the right address with that account's own signature on it. ChatGPT asks for confirmation before some write actions depending on the app's permissions, and OpenAI blocks a few especially risky ones outright rather than offering them for approval.

Will my mailbox work in the ChatGPT phone app?

No. OpenAI answers this one directly: MCP apps are web only. Set the connector up in a browser and expect it to be missing on mobile. If you want the same mailbox on a phone, Claude.ai holds it on any plan and its mobile apps see the connector like any other.

Is any of this specific to Claude?

No, and the key table on this page is the evidence. Claude was the first client most people connected because it was first to ship remote MCP support, but there are 13 clients documented here and the server cannot tell them apart. It answers the protocol, not a brand.

What this section does not cover

The same rule as the rest of the site. Saying what is missing is cheaper than letting somebody find out.

• Not protocol documentation

  If you are building your own MCP server rather than connecting to one, the specification at modelcontextprotocol.io is the thing to read. These pages are about configuring clients.

• No panel screenshots

  Control-panel screens go stale faster than anything else on a website and a wrong one costs more than an absent one. The panel describes itself as you use it.

• No other vendors' prices

  Whether your client needs a paid tier for MCP is that vendor's to state, and it changes. Each page links to their own page rather than repeating a figure that will be wrong.

• Mail, and a calendar you connect

  This server reads and writes email, and a calendar once one has been connected to the mailbox, which is a separate step. No contacts, no files on a drive.