Remote MCP Server vs Local MCP Server: Which Do You Need?

The MCP specification supports two fundamentally different ways to run a server: local, where the AI client spawns your server as a subprocess, and remote, where your server runs independently and the client connects to it over HTTP. They are not interchangeable, and picking the wrong one is a common source of confusion for people building their first MCP server.

Local MCP Servers: stdio Transport

A local MCP server uses the stdio transport. The AI client (Claude Desktop, for example) launches your server as a child process and communicates with it over stdin and stdout. There is no network involved.

{
  "mcpServers": {
    "my-local-server": {
      "command": "node",
      "args": ["./server.js"]
    }
  }
}

Strengths:

• Zero network setup. No HTTPS, no domain, no auth to configure.
• The server has direct access to the local filesystem and can run with the same permissions as the user.
• Simplest possible setup for tools that only ever need to run on one machine.

Limitations:

• Only works with clients that support spawning subprocesses (mainly desktop apps).
• Cannot be shared. Every user who wants your tool needs the code and its dependencies installed locally.
• No practical way to expose it to a web-based client, a mobile client, or a teammate who isn't at your machine.

Local servers are the right choice for personal tooling: a script that reads your own files, queries a database only you have credentials for, or automates something on your own machine.

Remote MCP Servers: Streamable HTTP Transport

A remote MCP server runs as an independent HTTP service with its own endpoint. Clients connect over the network instead of spawning a process.

{
  "mcpServers": {
    "my-remote-server": {
      "url": "https://your-subdomain.mcpcore.io/mcp"
    }
  }
}

Strengths:

• One server, many clients. The same endpoint can serve Claude, Cursor, ChatGPT, and any teammate you share the URL with.
• Works with web-based and mobile clients that cannot spawn local processes.
• Runs independently of any single user's machine, so it is available even when nobody's laptop is open.

Limitations:

• Requires HTTPS, and in most cases authentication, since anyone with the URL could otherwise call it.
• Needs to actually be hosted somewhere, which is either infrastructure you manage yourself or a platform that manages it for you.

Remote servers are the right choice the moment more than one person or more than one client needs access, or when the tool needs to run continuously regardless of whether your machine is on.

The Bridge: mcp-remote

Some clients, including Claude Desktop and Windsurf, use stdio natively and don't speak Streamable HTTP directly. For those, the mcp-remote package acts as a local proxy: the client spawns mcp-remote as a local process, and mcp-remote forwards requests to your remote HTTP endpoint. Functionally, this gives you a remote server with the convenience of a local client configuration. Cursor and VS Code Copilot support native HTTP transport and don't need this bridge.

Choosing Between Them

Question	Local (stdio)	Remote (HTTP)
Only you will ever use this tool?	Local is simpler	Either works
Multiple people or clients need access?	Not practical	Remote
Needs to run when your machine is off?	No	Remote
Needs direct local filesystem access?	Local	Harder over HTTP
Comfortable managing HTTPS and auth?	Not needed	Required

A reasonable default: start local while you're building and testing a tool, then move to remote hosting once you want to share it or use it from more than one client. If you already know you're building something for a team, start remote from the beginning rather than migrating later.

Making the Move to Remote

If you're moving from a local server to a hosted one, the tool logic itself doesn't change much. What changes is the transport and everything that comes with exposing an endpoint publicly: HTTPS, authentication, and rate limiting. Our MCP server hosting page covers what a production-ready remote endpoint needs, and MCPCore provisions all of it automatically when you create a server.

---

Transport details reflect the current MCP specification's stdio and Streamable HTTP transports. Check modelcontextprotocol.io for the authoritative transport reference.