Remote vs Local MCP Servers: stdio vs Streamable HTTP

Every MCP server is either local or remote, and the split is defined by its transport. A local server runs as a subprocess on the same machine as the client and communicates over stdio (standard input/output). A remote server runs as a networked service and communicates over Streamable HTTP — the HTTP-based transport the current MCP spec uses for servers reached over a URL.

That single choice cascades into everything else: how it authenticates, who can reach it, what it can access, and how much you operate. This guide walks the trade-offs so you can pick deliberately. It builds on what MCP hosting is; if you’re about to build a server, pair it with the build-an-MCP-server doc.

A local server is a program your MCP client launches — often via a command like npx -y some-mcp-server or a path to a binary — and talks to over stdio. The client writes JSON-RPC to the process’s stdin and reads responses from its stdout. That’s the whole transport.

The simplicity is real and worth respecting:

• No auth needed — the server is a child process of the client on the same machine, so the trust boundary is the OS user. There’s no network, so there’s nothing to authenticate over the wire.
• Direct local access — because it runs on your machine, a local server can touch the filesystem, local databases, a browser, git repos, OS APIs — things a remote service fundamentally can’t reach.
• Zero hosting — nothing to deploy or keep running; it starts when the client needs it and exits after.

The cost is scope. A stdio server serves exactly one machine, for whoever configured it there. It can’t be shared with a teammate without them installing it too, it isn’t reachable from a cloud assistant, and every user is their own install and their own version.

A remote server is a service listening at an HTTPS URL, speaking MCP over Streamable HTTP. Clients connect over the network, which changes the calculus entirely: one running server can serve many users and any MCP client — Claude, ChatGPT, Gemini, IDEs — without anyone installing anything.

What you gain:

• Reach — anyone you authorize can connect from anywhere, and cloud assistants that can’t launch a local process (ChatGPT, notably) can only use remote servers.
• Centralized control — one deployment to update, monitor, secure and version, rather than N installs drifting apart.
• Shared state and scale — a remote server can sit in front of shared systems and scale independently of any one client.

What it costs:

• Real authentication — a networked endpoint needs OAuth or scoped tokens, because now the trust boundary is the network, not the OS. Getting this right (and avoiding the confused-deputy and token-passthrough pitfalls in the prompt-injection guide) is the hard part.
• Hosting and operations — deployment, uptime, TLS, logging, rate limiting, incident response: the normal burden of running a public service.
• A larger attack surface — a public endpoint is reachable by more than your intended users, so security is load-bearing rather than incidental.

That tester lives at /tools/mcp-server-tester.

Neither transport is the “advanced” one; they serve different jobs, and the right answer follows the use case:

1. 1Reach for local when the server’s value is local access (your files, your repos, a browser, an OS capability), when it’s a personal developer tool, or when the data should never leave your machine. A filesystem server has no business being remote.
2. 2Reach for remote when multiple people or agents need the same server, when it fronts business data or cloud systems, or when you need it reachable from a cloud assistant like ChatGPT. Shared, networked value wants a networked server.
3. 3Expect to want both over time. A developer might run local servers for their own tooling and connect to remote servers for shared company data — the two coexist cleanly in the same client.

The honest conclusion the use cases point to — not a foregone one — is that anything you want a team or an outside agent to use ends up remote, and hosting a remote server well is genuinely hard: the transport, the auth, the scaling, the security are all load-bearing and easy to get wrong. That difficulty is precisely the gap managed MCP hosting fills — and it’s why our own platform exposes a business’s unified data as a single hosted remote endpoint with scoped keys, rather than asking every consumer to run something locally. Local isn’t wrong; it just doesn’t solve the shared-access problem, because it was never meant to.