Local vs remote MCP servers
Every MCP server runs in one of two places: as a program on your own machine, or as a service somewhere else that your client reaches over HTTP. The protocol supports both, and the choice decides something that matters more than convenience — whether your data and credentials ever leave your computer.
Side by side
| Local | Remote | |
|---|---|---|
| How it starts | Your client launches it as a subprocess and talks to it over standard input and output. | It's already running somewhere else; your client sends HTTP requests to a single endpoint. |
| Where your data goes | Nowhere. Requests, results and credentials stay on your machine. | To the operator. Your queries and any tokens you configured travel to their infrastructure. |
| What it can reach | Anything your user account can — your files, your local databases, your SSH config. | Only what the operator exposes. It cannot see your filesystem at all. |
| Setup cost | A config entry, plus whatever runtime the server needs (Node, Python) present on your machine. | A URL and usually an account. Nothing to install, nothing to keep updated. |
| Who you trust | The author of the code you're executing. | The author and the operator — their uptime, their logging, their handling of your data. |
| Across devices | Set up separately on each machine, and state doesn't follow you. | Same server from anywhere, shared state included. |
Which should you pick?
Go local when…
Choose local when the data is already on your machine or is sensitive enough that you'd rather it stayed there — filesystem access, a local database, anything under NDA. It's also the right default for anything experimental: a local server you stop trusting is a config line you delete.
Go remote when…
Choose remote when the thing you're connecting to lives in the cloud anyway. A hosted server for a SaaS product isn't sending your data anywhere it wasn't already going, and it removes the runtime, the updates and the credential handling from your machine entirely.
The security trade-off
- A local server is code you execute
- It runs with your privileges, so a bad one can do anything you can. The upside is that nothing it touches leaves your machine, and stopping it is immediate.
- A local HTTP server can be reached from the web
- If a server listens over HTTP on your machine rather than using stdio, a website you visit can attempt to talk to it through DNS rebinding. The protocol requires such servers to validate the Origin header and recommends binding to 127.0.0.1 only — worth confirming before running one.
- A remote server sees everything you send it
- Every request and every credential passes through the operator's systems and possibly their logs. That's an acceptable trade for a vendor hosting their own product, and a much larger one for an unfamiliar operator.
- Remote servers can change under you
- The operator can update behaviour, tools and permissions without you reinstalling anything. Convenient for fixes, but it means the thing you audited isn't necessarily the thing running tomorrow.
Self-hosting: the third option
There's a third option people reach for: running a server yourself on your own infrastructure. That gets the multi-device convenience of remote with the trust profile of local, at the cost of becoming the operator — which means you inherit the protocol's requirements for HTTP servers, authentication and Origin validation included.
Frequently asked questions
›Are most MCP servers local or remote?
Local is still the norm. The protocol tells clients they should support the stdio transport wherever possible, and the majority of published servers are distributed as a command your client runs — which is why most install instructions you'll meet are a config entry rather than a URL.
›Can one server be run both ways?
Often, yes. Plenty of servers ship both a command you can run locally and a hosted endpoint, and some let you self-host the same code. The tools it offers don't change — only where it runs and who can see the traffic.
›Do local MCP servers work offline?
The connection between your client and the server does, since it's just a subprocess on your machine. Whether the server is useful offline depends on what it wraps: a filesystem or SQLite server keeps working, one that calls a web API does not.
›What transport do remote MCP servers use?
Streamable HTTP, which the specification introduced to replace the earlier HTTP+SSE transport. It uses a single endpoint handling both POST and GET, and can optionally stream responses back using server-sent events when a server needs to send more than one message.
›How hard is it to switch from one to the other later?
For you, it's editing the config entry — swapping a command for a URL or the reverse — and restarting the client. What doesn't move automatically is state: anything the old server stored stays where it was.