A local MCP server runs as a process on your own machine and talks to your AI client over stdio. A remote MCP server runs somewhere else — a provider’s cloud, or your own — and talks to your client over HTTP, usually behind OAuth. Both speak the same Model Context Protocol underneath. What differs is where the server lives, who else can use it, and how much setup and maintenance falls on you. Here is how to tell them apart and pick the right one for a given tool.

What a local MCP server is

A local server is a program your client launches directly on your computer — a Node or Python process it starts over stdio (standard input/output), with no network hop in between. Classic examples are servers that touch your filesystem, a local database, or a CLI tool: things that only make sense running where you are. You typically install it yourself and point your client’s config file at the executable.

Because it runs on your machine, a local server can see whatever your user account can see. That is exactly what makes it useful for local file or dev-tool access, and exactly what makes an unreviewed one worth a second look — see how to vet an MCP server before you run one you did not write yourself.

What a remote MCP server is

A remote server runs on infrastructure you do not manage — a vendor’s servers, in most cases — and your client reaches it over Streamable HTTP (the current MCP transport standard). You add it by URL instead of by installing anything, and because it is not tied to your machine, it almost always gates access with OAuth: you sign in once, the server issues a token, and every call after that runs under your account’s existing permissions.

Most of the well-known MCP integrations work this way today — Notion, Linear, Sentry, Stripe, and the rest of the providers in gate’s server directory all publish remote endpoints rather than something you install locally. We covered one end-to-end example in connecting Notion to Claude.

The practical differences

  • Setup. Local needs the runtime installed and a config file edited by hand, per client, per machine. Remote needs a URL and an OAuth sign-in — no install step.
  • Multi-client, multi-device. A local server only exists where you installed it. Switch laptops or add a second AI client and you set it up again. Remote servers are reachable from anywhere you can sign in.
  • Sharing with a team. Local servers are inherently single-user — there is no natural way to hand one to ten teammates without ten separate installs. Remote servers can be governed centrally, which is the whole premise behind access control for MCP teams.
  • What it can reach. Local servers are scoped to your machine by default — often a feature, not a limitation, for filesystem or local dev tools. Remote servers are scoped to whatever your OAuth grant allows on the provider’s side, which can be broad.
  • Change control. A local server only changes when you update it yourself. A remote server’s maintainer can change its tools at any time, which is the mechanism behind the “rug pull” risk described in MCP prompt injection and tool poisoning.

When local makes sense

Reach for a local server when the job is inherently local: reading and editing files in a specific project directory, running commands against a database only reachable from your network, or wrapping a CLI tool you already have installed. If only you use it, and it never needs to run for anyone else, the simplicity of stdio is hard to beat.

When remote makes sense

Reach for a remote server for anything that is really a connection to a hosted product — a SaaS tool, a cloud database, a payments platform — and for anything more than one person or more than one client needs to use. Once a second person or a second AI client enters the picture, point-to-point local installs stop scaling, and a shared remote connection becomes the easier and more auditable option.

Where gate fits: gate is a gateway for remote MCP servers. You add a server by URL, complete its OAuth flow once, and every client pointed at your gate URL gets that connection — scanned for prompt injection before it goes live, governed with allow/ask/block rules, and logged in plain language. Local/stdio servers run entirely on your own machine and are outside what a hosted gateway like gate touches; they still deserve the same scrutiny, just applied by hand. You can browse the remote servers gate already supports on the server directory, or run any server’s tool list through the free MCP security scanner first.

The bottom line

Local versus remote is really a question of where a tool lives and who else needs it. One person, one machine, one narrowly local job: a local stdio server is simple and fine. Anything hosted, shared, or used from more than one client: a remote server, ideally reached through a single governed gateway rather than wired into each client by hand, is the setup that still makes sense a year from now. Most teams end up running both — the trick is knowing which is which before you connect one.