Remote vs local MCP servers: which should you run?

Use a local server when the tool needs your files, your network or your machine. Use a remote one when a vendor already runs a good server for a service you use. Neither kind is safer by default, because the risk is in different places.

That's the short version. The rest of this post explains what the two kinds are, how our directory splits between them, what each costs you, and which clients can use which.

The two kinds in a minute

A local server is a program on your computer. Your client (Claude Code, Cursor, VS Code and so on) starts it as a child process and talks to it over standard input and output, using JSON-RPC messages, one per line. Anything the server wants to log goes to standard error. This is the stdio transport, and it is why local servers are usually installed with a command like npx or uvx.

A remote server is a URL. The client sends each message to it over HTTPS, and the server answers with either one JSON reply or a stream. This is the Streamable HTTP transport. Remote servers usually sign you in with OAuth, so you approve access in a browser instead of pasting a key into a config file.

Those are the two transports in the MCP specification. There used to be a third, HTTP with Server-Sent Events, which the spec deprecated in March 2025 when Streamable HTTP arrived. You'll still see it in older server docs and some client menus. If you have a choice, pick Streamable HTTP.

The newest spec revision, 2026-07-28, simplified the remote side. It dropped the initialize handshake and protocol-level sessions, so any request can land on any server instance behind a plain load balancer. Client support for the new revision is uneven, though, so a server that still speaks the older handshake keeps working with more clients.

What the directory shows

Where each kind of server runs, and so whose permissions it has.

In our directory, a listing is remote if it has only a URL, local if it has only an install, and hybrid if it has both. Of 47,703 listings on 2 November 2026, 27,819 (58.3%) are remote, 15,612 (32.7%) are local and 4,272 (9.0%) are hybrid. The official registry looks the same: 59.1% of its active entries are remote-only, 31.7% are package-only and 8.0% have both.

The remote entries have settled on one transport. Of the registry servers that publish a remote endpoint, 97.0% use Streamable HTTP only, 2.0% use legacy SSE only and 1.0% offer both. Of the 21,259 registry servers with an installable package, 20,980 offer it as stdio.

The two groups differ in how much public evidence there is for them. Only 47.1% of remote-only registry entries link a repository, against 95.5% of package-only and 93.4% of hybrid entries. Our trust score can't see code it can't find, so remote listings score lower on it: 0.7% reach 60 or more, against 4.6% of local and 27.1% of hybrid. That is a statement about visible evidence and not about whether remote servers are worse. Many are hosted services from companies whose code isn't public. The details are in our census of the directory.

What each choice costs you

Who runs the code

A local server runs as you. The spec's security guidance says a local server can do whatever your user account can do, and recommends that clients show you the exact command and ask before starting one. A malicious or buggy local server can read your files and run programs. The usual defenses are to review the server first (see how to vet an MCP server), give it the least access that works, and sandbox it where your client supports that. VS Code, for instance, can sandbox local servers on macOS and Linux.

A remote server runs on infrastructure you don't control. It can't read your disk. But it receives everything you send it, including tool arguments and results, and whoever operates it can change it at any time, for everyone at once. So the questions shift to who the operator is, what scopes the sign-in asks for and what their terms say about your data.

Where your credentials live

Local servers normally take credentials from environment variables or config files on your machine. The spec says stdio servers shouldn't run the OAuth flow at all and should read credentials from the environment. That keeps things simple, and it also means a token sits in a config file. Claude Code's docs for its shared managed config file, for example, warn that every user on the machine can read it, so secrets don't belong there.

Remote servers use OAuth, so the client holds the token, and for hosted connectors the provider does. The server itself holds the upstream API keys. That's usually the better arrangement for secrets, as long as you trust the operator with them.

Updates

With a local server, you decide when to update. A command like npx -y some-package fetches whatever is current when it launches, which means an unpinned local server can change under you. Pin a version if you care.

A remote server updates for everyone at once. That's convenient for fixes, and it means tool descriptions and behavior can change without you doing anything.

Offline use, and speed

A local server works without a connection if the tool itself needs none. A remote one needs the network, and each call adds a round trip, plus OAuth discovery the first time. We looked for a neutral benchmark of local against remote latency and didn't find one, so we aren't going to quote numbers. For tools that mostly wait on a third-party API anyway, the difference tends not to matter.

