Local vs. Remote MCP Servers

Every MCP server listed on DReview is tagged either "Local · stdio" or "Remote · SSE" — and that one label answers a real, practical question before you've read a single line of setup instructions: does this thing run on your own machine, or does it live somewhere else entirely? The two options aren't just a technical detail. They change how you install a server, what it can access, who else can use it, and what you're trusting it with.

What "local" actually means

A local MCP server runs as a subprocess on your own computer, launched directly by your AI client. When you add a server to Claude Desktop or Cursor with a config like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/projects"]
    }
  }
}

the client itself starts that npx process, talks to it over stdin/stdout (this is the "stdio" transport), and kills it when you close the client. There's no network call involved in the core protocol exchange — the server is just another process on your machine, with whatever access to your filesystem, environment variables, or local network it's been given.

This is why servers like Filesystem MCP Server or Playwright MCP are local: they need direct access to your disk or your actual browser session. Running them "in the cloud" wouldn't make sense — there's no cloud version of your laptop's file system.

What "remote" actually means

A remote MCP server runs somewhere else — a company's own infrastructure, typically — and your client connects to it over HTTPS using Server-Sent Events (SSE) or the newer Streamable HTTP transport, instead of spawning a local process. Exa MCP Server is a good example: its config is just a URL —

{ "mcpServers": { "exa": { "url": "https://mcp.exa.ai/mcp" } } }

— and your client opens a persistent connection to Exa's servers rather than running anything locally. Stripe's and Square's MCP servers work the same way, both hosted at a URL you point your client at, often layered with OAuth so you authenticate with your real account instead of pasting an API key into a config file.

Remote servers are the natural fit for anything that's already a hosted service on someone else's infrastructure — a search index, a payments platform, a SaaS API — where there's no local equivalent to run.

The real tradeoffs

Setup friction. Local servers usually need a runtime on your machine (Node, Python, uv) and sometimes a real account's worth of environment variables. Remote servers are often just a URL, sometimes with a one-time OAuth flow — genuinely less to configure.

Where your data goes. This is the one that actually matters. A local server talking to your own filesystem never sends that data anywhere the vendor controls — the process runs on your hardware, under your OS permissions. A remote server necessarily means your requests (and whatever data they contain) travel to and are processed by someone else's infrastructure. Neither is automatically "unsafe," but they're different trust models, and it's worth knowing which one you're in before connecting a server to anything sensitive.

Access boundaries. Local servers are scoped by what your OS user account can touch — which is both a strength (nothing you don't already have access to) and a risk (also nothing stopping it, unless the server enforces its own limits, the way Filesystem MCP Server restricts itself to a directory you specify). Remote servers are scoped by whatever the vendor's API permissions allow, which is often narrower and more auditable — Stripe's remote server, for instance, only exposes what your Stripe API key is scoped to do.

Sharing. A local server is inherently single-user — it only exists while your client is running it, on your machine. A remote server can serve many users or many clients simultaneously, which is why it's the right shape for anything meant to be used by a team, not just configured once on one laptop.

Reliability and updates. A local server runs whatever version you have installed until you update it. A remote server is maintained by whoever hosts it — you always get their current version, for better (bug fixes arrive automatically) or worse (behavior can change without you doing anything).

A simple way to decide

Ask what the server actually needs to touch. If the answer is "my filesystem," "my running browser," "a local database on this machine," or "a CLI tool installed on this computer" — it has to be local, because there's nothing to connect to remotely. Desktop Commander MCP and DBHub are both local for exactly this reason.

If the answer is "a hosted API or platform I already have an account with" — Stripe, Slack, Exa, Google Workspace — a remote server (when the vendor offers one) usually means less setup and a narrower, vendor-managed permission boundary. Several tools on DReview offer both: Tavily MCP and Razorpay MCP Server each support a local stdio mode and a hosted remote mode, so you can pick based on whether you'd rather manage an API key locally or authenticate once against a hosted endpoint.

For anything that touches real money, real messages sent on your behalf, or sensitive personal data — regardless of local or remote — read what permissions the server actually requests before connecting it. That's true of every listing on DReview: the FAQ section on each tool page exists specifically to surface exactly this kind of thing, like whether posting messages is enabled by default (it usually isn't) or whether a payments server defaults to a test environment (the good ones do).

Spotting the type before you install anything

You don't have to read a whole README to know which kind of server you're looking at. Two tells, in order of reliability:

1. The install config itself. A command field (npx, uvx, python, a binary path) means the client is going to spawn a local process — that's stdio, full stop. A bare url field with no command means the client is opening a connection to an existing endpoint — that's remote, whether it's SSE or Streamable HTTP under the hood. 2. Whether it needs your own credentials for a third-party service. If the setup asks you to paste in an API key for something you already have an account with (Stripe, Slack, AWS), that's a strong signal it's either remote or a local wrapper around a remote API anyway — the server itself isn't the thing holding your data, the third-party platform is.

On DReview specifically, every listing is already tagged with its server type in the filter sidebar and on the tool card itself, so you don't have to infer it from the config at all — filtering by "Local · stdio" or "Remote · SSE" up front narrows the catalog to only the setup style you're looking for before you've opened a single listing.

It's not a permanent choice

The transport type isn't a philosophical commitment — it's just how a given server happens to be built, and some tools support both. If you start with a local install because it was the fastest path to trying something out, nothing stops you from switching to that same vendor's remote option later if one exists, or the other way around. Check each tool's own install tabs on its DReview listing; when a server offers more than one client config, both are shown.