Guide
Remote and local MCP servers, and which one you need.
One is a program your client starts on your own machine. The other is a URL your client calls. That single difference decides what you install, what happens when the laptop shuts, and who holds the key to your mailbox.
- Reading About 6 minutes
- Ours is Remote
- Spec read Revision 2026-07-28
The short version
Local means the server is a program on your computer. Remote means it is a web address. Mailbox MCP is remote, so there is nothing to install, and if your client only understands local servers there is a one-line bridge that fixes it.
The distinction
Where the code runs
Both lanes end at the same mailbox and both use the same twenty-eight tools. The only thing that moves is the box the server sits in.
Local server
Your computer
Runs only while that machine is on. You keep it updated. The mailbox credential sits on your disk.
Remote server
Your computer
Nothing installed, nothing to update, works from any machine you sign in on. The credential is held by whoever runs the server, which is the trade.
Side by side
The differences that matter
Ignoring the ones that only matter to whoever builds the server. These are the six a person choosing between them will actually feel.
| Local (stdio) | Remote (HTTP) | |
|---|---|---|
| Setting it up | Install a program, edit a config file with a command and arguments | Paste a URL, sign in |
| Keeping it current | Yours to do. An out-of-date server is an out-of-date server | Updated where it runs. You get the fix without doing anything |
| Using it from a second device | Install it again, configure it again, hold the credential twice | Same URL, same account |
| When the machine sleeps | The server sleeps with it | Stays up. Still does nothing until a client calls it |
| Who holds the mailbox credential | You do, on your own disk | The operator does. This is the real trade, and it is why the security page exists |
| Client support | Universal. Every MCP client speaks stdio | Widely but not universally supported. A bridge covers the gap |
The honest summary of that table
Remote wins on everything except where the key is kept, and that one exception is the whole of the argument. If you would not give a supplier a password to your mailbox, do not give one to a remote MCP server either. If you would, remote removes every other chore on the list.
The specification
What the specification says about each transport
Two transports are defined, and the wording is worth reading because most published explanations of this are describing an older revision.
stdio, the local one
In the stdio transport, the client launches the MCP server as a subprocess. The two ends communicate over the subprocess's standard streams.
MCP specification, revision 2026-07-28
A subprocess is a program started by another program. That is the entire mechanism: your AI client runs the server, then talks to it by writing lines of JSON to its input and reading lines from its output. It is a genuinely simple arrangement, which is why every client supports it.
Streamable HTTP, the remote one
The server MUST provide a single HTTP endpoint path (hereafter referred to as the MCP endpoint) that supports POST.
MCP specification, revision 2026-07-28
One address, and every request is a POST to it. The server answers either
with a plain JSON object or with an event stream scoped to that single
request. Ours is at /mcp, which is the shape the specification
uses in its own example.
Anything describing an /sse endpoint is out of date
HTTP+SSE was the transport in revision 2024-11-05 and has
been deprecated since 2025-03-26. Revision
2026-07-28 went further and removed the standalone GET
stream and protocol-level sessions from Streamable HTTP as well. Plenty
of blog posts, and some tools' own documentation, still show a URL
ending /sse and an Mcp-Session-Id header.
Neither is part of the current protocol.
How a remote server knows it is you
Over HTTP the answer is a bearer token, and the specification is blunt about what a server must do with one:
MCP servers MUST validate that access tokens were issued specifically for them as the intended audience. MCP servers MUST only accept tokens that are valid for use with their own resources. MCP servers MUST NOT accept or transit any other tokens.
MCP specification: Authorization
That rule exists to stop a server accepting a token minted for somewhere else and quietly passing it on, which is the confused-deputy problem in its most literal form. It is a reasonable thing to ask any remote MCP operator about, ours included.
Ours is the remote one, which means there is nothing to install and nothing to keep updated: a URL and a sign-in.
The workaround
If your client only speaks stdio
Some clients still only launch local servers. That is not a dead end and
it does not require waiting for them: a bridge is a tiny local program
your client starts in the ordinary way, which then talks to the remote
server on its behalf. The best known is mcp-remote, which
describes itself as connecting
an MCP Client that only supports local (stdio) servers to a Remote MCP
Server, with auth support
.
It goes in your client's MCP configuration as a command rather than a URL:
{
"mcpServers": {
"remote-example": {
"command": "npx",
"args": [
"mcp-remote",
"https://remote.mcp.server/sse"
]
}
}
}
That block is quoted from mcp-remote's own README, /sse and
all, so that it matches what you will find if you go and read it. Use
whatever URL your server actually publishes: ours is the
/mcp endpoint shown in your control panel, not the path in
that example.
Check your own client before reaching for this
Client support moves quickly and a bridge you do not need is a moving part you do not need. Your client's own settings screen is the authority on whether it takes a remote URL, and it is more current than any list on any website, including this one.
Choosing
Which one you actually want
Choose local if
You want the credential on your own disk and nowhere else, you are happy to install and update software, you use one machine, and you do not mind that it stops working when that machine does. For a developer running a filesystem or database server against their own project, local is obviously right.
Choose remote if
You want to paste a URL and be finished, you use more than one machine or more than one client, and you would rather somebody else kept the server patched. For mail specifically, remote also gets you the Microsoft 365 path, because that needs an OAuth application registered with Microsoft and a redirect URL that has to live somewhere.
The thing that should actually decide it
Not convenience. Ask who holds the key and what they do with it, then read the answer rather than the marketing. Ours is on the security page, including the parts that are not finished, and the eight questions worth asking any vendor are written out in full so you can put them to somebody else.
The quickest way to settle remote against local is to try the remote one, because it costs you a paste and a sign-in.
Limits
What this guide does not settle
-
Which clients qualify
It does not say which clients support remote servers today. That list would be wrong within weeks and your client's own settings are more current than any table we could publish.
-
Comparing local servers
It does not compare specific local mail MCP servers. We build a remote one, so we are the wrong people to review the alternatives.
-
Self-hosting
It does not cover self-hosting. Running your own remote server is a real option and it is not one we can write about neutrally.
-
This dates quickly
Protocol detail is accurate as at revision 2026-07-28 and this is the third transport arrangement in two years. Check the specification rather than trusting the date on this page.
What is the difference between a remote and a local MCP server?
A local server is a program on your own machine that your AI client launches as a subprocess and talks to over its standard input and output. A remote server is a URL your client calls over HTTPS. Nothing else about the protocol changes: the same tools, the same calls, the same results.
Do I have to install anything?
Not for a remote server. You paste a URL into your client's settings and sign in. A local server is the opposite: you install it, you keep it updated, and it only works while that machine is on.
My client only supports local servers. What now?
Use a bridge. mcp-remote is a small program your client launches locally which then talks to the remote server on its behalf, so a stdio-only client gets a remote server without either side changing. Its own README describes it as connecting "an MCP Client that only supports local (stdio) servers to a Remote MCP Server, with auth support".
Is a local MCP server more private than a remote one?
For some servers, genuinely yes: a local filesystem server never sends your files anywhere. For mail it is a weaker argument than it looks, because a local mail server still opens an authenticated connection to Gmail or Microsoft and your messages still cross the internet. What changes is who holds the credential, not whether the mail travels.
Does a remote server work when my laptop is closed?
The server does. Whether anything happens depends on your client, because nothing calls a tool unless a client asks it to. A remote server is available at three in the morning; it is not doing anything at three in the morning.
Why do some setup guides show a URL ending in /sse?
Because they were written against an older revision. HTTP+SSE was the 2024-11-05 transport and has been deprecated since 2025-03-26. The current arrangement is a single endpoint, commonly /mcp, that accepts POST and may answer with an SSE stream scoped to that one request. Some tools and their documentation still show /sse.
Attribution
Sources
- MCP specification: stdio transport The subprocess definition quoted above. Read 2026-08-26.
- MCP specification: Streamable HTTP transport The single-endpoint requirement, and the note that revision 2026-07-28 removed the GET stream and protocol-level sessions.
- MCP specification: Authorization The bearer-token audience rules quoted in full.
- mcp-remote The bridge for stdio-only clients. Its README is the source of both the description and the configuration block.
Keep going
Read next
Ours is the remote one.
A URL and a sign-in, nothing installed. 5 calls a day free on any mailbox, so you can find out whether remote suits you before paying for it.