A local MCP server runs on your own machine. A remote MCP server runs somewhere always-on, at a URL, so anything you give permission can reach it. That is the whole distinction, and almost every other difference between the two follows from it.
If you already know what an MCP server is, the local versus remote question is really a question about where the server lives and who gets to talk to it. Local is perfect for personal development. Remote is how you share a server with a team or put it in production. This post walks through the practical differences: transports, auth, access, and how to move from one to the other.
The one difference that matters
An MCP server is a program that exposes tools and data to an AI agent over the Model Context Protocol. It has to run somewhere, and that somewhere is the whole story.
A local MCP server runs as a process on your laptop. The AI client you use, an editor like Cursor or a chat app like Claude, launches it directly and talks to it on the same machine. Nothing leaves your computer. When you close the laptop, the server stops.
A remote MCP server, sometimes called a hosted MCP server, runs on a machine that stays on, at a stable network address. It does not care whether your laptop is awake. Any client you authorize, yours, a teammate's, or a production agent, can connect to the same URL and use the same tools.
Transports: stdio vs streamable HTTP
The clearest way to tell local and remote apart is the transport, the channel the client and server use to exchange messages. The Model Context Protocol defines two standard MCP server transports, and they map almost exactly onto local versus remote.
stdio is the local transport. The client starts the server as a subprocess and speaks to it over standard input and output, the same pipes a normal command-line program uses. There is no network involved. It is fast, simple, and only reachable from the one machine the process runs on. This is the default for local MCP servers.
Streamable HTTP is the remote transport. The server listens at an HTTP endpoint, and clients connect to it over the network like any other web service. It can stream responses back as they are produced, which is where the name comes from, and it is what lets a server at a URL serve many clients at once. When people talk about streamable HTTP MCP, this is the transport they mean.
So stdio vs HTTP MCP is not a style choice. stdio is for a server on your machine. Streamable HTTP is for a server other machines need to reach. Choosing the transport is choosing local or remote.
When a local MCP server is the right call
Local is the correct default more often than people expect. Reach for a local MCP server when:
- You are building or prototyping a server and want a tight edit-and-test loop.
- The tools touch things that only exist on your machine, like local files or a dev database.
- The data is sensitive and you would rather it never leave your computer.
- You are the only person, and the only agent, that needs it.
For a personal tool you use from your own editor, hosting it would add cost and moving parts for no benefit. Local wins.
When you want a remote (hosted) MCP server
You move to a remote MCP server the moment more than your own laptop needs to reach the tools. Common triggers:
- A teammate wants to use the same server from their own agent.
- A production agent, running on a server rather than your desk, depends on it.
- You want the tools available on a schedule or around the clock, not only when you are at your machine.
- Several clients or agents call it at once, and a single local process is no longer enough.
A hosted MCP server gives you one address that every authorized client shares, and uptime that does not depend on anyone's laptop. That is the difference between a tool you use and a tool your organization runs.
Authentication changes when you go remote
Auth is where local and remote genuinely diverge, and it is worth being deliberate about.
A local server over stdio needs no network authentication. The trust boundary is your machine. If someone can start the process, they are already on your computer. Secrets like API keys are usually passed in through environment variables or the client's config, and they stay local.
A remote server is reachable over the network, so it has to prove who is calling before it runs anything. Otherwise your tools are open to whoever finds the URL. The Model Context Protocol defines an authorization model for HTTP transports based on OAuth 2.1, and in practice remote servers are protected with OAuth or with bearer tokens and API keys. The rule of thumb: the instant a server leaves your machine, it needs real auth in front of it.
The migration path: local to remote
Going from local to remote is less work than it sounds, because the server logic, the tools it exposes, does not change. What changes is how it is reached.
- Switch the transport from stdio to streamable HTTP, so the server listens on a port instead of talking over stdin and stdout. Most MCP server frameworks support both, so this is often a config change rather than a rewrite.
- Add authentication, since the server is now exposed to the network.
- Run it somewhere always-on, at a stable URL, and point your clients at that address instead of launching a local process.
The third step, the actual hosting, is its own topic. We wrote a full walkthrough in how to host an MCP server, from the four things hosting requires to a deploy you can copy.
Local and remote are not competitors. They are two stages of the same server. You build and test locally over stdio, and when the tool needs to be shared or run in production, you swap to streamable HTTP, add auth, and host it. If you get to that step and want somewhere to put it, Scalix Run hosts long-running services like remote MCP servers at a stable URL any authorized agent can reach. But start local. The move to remote is easy once you need it.
Top comments (0)