Remote vs local MCP servers: the trade nobody spells out
Local is faster and it is not free. Remote costs a hop and buys four things you would otherwise have to build yourself.
The usual framing is "local is private, remote is convenient", which is true and useless. The real difference is structural: a local server has nowhere to put the four things a serious integration needs — a credential store, a call log, an allowance, and a version gate — and a remote one has a natural home for all four.
Latency: local wins, by less than the argument suggests
A local process saves a network hop, and a hop is worth something. What it is not worth is the weight the argument usually carries, because the hop is rarely the part you are waiting for.
The exception is the tight loop: an agent making dozens of calls in sequence, where a hundred milliseconds each becomes a wall-clock problem. If that is your workload, measure it rather than reasoning about it — and note that the same loop against a remote server is precisely the case an allowance exists for.
What local genuinely wins
- Your files never leave. If the job is "read this repository and answer questions about it", nothing beats a process that already has it on disk. No transfer, no copy, no policy conversation.
- No third party at all. One fewer company in the story. For some work that is the entire requirement and everything else is negotiable.
- No monthly anything. A local server can honestly be a one-time licence, because there is no meter to run and nothing to keep serving.
- It works offline. Rarely decisive, occasionally the whole point.
What local cannot have, structurally
It cannot carry a subscription that means anything, because there is no admission point at which to check an entitlement — the process runs whether or not last month was paid. It cannot show you a call log, because nothing sits between the client and the tool. It cannot enforce an allowance, for the same reason. And it cannot gate a release: whatever version is on disk is the version holding your permissions.
The one-time licence is not a pricing preference for local servers. It is the only thing a local server can enforce.
Which is a useful lens on a listing: a local server advertising a monthly subscription is worth one question, and the question is what exactly stops working when you cancel.
What the hop buys
| Capability | Local | Remote, behind a gateway |
|---|---|---|
| Credential storage | Your disk, your problem | Brokered; the token never reaches you |
| Call log | None | Tool, key, duration, result |
| Spending ceiling | None enforceable | Refused before the call is made |
| Release gating | Whatever is on disk | New capability waits for approval |
| Revocation | Find every machine | One action, immediate |
| Latency | One hop shorter | One hop longer |
The middle case, which is the worst one
A local server holding a long-lived API key to a third-party service combines the disadvantages of both shapes: the secret is on your disk like a local server, and the blast radius is somebody else’s production system like a remote one. No log, no ceiling, and no revocation that does not involve remembering every machine.
If you have one of these — and most people do — it is worth an afternoon to check what that key can actually do. It is nearly always broader than the tools using it, because scopes are copied and rarely trimmed.
The rule
If the data is already on your machine, run it locally and stop thinking about it. If the server holds somebody else’s credential, run it remotely behind something that can log, cap and revoke. And if you are in the middle case, treat it as a temporary state rather than an architecture.