Remote MCP server vs local MCP server: which to use

A local MCP server is a program your AI app starts on your own computer and talks to over stdio. A remote MCP server is a service someone runs on the internet that your app reaches by URL, usually over Streamable HTTP. Use a local server when the tool needs your machine: your files, a database on your laptop, an app or network only you can reach. Use a remote server for everything else, because there is nothing to install, the vendor keeps it updated, and the same URL works in Claude on the web, in Claude Desktop, in Cursor and in Claude Code. The rest of this guide shows how to tell which one you have, what each looks like in a config file, and where each one breaks.

What is the difference between a local and a remote MCP server?

The MCP spec defines two standard ways for an app (the client) to talk to a server. The transports overview(checked November 2026) lists them as stdio, "newline-delimited messages over the standard streams of a client-launched subprocess", and Streamable HTTP, where "each message is an HTTP POST to a single MCP endpoint".

Those two transports map onto the local and remote split. In the stdio binding, "the client launches the MCP server as a subprocess." The server only exists while your app runs it, and it lives on the same machine. In the Streamable HTTP binding, "the server operates as an independent process that can handle multiple client connections", behind one endpoint such as https://example.com/mcp. It runs whether or not your app is open, and many people can use the same one.

One nuance the labels hide: local and remote describe where the server runs, stdio and HTTP describe how you talk to it. An HTTP server can run on your own laptop. The same spec page says that "when running locally, servers SHOULD bind only to localhost (127.0.0.1)", and Cursor's MCP docs(checked November 2026) list Streamable HTTP as running "Local or remote". In practice, though, almost every local server you install is stdio and almost every hosted one is HTTP, so the rest of this guide uses the words that way. If you are new to hosts, clients and servers, the MCP explainer covers them first.

How can you tell which kind of server you have?

Look at what the server's README tells you to paste. That one detail answers the question.

• A command, such as npx -y some-package, uvx some-tool, python server.py or a path to a binary, means a local server. In a config file it shows up as a command with args.
• An https address, often ending in /mcp, means a remote server. In a config file it shows up as a url.
• An address ending in /sse is a remote server on the older HTTP+SSE transport. The Streamable HTTP pagesays it "has been deprecated since protocol version 2025-03-26" and that new implementations should not adopt it. Clients still connect to these servers, covered below.

Some vendors offer both: an npm package you run yourself and a hosted URL. When you get that choice, the rest of this guide is how to pick.

How do local and remote MCP servers compare?

Two rows deserve a closer look. On permissions, the official MCP guide to local servers(checked November 2026) warns about its own filesystem example that "the server runs with your user account permissions, so it can perform any file operations you can perform manually." That is what makes a local server powerful, and it is why you should only run local servers you trust.

On sign-in, the authorization spec(checked November 2026) splits the two cleanly. Authorization is optional, but when it is used, servers on an HTTP transport "SHOULD conform" to the spec's OAuth 2.1 based flow, while stdio servers "SHOULD NOT follow this specification, and instead retrieve credentials from the environment." That is why local servers ask you to paste an API key into an env block and remote servers open a browser window to sign you in.

What does each look like in a config file?

Most clients use the same mcpServers shape for both kinds, and the difference is just command versus url. Here is one local and one remote server side by side in Cursor's mcp.json. Cursor's MCP docs list command, args, env and envFile for stdio servers, and url and headers for remote ones.

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/username/Desktop"]
    },
    "goro": {
      "url": "https://mcp.usegoro.ai/mcp"
    }
  }
}

In Claude Code the split is the --transport flag. Its MCP docs(checked November 2026) say "HTTP servers are the recommended option for connecting to remote MCP servers", and that for stdio servers the -- separates Claude's own options from the command that runs the server.

# local: Claude Code starts the program, everything after -- is the command
$ claude mcp add --transport stdio filesystem -- npx -y @modelcontextprotocol/server-filesystem /Users/username/Desktop

# remote: Claude Code connects to a URL
$ claude mcp add --transport http goro https://mcp.usegoro.ai/mcp

If you write Claude Code's .mcp.json by hand, one detail trips people up. The same docs say an entry that has a url but no typeis a configuration error, "because Claude Code reads an entry with no typeas a stdio server." Remote entries need "type": "http".

