Local vs remote MCP servers: stdio vs Streamable HTTP

Every MCP server reaches its client through a transport, and the MCP specification defines two of them. stdio is for local servers that your client starts as a program on your machine. Streamable HTTP is for remote servers that live at a URL. This guide explains how each works, how they differ on auth, latency and security, how to configure both in popular clients, and how to tell them apart on MCPpedia.

A third transport, HTTP with Server-Sent Events (SSE), was deprecated when Streamable HTTP arrived in the 2025-03-26 revision of the spec. Many clients still accept it for older servers, but new servers should use Streamable HTTP.

How stdio works

With stdio, the client launches the server as a child process, usually with a command such as npx, uvx or docker run -i. The two sides exchange JSON-RPC messages over the process's standard input and output, one message per line. Anything the server wants to log goes to standard error.

Two consequences follow:

• Stdout is reserved for the protocol. A stray print or console.log corrupts the stream. This is one of the most common reasons a local server fails, and it's covered in the troubleshooting guide.
• The server lives and dies with the client. It starts when the client connects, runs with your user's permissions, and stops when the client closes it. Only that one client can talk to it.

How Streamable HTTP works

With Streamable HTTP, the server is a web endpoint, typically a path like https://example.com/mcp. The client sends each JSON-RPC message as an HTTP POST. The server answers with a single JSON response or streams events back on the same response when an operation takes longer.

Because it is plain HTTPS, a remote server can sit behind a load balancer, serve many users, and run on the vendor's infrastructure instead of yours. Remote servers usually authenticate with OAuth, so you approve access in a browser instead of pasting a key into a file.

Side-by-side comparison

	Local (stdio)	Remote (Streamable HTTP)
Where it runs	Your machine, as your user	The operator's servers
Who starts it	Your client, as a child process	Already running at a URL
Typical install	npx, uvx, Docker, a binary	A URL in your client config
Credentials	Environment variables in your config	OAuth sign-in, or a header token
Reaches local files and networks	Yes	No, unless exposed publicly
Works offline	Yes, if the tool itself does	No
Updates	When you change the version	Whenever the operator deploys
Hosted clients such as ChatGPT	Not supported	Supported

Authentication

Local servers get credentials from their environment. The authorization part of the spec is written for HTTP transports. It says stdio implementations should not follow the OAuth flow and should read credentials from the environment instead. In practice you put an API key in the server's env block, ideally as a variable reference rather than a literal secret.

Remote servers use OAuth 2.1. The client discovers the authorization server from the MCP server's metadata, opens a browser for you to sign in, and stores the token. Many servers also accept a static bearer token in an Authorization header, which is simpler for automation but means a long-lived secret sits in a config file. Read the scopes on the consent screen, and see the security best practices guide for what to grant.

Latency and reliability

We aren't aware of a neutral benchmark comparing the two, so here are the mechanics rather than numbers.

• stdio has no network hop between client and server, but the process has to start. The first run of an npx or uvx server may download the package, which can take long enough to hit a client's startup timeout.
• Streamable HTTP adds a network round trip to every call, plus OAuth discovery the first time you connect. Once connected there is nothing to install or start.

For servers that wrap a third-party API, the API call usually dominates either way. Reliability differs more than speed. A local server breaks when your PATH, Node version or environment is wrong. A remote one breaks when the network or the operator's service is down.

Configuring each kind

The config shape differs by client. In Claude Code, choose the transport with a flag:

# Remote server over Streamable HTTP
claude mcp add --transport http notion https://mcp.notion.com/mcp

# Local server over stdio
claude mcp add --env API_KEY=YOUR_KEY --transport stdio example -- npx -y example-mcp-server

In Cursor's mcp.json, a remote entry has a url and a local entry has a command:

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

VS Code uses .vscode/mcp.json with a top-level servers key and an explicit "type": "http" for remote entries. Claude Desktop runs local servers from claude_desktop_config.json and adds remote servers as connectors in its settings. ChatGPT accepts remote URLs only. The client pages list the file and format for each app, and the step-by-step guides for Claude Code and Cursor go further.

If a client can only start local commands, the mcp-remote package can bridge it to a remote URL. Most current clients connect to URLs natively, so use the bridge only when you have to.

How MCPpedia marks remote servers

Every listing records whether the server has a hosted endpoint, an installable package, or both.

• The Remote badge. A globe badge on cards and server pages means the listing has a remote endpoint.
• The remote list. Remote MCP servers collects every listing you can install with a URL, which is what ChatGPT and other hosted clients need.
• The Transport filter. In the directory, the Transport filter splits listings into Remote (a URL only), Local (no remote endpoint) and Hybrid (both).
• The install panel. For a remote server it generates a URL-based config for each client. For a local one it generates the command, arguments and environment variables.

Each server page's FAQ also answers whether that server supports remote connections, and over which transport.

Which should you choose?

1. The tool needs your machine: files, a local database, a browser, a device on your network. Use a local server.
2. A vendor runs a server for a service you already use: Notion, Linear, Sentry and Atlassian all do. Prefer the vendor's remote server over a community wrapper.
3. You need offline use or a private network: local.
4. You use ChatGPT or another hosted client: remote is the only option.
5. You manage a team: remote servers are easier to approve, update and revoke centrally. For local ones, pin versions and allow-list exact commands.
6. You're publishing a server: offer both if you can. A package for local use plus a hosted URL covers every client.

Neither kind is safer by default. A local server runs code as you. A remote server sees the data you send it. Our blog post on remote vs local MCP servers looks at how the directory splits between the two.