Skip to main content

Local vs Remote MCP Servers

Short answer

A local MCP server runs on your computer. Your AI app starts it as a child process and passes messages through standard input and output, which is the stdio transport. A remote MCP server runs on a host you reach by URL and uses Streamable HTTP, where each message is an HTTP POST to one endpoint. Choose local when the server needs your files or local tools. Choose remote when the service has to work from web apps or other people's machines, and add authorization before you do.

Tested withMCP spec 2026-07-28Checked 20 Oct 2026

By Tony LewisHow we test these guides

Compare the two​

Both transports carry the same protocol messages. What differs is where the server runs and who can reach it.

Local (stdio)Remote (Streamable HTTP)
How the app connectsStarts the server as a child process and writes to its stdinSends each request as an HTTP POST to one endpoint
Where the server runsOn your machine, with your user's permissionsOn a host you or a vendor runs, or on localhost if you run it yourself
Who can reach itOnly the app that started itAnyone who can reach the URL, unless the server requires authentication
Network portNoneYes, one HTTP endpoint
Config entrycommand and argsurl
Sign-inEnvironment variables or your own filesOAuth, through the spec's authorization flow

Questions that decide it​

  1. Does the server need your files, local apps or local network? If yes, it has to run locally. If it only calls a web service, the MCP security guide's advice is to prefer the remote version when one exists, because a local install adds risk without adding capability.
  2. Must web apps or other people reach it? ChatGPT on the web uses remote MCP tools through plugins, so a stdio server can't serve it. A server that a team shares usually needs to be remote too.
  3. Does it act with a user's own account? A remote server that reads or changes user data should use the spec's OAuth flow. See Authorization for MCP servers.
  4. Can you keep it running and patched? A remote server is one copy that you update in one place. Local servers are copies on every machine that installs them.

What changed in the 2026-07-28 spec​

The current spec revision made MCP stateless, and that changed Streamable HTTP in three ways:

  • The Mcp-Session-Id header is gone, the separate GET stream is gone, and SSE resumability with Last-Event-ID is gone. If a response stream breaks, the request is lost, and the client sends it again as a new request.
  • Servers no longer send their own requests to the client on either transport. When a server needs sampling, elicitation or roots, it returns an input-required result and the client retries the original call with the answers.
  • HTTP+SSE, the transport from protocol version 2024-11-05, has been deprecated since 2025-03-26 and is now classified as Deprecated. New implementations should not adopt it, and existing ones should move to Streamable HTTP.

Some apps still accept SSE endpoints so that older servers keep working. The table below shows what each app's documentation lists.

Which AI apps support which​

AppLocal (stdio)Remote (Streamable HTTP)
Claude CodeYes, with --transport stdioYes, with --transport http. SSE is also accepted but deprecated.
CodexYesYes
CursorYes, with command in mcp.jsonYes, with url. SSE endpoints also use url.
VS Code (GitHub Copilot)Yes, as a "Command (stdio)" serverYes, as an HTTP server
Gemini CLIYes, with commandYes, with httpUrl. The url key is for SSE.
Claude custom connectorsClaude Desktop only, through claude_desktop_config.jsonYes. Claude connects from Anthropic's cloud, so the URL must be public.
ChatGPT on the webNoYes, through plugins

Security tradeoffs​

Local servers run with your permissions​

A stdio server is an ordinary process running as your user. It inherits your environment variables and can read anything your account can read. The MCP local server security guide is direct about this: the stdio transport is not a sandbox. The SDKs assume full trust between the two stdio peers.

Treat a local server as code you're trusting with your account. Install it from a publisher you can identify, pin the version, and run third-party servers in a container that mounts only the directory they need. Give each server its own narrowly scoped token instead of a shared one. Sandboxing local servers walks through the container setup.

Remote servers see your requests​

The operator of a remote server receives every request and every argument you send. You're trusting that operator with the data, so check who runs the server before you connect it.

The spec says servers SHOULD implement authentication for all connections. The security best practices add that an MCP server MUST NOT accept tokens that weren't issued for it. Passing a client's token through to another API is an anti-pattern. Authorization for MCP servers covers the builder side, and common MCP vulnerabilities covers the attacks it prevents.

A server on localhost over HTTP needs checks too​

Running Streamable HTTP on your own machine doesn't make it private. A web page open in your browser can try to reach a local server through DNS rebinding. The spec says a server MUST validate the Origin header and return HTTP 403 when it's invalid, and SHOULD bind to 127.0.0.1 rather than all interfaces. The local security guide adds that binding to 127.0.0.1 is not an authentication boundary, so a local HTTP server still needs real authentication.

How to set up each one​

A local server entry names a command. A remote server entry names a URL. These two entries follow the Cursor docs' format:

mcp.json, local server
{
  "mcpServers": {
    "server-name": {
      "command": "python",
      "args": ["mcp-server.py"]
    }
  }
}
mcp.json, remote server
{
  "mcpServers": {
    "server-name": {
      "url": "https://mcp.example.com/mcp"
    }
  }
}

Each app keeps its config in a different file, and each has its own command for adding a server. The connect guides cover them one at a time: Claude Code, Cursor, Codex, VS Code and GitHub Copilot, Gemini CLI, Claude Desktop and ChatGPT.

To build a local server, follow Build an MCP server. To run one remotely, follow Deploy a remote MCP server.

Common problems​

MCP server "<name>" has a "url" but no "type" (Claude Code) Claude Code reads an entry with no type as a stdio server, and it skips the entry. Add "type": "http" for a Streamable HTTP endpoint, or "type": "sse" for an SSE endpoint.

The remote connector works from your laptop but not from Claude Claude's custom connectors connect from Anthropic's cloud, not from your machine. A localhost URL or a server on a private network can't be reached that way. Host the server at a public HTTPS URL, or allowlist Anthropic's IP addresses in your firewall.

FAQ​

Can one server support both stdio and Streamable HTTP?

Yes. Both transports carry the same protocol messages, so the tools can stay the same and only the way the server starts changes. The Python SDK runs one server over either, and its run command takes a transport option that switches to streamable-http for remote use.

Does a remote MCP server need to be on the public internet?

Not for every app. Claude's custom connectors connect from Anthropic's cloud, so that server must be reachable over the public internet. Apps that run on your computer, such as Cursor, can also use a URL on localhost.

Should I still use SSE for a new server?

No. Use Streamable HTTP for new servers. The spec deprecated the HTTP+SSE transport in 2025-03-26, but clients such as Claude Code and Gemini CLI still accept SSE endpoints so that older servers keep working.

Can ChatGPT use a server that runs on my computer?

Not on the ChatGPT web app. ChatGPT on the web uses remote MCP tools through plugins. Local Codex clients can connect to stdio servers directly.