Remote vs Local MCP Servers: Which Should You Use?

What each one is

Local MCP server

A local server is a program on your own machine. Your AI client starts it as a subprocess and talks to it through standard input and output. That is the stdio transport in the MCP spec.

A typical example is the official Filesystem server. In Claude Desktop, you add it to a config file called claude_desktop_config.json with a command such as npx and a list of folders it may use. Many local servers need Node.js or Python installed.

Key trait: it runs with your user permissions and can reach things only your machine can reach.

Remote MCP server

A remote server runs as its own service. It has a single endpoint, such as https://example.com/mcp. Clients send messages to it with HTTP POST. That is the Streamable HTTP transport.

A remote server can serve many users at once. You connect by pasting its URL into your AI client and signing in, often through OAuth.

Key trait: nothing to install. Any client with an internet connection can use it.

What about SSE?

Older guides mention an HTTP+SSE transport. The spec replaced it with Streamable HTTP in protocol version 2025-03-26. Streamable HTTP can still use Server-Sent Events for streaming replies. Some clients, like Cursor and ChatGPT, still accept old SSE servers for backward compatibility. New servers should use Streamable HTTP.

Remote vs local MCP server at a glance

How it works

The MCP architecture is the same in both cases. Your AI app (the host) creates one client per server. Only the transport changes.

The local flow

1. You add a command to your client's config file.
2. The client starts the server process when it launches.
3. They swap JSON-RPC messages over stdin and stdout.
4. Credentials come from environment variables you set. The spec says stdio servers should not use the OAuth flow and should read credentials from the environment instead.
5. When you quit the client, the server stops.

The remote flow

1. You paste the server URL into your client.
2. The client sends a request. The server replies "401 Unauthorized" with a pointer to its auth metadata.
3. The client runs an OAuth 2.1 flow with PKCE. You sign in and approve access in a browser.
4. The client gets an access token tied to that one server.
5. Every request after that carries the token in the Authorization header.

The authorization spec also bans token passthrough. The MCP server must use its own credentials when it calls an upstream API like Shopify.

One detail people miss

Web clients reach remote servers from the vendor's cloud, not from your laptop. Claude's help center says Claude connects to custom connectors "from Anthropic's cloud infrastructure, rather than from your local device". So a server on localhost will not work as a Claude web connector. It must be reachable on the public internet.

Examples: which one fits

Pick a local server when

• You work with files on your machine. Sorting downloads, reading a local folder, editing docs.
• You are coding. Git, test runners, a local database or a browser tool inside Cursor or Claude Code.
• Data must not leave the device. Some legal, health or internal data rules require it.
• You are building and testing your own server. stdio is the quickest loop.
• The tool needs no account. A calculator or a unit converter does not need a cloud host.

Pick a remote server when

• The data already lives in a SaaS tool. Shopify orders, HubSpot deals, GA4 reports. The data is in the cloud anyway.
• A team needs the same access. One URL, one sign-in flow, no per-laptop setup.
• You use web or chat clients. ChatGPT and claude.ai can only use remote servers.
• You want secrets off laptops. A local config file often holds API keys in plain text. A hosted server keeps them server-side.
• You manage many clients or brands. Agencies need separate connections per account, not a pile of config files.

A mixed setup is normal

Many developers run both. A local server for the repo and the file system. Remote servers for Jira, Slack or the store backend. The client treats them the same way once connected.

Common misconceptions

"Local is always more secure"

Not always. A local server runs code with your user permissions. The MCP security guide warns about malicious startup commands, bad packages and data loss. Also, API keys for SaaS tools often sit in a plain-text config file. For cloud data, a trusted remote server with OAuth can be the safer choice.

"Remote means my data is stored somewhere new"

It depends on the provider. A remote MCP server passes requests to the upstream API. It does not need to keep a copy of your data. Check the provider's data and logging policy.

"Local servers cannot use HTTP"

They can. A local server can run Streamable HTTP on localhost. The spec then says it should bind to 127.0.0.1 only and must check the Origin header to block DNS rebinding attacks. stdio is still the simpler choice for local use.

"SSE and Streamable HTTP are the same thing"

No. The old HTTP+SSE transport used two endpoints. Streamable HTTP uses one endpoint and can use SSE for streaming when needed. HTTP+SSE is deprecated.

"Every client supports both types"

No. Desktop and IDE clients like Claude Desktop and Cursor support both. Web clients like ChatGPT support remote servers only. Check your client before you choose.

How to get started

Starting with a local MCP server

1. Install the runtime the server needs, often Node.js or Python.
2. Open your client's MCP config. In Claude Desktop that is Settings, then Developer, then Edit Config.
3. Add the server command and its arguments.
4. Give it access only to the folders or systems it needs.
5. Restart the client and check that the tools appear.

Starting with a remote MCP server

You can use a vendor's own remote server, host one yourself, or use a hosted MCP platform. Self-hosting means you run the server, handle OAuth, and keep it up. A hosted platform does that part for you.

With PopMCP, the steps are:

1. Create a workspace for your business, brand or client.
2. Connect a provider from the MCP server catalog, such as Shopify or HubSpot. You authorize once.
3. Copy your MCP URL. Every account uses the same one, https://app.popmcp.com/mcp, over Streamable HTTP.
4. Add it to your client and approve the PopMCP sign-in. Follow the Claude setup guide. ChatGPT custom connectors, Cursor, Codex, Windsurf, Zed and other remote-capable clients also work.
5. Try a read first. Writes run as soon as the model calls them, so confirm it reads the right account.

Provider credentials stay in PopMCP, encrypted at rest with AES-256-GCM. They are never sent to the AI client. The client signs in to PopMCP with OAuth and only reaches the connectors you approve.

To be clear on fit: PopMCP covers business tools, not your local files or Git repo. Keep a local server for those. For more on the basics, read MCP vs API.