Local vs remote MCP servers: which should you run?

A local MCP server runs as a process your AI client starts on your own machine, usually with one line in a config file. A remote server runs somewhere else, at a URL, and your client connects over the network. MCP calls these stdio and Streamable HTTP, its two standard transports, and the choice decides who holds the credential and what happens when something goes wrong.

The model never sees the difference. It asks for a tool and gets a result either way.

What the spec says

In stdio, "the client launches the MCP server as a subprocess" and the two talk over standard input and output. There's no network listener and no second user: whoever started the process is the only one who can reach it.

In Streamable HTTP, "the server operates as an independent process that can handle multiple client connections," reachable at a single HTTP endpoint that can also stream events back over Server-Sent Events. A vendor runs one copy, and every customer's agent connects to the same address. That's why the spec's warnings for this transport exist: it MUST validate the Origin header to prevent DNS rebinding, and if it's meant to be reached only locally it SHOULD bind to 127.0.0.1 rather than every interface. A stdio server needs neither warning, since nothing on the network can reach a process that only talks over its own stdin and stdout.

Credentials: environment variable vs OAuth

How MCP authorization works covers this in full. The short version: a local server doesn't need a login flow, since the thing starting it is the thing using it, so it reads an API key from an environment variable, set once. A remote server might answer calls from many different people, so it has to know who's calling on every request. Authorization is optional in the spec, but where a remote server does it, the spec's answer is OAuth 2.1 with PKCE and tokens bound to that one server.

Neither is a strict win. An environment variable is simple, but it's one key, good for everything the service allows, sitting in a plaintext file. Keep API keys out of your AI agent's reach covers what goes wrong when an agent that can read its own config can also read that key. OAuth adds a login screen, but a stolen token is scoped to one person and one server, and can be revoked without touching anyone else.

Isolation, updates and rug pulls

A local server runs with your client's own privileges on your machine. The spec's security best practices say a malicious one gets "arbitrary code execution" with "no visibility" into what ran, and a legitimate server that turns bad in an update carries the same risk. How to sandbox an AI agent covers running one in a container with a scoped filesystem mount and no ambient credentials, the spec's own recommendation.

A remote server fails differently: it runs on the vendor's infrastructure, outside your blast radius, so you're trusting their isolation instead of yours, and a bug that leaks data between their customers isn't one you can contain from your side.

Updates follow the same split. A local server is a version you installed and it changes only when you update it, so pinning it is deliberate. A remote server updates on the vendor's schedule, and every connected client gets the change the moment it ships. What is an MCP rug pull? covers how a tool's description or behavior can change after approval on either transport, since neither one forces a client to re-approve it.

Team sharing and audit

A local server is per machine. If three people need the same Jira server, each pastes the same API key into their own config, with no shared view of who called what, since each copy is a separate process with its own log, if it logs at all.

A remote server is built for this: one instance, reachable by everyone's client, with OAuth telling it who's calling, so access and revocation happen per person. That's where a gateway earns its place too: something has to decide which agent can call which tool, and keep one audit trail across all of them, since a server's own logs usually show the gateway's identity, not each caller's.

Latency and offline use

A local server calls over stdio on the same machine, so there's no network hop before it reaches the service it wraps, and it keeps working without a connection beyond whatever that underlying call needs. A remote server adds at least one network round trip, usually two: client to server, then server to the API behind it, and it needs a live connection just to list its tools. For a filesystem tool called in a tight loop, you'll notice. For an occasional ticket lookup, it rarely matters.

A worked example

An engineer wants an agent that reads files in a local repository and files tickets in the team's Jira. The filesystem tool fits stdio: it only needs this one laptop's disk, there's one user, and a hosted "read my local files" doesn't make sense. It runs as a local process, scoped to that repository's directory, with no ambient AWS or database credentials in its environment.

Jira is the opposite case. Several people need it, the vendor already runs a hosted MCP server, and nobody wants one shared API key on every laptop. The team connects to Jira's remote server instead, each person signing in with their own account, so Jira's access control decides what each can see, and a leaked token is one person's problem rather than the whole team's.

Which to run

Local fits one person working on one machine, and tools that only make sense locally, like a filesystem or a local database. It's also the right default while you're just trying a server out, since there's no account to create and nothing to revoke later.

Remote fits a team sharing a SaaS API the vendor already hosts, especially when you need one place to see who called what.

Either one can sit behind a gateway rather than being reached directly. A local server stays local, but a gateway still mediates and logs the calls an agent makes to it. A remote server can be run yourself, in your own infrastructure, instead of relying on the vendor's; self-hosted MCP gateways compares the options.

No transport choice removes the need to read what a tool does before approving it, and nothing here stops a model from being talked into calling the wrong tool through prompt injection. The transport decides who holds the credential and how the server is reached. It has no say in whether the model picks the right tool.

Where Statio fits

Statio is a gateway that sits in front of MCP servers either way. On the managed plan, it can proxy a remote server you already run and connect by URL, or host servers for you. Self-hosted Statio runs the same gateway in your own cloud if the keys and logs need to stay on your side. Either way, per-tool permissions decide which agent can call which tool, and each agent gets its own identity instead of a shared key. Calls land in the audit trail. None of that replaces the per-server choices above.

Next

• How MCP authorization works (OAuth 2.1), the full flow a remote server runs.
• API keys vs OAuth for MCP servers, the credential question on its own.
• How to sandbox an AI agent and control its network egress, for running a local server safely.
• What is an MCP gateway?, for mediating either transport instead of connecting directly.
• What is shadow MCP?, what happens when either kind of server gets added without anyone else knowing.

Questions