Remote vs local MCP servers: how to choose

MCP supports two standard transports: stdio and Streamable HTTP. The transports page (spec 2026-07-28) says protocol semantics are identical on every transport. A transport is just a binding for framing and delivery.

'MCP server' refers to the program serving context regardless of where it runs. A server launched on the same machine via stdio is commonly called 'local'. One hosted on a platform (the page cites the Sentry MCP server) using Streamable HTTP is commonly called 'remote'.

The architecture page says local stdio servers typically serve a single MCP client, whereas remote Streamable HTTP servers typically serve many clients.

In stdio, the client launches the MCP server as a subprocess. The server reads newline-delimited JSON-RPC from stdin and writes to stdout, and may log to stderr. The architecture page says stdio provides optimal performance with no network overhead and is for local processes on the same machine.

The stdio transport has no header layer. Protocol version, capabilities and optional client identity travel in the JSON-RPC body's _meta fields. Shutdown is by closing the server's stdin, then waiting, then force-terminating if needed. If a stdio server process exits unexpectedly, the client should restart it; because the protocol is stateless, in-flight requests are lost and can be retried.

The local-server guide says local MCP servers are programs running on your computer. In Claude Desktop they are configured in claude_desktop_config.json under mcpServers with a command and args (e.g. npx), and the example needs Node.js. Secrets can be passed through an env key in the config.

The remote-server guide says remote servers are hosted on the internet, available from any MCP client with a connection, and need no per-device install. In Claude they are added as Custom Connectors by entering the server URL and then completing authentication.

In Streamable HTTP the server exposes a single HTTP MCP endpoint that accepts POST. Each JSON-RPC message is its own POST, and the server replies with either a single JSON object or a request-scoped Server-Sent Events stream.

Every Streamable HTTP POST must carry an MCP-Protocol-Version header plus Mcp-Method (and Mcp-Name for tools/call, resources/read, prompts/get), mirrored from the body so gateways and load balancers can route without parsing it.

Streamable HTTP was introduced in protocol version 2025-03-26, replacing the 2024-11-05 HTTP+SSE transport, which is now classified Deprecated (new implementations should not adopt it). Revision 2026-07-28 removed the GET stream endpoint and protocol-level sessions. Older revisions used the Mcp-Session-Id header and resumable streams via Last-Event-ID, which this revision ignores.

Authorization is optional in MCP. The auth spec defines its flow for HTTP-based transports, where implementations should conform to it. For stdio, the authorization page says implementations should not follow the OAuth spec and should instead retrieve credentials from the environment.

The architecture page says Streamable HTTP supports standard HTTP authentication such as bearer tokens, API keys and custom headers, and that MCP recommends OAuth for obtaining tokens. The remote-server guide says most remote servers require authentication, commonly OAuth, API keys or username/password.

In the auth spec a protected MCP server acts as an OAuth 2.1 resource server and the MCP client as an OAuth 2.1 client. The authorization server may be hosted with the resource server or separately. MCP servers must implement OAuth 2.0 Protected Resource Metadata (RFC 9728), and clients must use it to discover the authorization server. An unauthenticated request gets HTTP 401 with a WWW-Authenticate header pointing at the metadata.

Clients must send the RFC 8707 resource parameter in both authorization and token requests, use PKCE, and send tokens in the Authorization: Bearer header on every HTTP request (never in the query string). Servers must only accept tokens issued for themselves. For client registration, authorization servers and clients should support OAuth Client ID Metadata Documents; Dynamic Client Registration is deprecated and retained only for backwards compatibility.

The 'Local MCP Server Compromise' section warns that local servers run with the user's privileges and can execute arbitrary code. Clients with one-click setup must show the exact command and get explicit consent, and should sandbox servers with minimal default privileges.

The local-server guide warns that a local server runs with your user account permissions and can do any file operation you can, so only grant access to directories you are comfortable with. Servers intended to run locally should limit access by using stdio, or if using HTTP should require an authorization token or use unix domain sockets or other restricted IPC.

For Streamable HTTP, servers must validate the Origin header on all connections (403 if invalid) to prevent DNS rebinding. They should bind only to localhost (127.0.0.1) when running locally, and should implement proper authentication. For remote servers, the remote guide advises verifying a server's authenticity, connecting only to trusted sources and reviewing requested permissions.

Security best practices forbid token passthrough: an MCP server must not accept tokens that were not explicitly issued for it, and proxy servers that front third-party APIs must implement per-client consent to avoid the confused deputy problem. They also cover SSRF in OAuth discovery: clients should require HTTPS, block private and link-local IP ranges (including cloud metadata addresses), validate redirects, and consider egress proxies.

The sources do not name a winner, and this page does not either. The protocol is the same on both transports; what differs is how each is installed, how it signs in and what you are trusting.

A local server is launched on the same machine via stdio, typically serves a single client and runs with your user account permissions. A remote server is hosted on the internet, typically serves many clients, needs no per-device install, and most require authentication.

On the trust side, the local-server guide says a local server can do any file operation you can. The remote-server guide advises connecting only to trusted sources.