Reaching private systems

Local is the natural fit for anything on your laptop or your company network. Hosted clients complicate remote. Claude's connectors, for example, call your server from Anthropic's infrastructure, so a server on localhost isn't reachable unless it has a public URL or goes through a tunnel. OpenAI's ChatGPT works the same way for custom servers: it needs a public HTTPS endpoint or a tunnel. If you're building a server for yourself, that's a real argument for staying local.

Admin controls

If you manage a team, both kinds can be allow-listed. Claude Code's managed settings can allow or deny servers by URL or by command, and GitHub made MCP allow-lists in Copilot's managed settings generally available on 6 August 2026. Remote servers are easier to control centrally, because a URL pattern is a simpler rule than a command line.

Which clients support which

This changes quickly, so treat it as a snapshot of the clients' own docs from early November 2026 and check the current page before you rely on a detail.

• Claude Code supports stdio and Streamable HTTP, and calls SSE deprecated.
• Claude Desktop runs local servers from its config file, and adds remote ones through Connectors in settings. Remote connectors are called from Anthropic's network.
• Cursor and VS Code both support local commands and remote URLs, and both still accept SSE for older servers.
• ChatGPT supports remote servers only.
• Windsurf, Zed, Cline, Goose and Continue document both local commands and remote URLs.

Adding one looks like this in a few of them. In Claude Code:

# remote
claude mcp add --transport http notion https://mcp.notion.com/mcp

# local
claude mcp add --env AIRTABLE_API_KEY=YOUR_KEY --transport stdio airtable \
  -- npx -y airtable-mcp-server

In Cursor's mcp.json, a remote entry is a URL and a local one is a command:

{
  "mcpServers": {
    "remote-example": { "url": "https://example.com/mcp" },
    "local-example": { "command": "npx", "args": ["-y", "mcp-server"] }
  }
}

In VS Code's .vscode/mcp.json the top-level key is servers, not mcpServers:

{
  "servers": {
    "remote-example": { "type": "http", "url": "https://example.com/mcp" }
  }
}

That key difference trips people up when they paste a config between clients. Every server page in the directory shows a copy-ready config for ten clients, and the clients pages cover each one.

A bridge for clients that can't do remote

mcp-remote is a small local program that speaks stdio to your client and forwards to a remote server, handling the OAuth sign-in on the way. It exists for clients that can only start local commands. Its own README says you can drop it once your client supports remote servers directly, and most clients now do. It is still maintained, and it is also a local program that handles your tokens, which is why the 2025 command-injection bug in it mattered (fixed in 0.1.16). If your client can connect to a URL natively, do that.

How to choose

1. The tool touches your machine. Files, a local database, a browser, a device. Run it locally.
2. A vendor runs a server for a SaaS you already use. Prefer their remote server over a community wrapper, if you trust the vendor. Sign-in through OAuth beats a pasted key.
3. You need it to work offline or on a private network. Local.
4. You manage a team. Remote servers are easier to approve, update and revoke centrally. For local ones, pin versions and allow-list the exact command.
5. The server is from an unknown author. Remote means they see your data. Local means they run code as you. Neither is a reason to skip the checks in our vetting post. If you're unsure, a remote server with narrow OAuth scopes often limits the damage better than a local one running as your full account.
6. You publish a server. Offer both when you can. A hybrid listing, with a package and a remote URL, is also the kind that has the most evidence behind it in our data.

What may change next

The spec's roadmap, last updated in August 2026, lists "HTTP over stdio" as a goal: Streamable HTTP as the one binding, spoken over standard input and output for local servers. The roadmap says it reflects current thinking and not commitments. There is also a proposal for server cards, a small JSON file describing a remote server before you connect. Its status and its URL have changed more than once, so check the current spec before building on it.

Sources

• MCP specification, transports, revision 2026-07-28
• Streamable HTTP transport and stdio transport
• Spec changelog, 2026-07-28
• Authorization
• Security best practices
• MCP roadmap
• Claude Code MCP documentation and managed MCP settings
• Claude connectors: adding a custom connector
• Cursor MCP documentation
• VS Code MCP configuration reference
• Connect ChatGPT to your MCP server
• GitHub changelog: MCP allowlists in enterprise managed settings
• mcp-remote on npm and its security advisory