Remote vs local MCP servers
Esta página aún no está disponible en tu idioma.
What is the difference between a remote and a local MCP server?
Section titled “What is the difference between a remote and a local MCP server?”A local MCP server runs as a process on your own machine. Your MCP client
talks to it over stdio or over HTTP bound to 127.0.0.1. Nothing leaves the
machine, and nothing outside the machine can reach it.
A remote MCP server is a service on the public internet, reached over HTTPS at a real domain, with OAuth deciding who gets in.
Both speak the same protocol. An MCP client cannot tell the difference at the tool level. The difference is entirely about where the server is, and that single fact decides what is possible.
The comparison
Section titled “The comparison”| Local MCP server | Remote MCP server | |
|---|---|---|
| Address | stdio or 127.0.0.1:port | https://example.com/mcp |
| Auth | Local bearer token, or none | OAuth 2.1, usually with PKCE |
| Reachable from a phone | No | Yes |
| Reachable from a browser client | No | Yes |
| Reachable from a second computer | No | Yes |
| Works when your machine is asleep | No | Yes |
| Data leaves your machine | No | Yes, to that server |
| Setup | Edit a JSON config file | Click connect, approve in a browser |
| Listable in vendor connector directories | Generally no | Yes |
Why a desktop app can use local servers and a browser cannot
Section titled “Why a desktop app can use local servers and a browser cannot”This is the part that surprises people, so it is worth being precise.
A desktop MCP client (Claude Desktop, Cursor, Cline, and similar) runs on your
computer. It can spawn a child process and talk to it over stdio, or open a
socket to 127.0.0.1. Both are ordinary things for a local application to do.
A browser client cannot. When you use claude.ai or ChatGPT on the web, the
thing that would need to reach your MCP server is not the browser tab, it is
the vendor’s servers. Those are somewhere else entirely, and 127.0.0.1 from
their perspective means their loopback, not yours. There is no configuration
that fixes this. It is what loopback means.
The same logic applies to your phone. Your phone’s 127.0.0.1 is your phone.
What this means for connector directories
Section titled “What this means for connector directories”Anthropic’s remote connector directory requires a public HTTPS endpoint with OAuth 2.0 and PKCE. Loopback hosts are explicitly not eligible, because the review process has to be able to reach your server and so does every user who installs it.
Local servers can ship as desktop extensions instead, which install into a desktop client. That works, and it keeps the same ceiling: desktop only, that machine only, application open.
So when you notice that a category of tool is missing from a remote connector directory, the usual reason is not that nobody built one. It is that the servers which exist are local by design and cannot apply.
Which should you use?
Section titled “Which should you use?”Use a local MCP server when the data should never leave the machine, you work at one computer, and you are content for the tool to be available only while that computer is awake and the host application is running. Local is the correct answer for a lot of workflows and it costs nothing.
Use a remote MCP server when you want the same context from a phone, a browser, or a second machine, or when the data needs to keep being available while your laptop is closed.
The tradeoff is real and it is not a trick question: local buys you absolute data locality, remote buys you reach. You are choosing which one you need.
How Engram handles it
Section titled “How Engram handles it”Engram is a remote MCP server at mcp.engram.page, using OAuth 2.1 with
Dynamic Client Registration, so a client can register and connect without you
pasting credentials into a config file. That is what lets your AI answer from
your notes on your phone, in a browser, with your laptop shut.
If you want the locality property instead, the answer is not a different protocol, it is a different host. Self-host Engram and the remote server becomes your server, on your hardware, on your network. Same code, same protocol, same clients. You keep the reach and you keep the data.
That combination is the reason self-host exists in the product rather than as a marketing checkbox: it is the only way to offer both halves of a tradeoff that is otherwise genuinely exclusive.