Remote vs local MCP servers: stdio, Streamable HTTP, and which one your team should use
A local MCP server runs on your machine over stdio; a remote one is a URL over Streamable HTTP with OAuth.
On this page
A local MCP server runs on your own machine: the AI app launches it as a subprocess and talks to it over standard input and output, with credentials read from environment variables. A remote MCP server lives at an HTTPS URL, speaks the Streamable HTTP transport, and signs each person in with OAuth. Use local for your own files and your own API keys; use remote for anything shared by a team or sold as a product.
That is the decision in one paragraph. The rest explains the two transports as the specification defines them, what each one implies for security and operations, how to choose, and why some servers, including ours, are remote only.
The two transports the MCP spec defines
The Model Context Protocol encodes every message as JSON-RPC. The specification (revision 2025-11-25) defines exactly two standard transports for carrying those messages, and says clients should support the first wherever possible:
- stdio. The client launches the server as a subprocess. The server reads JSON-RPC messages from standard input and writes them to standard output, one per line. It may log to standard error, and it must not write anything else to stdout.
- Streamable HTTP. The server is an independent process at a single HTTP endpoint, such as
https://example.com/mcp, that accepts POST and GET. Every client message is a POST. The server answers either with one JSON object or by opening a Server-Sent Events stream when it has several messages to send. It replaced the older HTTP+SSE transport from the 2024-11-05 revision, which is now deprecated.
"Local" and "remote" are the everyday names for those two. A local server is almost always stdio; a remote server is always Streamable HTTP. You can run a Streamable HTTP server on localhost, and the spec notes that such servers should bind only to 127.0.0.1, but the common shapes are the two above. The transports section of the spec has the full rules; the glossary entry on remote servers is the shorter version.
How a local server works
You install something, usually a small program in Node, Python or Go, and add it to your AI app's configuration with the command to run it. When the app starts, it spawns the process. The server typically reads an API key or a database path from the environment the app passes it. When you close the app, the process dies.
This is the original shape of MCP, and it is still the right one for a large class of servers:
- A filesystem server that reads the folders you point it at.
- A database server with a connection string you keep in your shell profile.
- A wrapper around a CLI tool already installed on your machine.
- Anything you are prototyping in an afternoon.
Its strengths are simplicity and locality. There is no network, no TLS certificate, no login, and no multi-tenancy: the server serves one person, the one who launched it. The spec says stdio servers should not use the OAuth authorization flow at all and should take credentials from the environment instead.
Its weaknesses are the same facts seen from a team's side. Every person installs and updates their own copy. Every copy needs its own key. A key in a config file on a laptop is a key that can be copied, committed by accident, or left behind when someone leaves. And nothing central knows who called what.
How a remote server works
A remote server is a web service. You add it to your app by URL. On the first call the server answers 401 Unauthorized with a pointer to its metadata; the app discovers the authorization server, opens a browser, you sign in and approve a set of scopes, and from then on every request carries a bearer token in the Authorization header. The MCP client inside the app handles that whole dance; a person just sees a consent screen.
Streamable HTTP adds a few mechanics you will notice as a user or an operator:
- Sessions. A server may return an
MCP-Session-Idheader at initialization, and the client must then send it on every request. The server can end the session at any time, after which the client starts a new one. - Streaming. For a long tool call the server can open an SSE stream, send progress notifications, and finish with the response. If the connection drops, the client can reconnect with
Last-Event-IDand the server may replay what was missed. - Origin validation. Servers must validate the
Originheader on every connection and reject bad ones with403, to stop a malicious web page from talking to a server through the browser. - Authentication on every call. The token goes in the header of each request, never in the URL, and the server must check it was issued for this server specifically.
The payoff is that one deployment serves everyone. Nobody installs anything. Access is granted per person, scoped to what they approved, and revocable from the server side. Every call can be audited against the person behind the token.
The cost is that you are now running a service: hosting, TLS, uptime, rate limits, tenant isolation, and an OAuth authorization server or an integration with one. For a server that only you use, that is a lot of machinery.
Remote vs local MCP server: side by side
| Local (stdio) | Remote (Streamable HTTP) | |
|---|---|---|
| Where it runs | Your machine, as a subprocess | A host you or a vendor operate |
| How the client reaches it | Launches a command | Connects to an HTTPS URL |
| Who it serves | One person per process | Many people, one deployment |
| Credentials | Environment variables, a config file | OAuth token per person, scoped and revocable |
| Installation | Each person installs and updates | None; add the URL |
| Network exposure | None | Public endpoint; needs TLS, Origin checks, rate limits |
| Audit trail | Whatever the server logs locally | Central, per token and person |
| Latency | Lowest | Network round trip |
| Good for | Files, local databases, CLIs, prototypes | SaaS products, team data, anything multi-user |
| Spec guidance on auth | Use the environment, not OAuth | OAuth 2.1 flow in the authorization spec |
Which one should you use?
Ask three questions.
Whose data is it? If the server reads your own files or a database only you touch, local. If it reads a system several people share, with records that belong to the company and permissions that differ per person, remote. A local server has no way to express "Priya can see deal values and Tom cannot"; it runs with whatever key it was given.
Who has to install it? If the answer is "me, once", local is fine. If the answer is "every teammate, and keep it updated", a remote server removes the whole chore. We have watched the local-server version of this fail inside a week: one person's config has an old key, another's has a path that only works on their machine.
What happens when someone leaves? With a local server, their key lives in a file you cannot see. With a remote server backed by OAuth, revoking their account ends every token they ever created, on the next call.
A reasonable rule for a small team: local servers for developer tooling on each person's laptop; remote servers for every product the team actually works in.
When a team should host its own remote server
Most teams will connect to remote servers that vendors run. Sometimes it makes sense to host one yourself: an internal system with no vendor, a database you want assistants to query with per-person permissions, or an API you built. Before you do, budget for the parts that are not the tools themselves:
- An authorization server. The MCP authorization spec expects OAuth 2.1 with PKCE and metadata discovery. You can run one or front the server with an identity provider that supports it.
- Token validation on every request, including checking the token was issued for your server and not for some other resource.
- Tenant isolation. A request's token must bound what it can see. Build the server so a fresh instance, or a fresh context, is created per request around that token, and nothing is cached across people.
- Rate limits and audit. One busy client should not starve the others, and you want to know afterwards who ran which tool.
- Operations. TLS, uptime, versioning the tool list without breaking clients.
If that list looks heavy for what you need, keep the server local, or wait for the vendor.
Why Atrix is remote only
Our own MCP server is a worked example of the choice. Atrix is a shared workspace: a team's projects, documents, customers, calendar and people records live in it, and what each person may see differs. A local server would have to run with one key that is as powerful as the person who created it, on every laptop, and the server could never tell who was actually asking.
So the Atrix server is a single remote endpoint, https://atrix.dev/api/mcp, over Streamable HTTP. There is no package to install. In Claude Code the whole setup is one line, claude mcp add --transport http atrix https://atrix.dev/api/mcp, followed by /mcp and Authenticate; the browser opens, you choose a workspace and approve scopes, and the client stores a short-lived access token with a rotating refresh token. The server builds a fresh instance per request around the token presented, so nothing is shared between requests or workspaces, and every call is audited by tool, outcome and subject. It exposes 85 tools and is listed in the Official MCP Registry and on Glama. The feature page covers what the tools do.
The limits are real. There is no offline mode and no way to use it without an Atrix account. Rate limits are 120 calls and 30 writes per minute per token. And because scopes can only narrow what a person may already do, an assistant connected through someone's account can never see more than that person can; if you need a server that reaches everything, that is not this one, and we think that is the right trade.
FAQ
What is the difference between a remote and a local MCP server?
A local server runs on your machine as a subprocess and talks over stdio, with credentials from the environment. A remote server runs at an HTTPS URL over Streamable HTTP, authenticates each person with OAuth, and serves many users from one deployment.
Is stdio or Streamable HTTP better?
Neither is better in general. The spec defines both and asks clients to support stdio where possible. stdio is simpler and has no network exposure; Streamable HTTP is the only option when the server is shared or hosted away from the user's machine.
Can I run a Streamable HTTP server locally?
Yes. The spec says locally running HTTP servers should bind only to localhost and must validate the Origin header to prevent DNS rebinding. It is still a less common shape than stdio for a single-user server.
Do remote MCP servers need OAuth?
The MCP authorization spec says implementations using an HTTP transport should follow it, and it is built on OAuth 2.1. Some servers accept a pasted bearer token instead, which is simpler and weaker: the token is long-lived, lives in a config file, and is not scoped by a consent screen.
What happened to the HTTP+SSE transport?
It was defined in the 2024-11-05 revision and replaced by Streamable HTTP in 2025-03-26. The current spec marks it deprecated and describes how clients and servers can stay compatible with the old shape.
Is the Atrix MCP server available locally?
No. It is remote only, at https://atrix.dev/api/mcp, because the workspace data is shared and per-person permissions have to be enforced by the server for each call.
Next step
If you are connecting an assistant to Atrix, the developer overview has the exact steps for Claude Code, Claude Desktop, ChatGPT and Cursor, and the MCP feature page lists the tools. If you are deciding how to build your own server, read the MCP client and remote MCP server entries first.