Local or remote MCP? The decision most people get backwards
Remote MCP sounds modern, so people reach for it. The data and the tradeoffs both say: default to local, and go remote only for specific reasons.
When people choose between a local (stdio) MCP server and a remote (HTTP/SSE) one, they often pick remote because it sounds more modern. That's backwards. Let me make the case for the boring default.
What the split actually is
In this directory, 90% of servers are local stdio, 8% remote HTTP, 2% SSE. That's not the ecosystem lagging — it's builders being correct about the common case.
A local server runs as a process on your machine (npx, uvx, docker). It can touch your filesystem, reuse the CLIs you're already logged into, and — critically — it sends nothing to anyone. A remote server is a hosted URL you connect to. Someone else runs it; your requests and often your data leave your machine.
Default to local. Here's why.
- Privacy by construction. A local server that reads your repo and sends nothing outbound has a tiny attack surface. With a remote server you're trusting a third party with whatever passes through.
- No new auth. Local servers piggyback on credentials you already have. Remote servers usually mean another API key or OAuth grant — another thing to scope and rotate.
- It's free and it's yours. No hosted dependency to go down, rate-limit you, or start charging.
For the single-developer, single-machine case — which is most cases — local is simpler and safer. That's a rare combination, and it's why stdio dominates.
When remote genuinely wins
I'm not anti-remote. There are real reasons to choose it, and they're specific:
- Sharing across a team. Getting five people to each install, configure and authenticate a local server is painful. A hosted server everyone points at is the honest fix. This is the single best reason to go remote.
- Heavy infrastructure you don't want to run. A managed browser farm with proxies and anti-bot handling, a hosted vector store, a scraping API — things that are a pain to operate locally. Let someone else.
- The vendor only ships remote. Increasingly the official server is a hosted endpoint (Atlassian, several others). Then the choice is made for you.
The honest decision rule
Ask one question: does this need to be shared or hosted? If yes, remote. If no — and for most personal setups the answer is no — local is the better default, full stop. "Remote sounds more modern" is not a reason; it's a vibe, and it usually costs you privacy and an extra credential for convenience you didn't need.
One nuance for Claude Desktop users: it has no native remote transport, so remote servers are bridged through the mcp-remote proxy. It works, but it's another moving part — one more reason that, all else equal, local is the calmer choice.
The summary: the 90% aren't behind the curve. They're right. Reach for local by default and switch to remote only when sharing or heavy infrastructure forces your hand.