{
  "mcpServers": {
    "goro": {
      "type": "http",
      "url": "https://mcp.usegoro.ai/mcp"
    }
  }
}

Claude Desktop keeps the two apart entirely: remote servers go in as custom connectors, local ones as extensions or in claude_desktop_config.json. The step-by-step for each is in the Claude Desktop MCP guide, and the Cursor specifics, including OAuth and approvals, are in the Cursor MCP guide.

When should you use a local MCP server?

When the work happens on your machine, or on a network only your machine can reach. A remote server cannot see your disk, and in Claude it cannot see your private network either: Anthropic's custom connector guide(checked November 2026) says "Claude connects to your remote MCP server from Anthropic's cloud infrastructure, rather than from your local device", and that servers "behind a VPN, or blocked by a firewall won't connect." Good fits for local:

• Reading and writing files in folders you choose.
• A database, dev server or container running on your laptop.
• An internal tool on your office network or VPN.
• A server you are building yourself, before you deploy it anywhere.
• Cases where your rules say requests must not pass through a third party's server. Keep in mind a local server that calls an outside API still sends data to that API.

The cost is upkeep. Every machine needs the runtime (often Node.js or Python), the right version, and your API keys in a config file. A local server also stays local: the same connector guide says servers in claude_desktop_config.json"aren't available in Cowork or claude.ai."

When should you use a remote MCP server?

When the tool talks to services on the internet anyway, which covers most of what people connect: search, SaaS apps, data APIs, media generation. There the remote version wins on almost every count.

• Nothing to install. No Node version to manage, no package to update, no npx path problems.
• It follows you.Anthropic's guide says custom connectors using remote MCP "are available on Claude, Cowork, and Claude Desktop", so one URL works in the browser and the desktop app, and the same URL goes into Cursor or Claude Code.
• No keys in plain text.With OAuth you sign in once in the browser instead of pasting a secret into a JSON file. Claude Code's docs say its tokens are "stored securely and refreshed automatically".
• Teams share one setup.Claude Code's project scope stores servers in a .mcp.jsonat the project root, and its docs say to check it into version control "so everyone on your team gets the same MCP tools and services." A URL entry has no local path or runtime to differ between machines.

The cost is trust. Your tool calls, and whatever the agent puts in them, go to someone else's server. Read the operator's privacy terms the way you would for any SaaS, and prefer servers that sign you in with OAuth over ones that want a long-lived key.

Can you use a remote server in a client that only supports local ones?

Yes, with a bridge. mcp-remoteis an open-source package whose README (checked November 2026) describes it as a way to "connect an MCP Client that only supports local (stdio) servers to a Remote MCP Server." You add it as a local server whose argument is the remote URL. It runs on your machine, forwards every message, and handles the OAuth sign-in in your browser.

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

The README says it needs Node 18 or higher and keeps credentials in ~/.mcp-auth. The bridge has a second use in Claude Desktop: because it connects from your computer rather than from Anthropic's cloud, it can reach a server that is only visible on your own network. For a public server, the client's native URL support is simpler, so use that when it exists.

For old /sseservers, most clients cope on their own. Claude Code's docs say to add them with the same --transport httpcommand: it "tries the HTTP transport first and switches to SSE when the server doesn't accept it", which needs Claude Code v2.1.265 or later, and --transport sse still works on earlier versions.

Which kind is Goro?

Goro is a remote server. You add one URL, https://mcp.usegoro.ai/mcp, and sign in with OAuth 2.1. There is no package to install and no API key for the MCP connection. Behind that URL is a catalog of real-world tools: web and news search, page scraping, social platform data, maps, people and company enrichment, plus image, video and voice generation. Your agent sees the price before each call and reports which tool ran and what it cost. A web search call is from $0.0075 per page of about ten results, and a web page scrape is from $0.005970 per result.

It does not replace your local servers. If the job is reading your files or querying the database on your laptop, keep a local server for that; the two sit side by side in the same config, as in the Cursor example above. And if all you need is for Claude to look something up, its built-in web search already does that with nothing to add. A gateway pays off when you would otherwise install and maintain a separate server, account and bill for each data source. Running tools needs a plan, from $19 a month with $25 of tool credit included; the details are on the pricing page.