Remote vs Local MCP Servers: Which Should You Run?
Short answer: run a local MCP server over stdio when the tool needs your machine (your files, your shell, your local repos), and a remote MCP server over Streamable HTTP when the tool lives in the cloud anyway or more than one person needs it. Most working setups end up with a few of each, but the pull is clearly toward remote, and the MCP v2 spec leans into that.
If you are still fuzzy on the basics, read [what an MCP server actually is](/blog/what-is-an-mcp-server) first. This post assumes you know the client and server picture and want to decide where the server should live.
What local and remote actually mean
A local MCP server is a process your MCP client launches on your own machine and talks to over stdin and stdout. That is the stdio transport. No network hop, no port, no sign-in handshake. When the client exits, the server exits with it.
A remote MCP server runs somewhere else, usually on the vendor's infrastructure, and your client talks to it over Streamable HTTP at a plain URL. Authentication is typically OAuth, and the server keeps running whether your client is open or not.
Same protocol, same tools list, same call semantics. The only difference is where the process lives, and that one difference drives everything below.
Where a local MCP server wins
- Your filesystem. Reading and writing files on your laptop is the canonical stdio job. A remote server cannot see your disk, and you would not want it to.
- Dev tools. Git, test runners, linters, local databases, build scripts. These live on your machine, so the server that drives them should too.
- Privacy and latency. Data never leaves the machine, and there is no network round trip on any call.
- Offline work. A stdio server does not care whether you have a connection.
The costs are operational. You install the server on every machine that needs it, you keep a Node or Python runtime at the right version, your JSON config drifts between your laptop and your desktop, and updates are on you. Worse, API keys for stdio MCP servers usually end up sitting in plain-text config files.
Where a remote MCP server wins
- SaaS tools. Your CRM, helpdesk, or issue tracker already lives in the cloud. A remote server sits next to the data instead of proxying it through your laptop.
- Zero install. You paste a URL into your client. No runtime, no npm, no version skew.
- One version for everyone. The vendor operates the server, and every user connects to the same current one.
- Real auth. OAuth sign-in with scoped, revocable tokens instead of a key pasted into a config file.
- Clients that cannot spawn processes. Web-based and mobile agents cannot launch a subprocess. Remote is their only option.
The costs: you need a network connection, you extend trust to whoever hosts the server, and a badly run remote endpoint is a security surface a local process is not.
Remote vs local MCP servers: the decision table
| Your situation | Run | Why |
|---|---|---|
| Files on your own machine | Local (stdio) | Only a local process can see your disk |
| Git, tests, builds, local databases | Local (stdio) | The tools themselves are local |
| A SaaS tool (CRM, helpdesk, tracker) | Remote (Streamable HTTP) | The data is already remote, OAuth beats pasted keys |
| A whole team on the same tools | Remote | One URL, one version, per-user sign-in |
| A web or mobile agent client | Remote | It cannot launch subprocesses |
| Offline or air-gapped work | Local (stdio) | No network required |
| No appetite for maintaining runtimes | Remote | Nothing to install or update |
Or keep the one-liner: local for what is on the machine, remote for everything else.
The ecosystem is moving remote
Two signals stand out. First, vendors increasingly ship a hosted MCP endpoint instead of an npm package you run yourself, because a URL is easier to support than a thousand slightly different local installs. Second, the spec itself: Streamable HTTP superseded the older SSE-based remote transport, and MCP v2, final since July 28, 2026, is stateless-first. Requests are designed to carry what they need, so servers can run on serverless infrastructure and scale horizontally without sticky sessions. That is a spec written with remote deployment in mind. [What changed in MCP v2](/blog/what-is-mcp-v2) covers the details.
Local is not going away. Files and dev tools are local by nature, and stdio remains in the spec. But the default for anything SaaS-shaped is now a URL, not an install.
If you want to try a remote server right now, our directory server at https://mcp.tulimoa.com/mcp is Streamable HTTP with authless read access. One line, claude mcp add --transport http tulimoa https://mcp.tulimoa.com/mcp, and your agent can search the whole catalog with no account. The [MCP explainer page](/mcp) documents all five tools.
One warning before you go collecting URLs: every server you add injects its tool schemas into your agent's context, and ten remote servers connect as easily as one. That is exactly how tool catalogs bloat. We wrote up [how many MCP servers is too many](/blog/how-many-mcp-servers-is-too-many) if you are heading that way.
Frequently asked questions
Is stdio deprecated in MCP v2?
No. stdio is still part of the spec and local servers still speak it. The stateless-first changes in v2 make remote servers easier to build and scale; they do not remove local ones.
What is Streamable HTTP in MCP?
The current transport for remote MCP servers. The client sends JSON-RPC over ordinary HTTP POSTs to a single endpoint, and the server can stream a response back when a call takes time. It replaced the earlier HTTP plus SSE arrangement, which needed a separate long-lived event stream.
Can I run local and remote MCP servers at the same time?
Yes, and most real setups should. Clients treat every connected server the same regardless of transport, so a filesystem server over stdio and a CRM server over Streamable HTTP sit side by side in one tools list.
Do remote MCP servers always require sign-in?
No. Auth is decided per server, and sometimes per tool. Tulimoa's directory server, for example, answers its three read tools without any account and only asks for OAuth on the two write tools.