Local vs Remote MCP Servers: What Changes

The real difference is where the server process runs and who holds the credentials — not what its tools can do. Stdio mode, used by both VS Code and GitHub MCP via npx, spawns the server as a local process next to the client. Remote mode swaps that for one shared, network-reachable endpoint over HTTP/SSE, which centralizes credentials and rate limits instead of splitting them per machine.

What's the actual difference between stdio and HTTP/SSE transport?

MCP separates what an agent can do from how the client talks to the process doing it. According to modelcontextprotocol.io, the protocol exists to connect AI applications like Claude to external systems — data sources such as local files and databases, tools such as search engines and calculators, and workflows such as specialized prompts — the way USB-C gives every device the same physical connector. That connection travels over one of two transports: stdio, where the client launches a process on the same machine and talks to it over standard input/output, or HTTP/SSE, where the client instead opens a network connection to a server already running somewhere else.

The VS Code MCP page shows the stdio pattern directly: install with mcpizy install vscode through the MCPizy CLI, or run npx -y vscode-mcp-server directly, which spawns a local process that reads workspace structure and diagnostics for Claude Code, Cursor, Windsurf and any other MCP-compatible client. The GitHub MCP server follows the same shape — npx -y @modelcontextprotocol/server-github starts a local process on the developer's own machine, even though the tools it exposes then call out to GitHub's API over the network to do their work.

That last detail is the point: local vs remote describes where the MCP server process itself lives, not whether the data or API it touches is local. A remote deployment moves that same process onto a server reachable over HTTP/SSE, so any number of clients can connect to one running instance instead of each person launching their own copy with npx. Everything else — the tools a server exposes, their inputs, what they're allowed to do — stays the same regardless of transport.

What do you gain by running an MCP server locally?

Running the MCP server locally turns the hop between client and server into a local pipe instead of a network round trip, and it means whatever the server reads never has to leave the machine to reach the process handling it. The VS Code MCP page frames this directly: it lets Claude Code, Cursor, Windsurf and other MCP-compatible agents read workspace structure and diagnostics, installed in one command — mcpizy install vscode — with no separate server to stand up or host.

For a tool whose whole job is reading the project in front of you, that matters: the workspace never has to be shipped anywhere for the MCP hop itself, only whatever the client's underlying model call actually needs. Local install also removes an operational commitment — nothing to deploy, patch or keep online, because the process exists only for the length of the client session and disappears when it ends.

Local doesn't mean fully offline, though. The GitHub MCP server also installs locally via npx -y @modelcontextprotocol/server-github, but its tools — get_repository, list_issues, create_issue, list_pull_requests, get_file_contents — still call out to GitHub's API over the network on every use. The local/remote choice is about where the MCP process itself runs, not about whether the workflow ever touches a network at all.

What do you gain by running an MCP server remotely?

The case for a remote MCP server is organizational more than technical: one running instance, reachable over HTTP/SSE, that every teammate's client points to instead of each person installing and running their own copy. Take GitHub MCP — the official server installs today as a local process via npx -y @modelcontextprotocol/server-github and authenticates with a fine-grained PAT that each developer has to scope themselves. Moving that same server behind one shared remote endpoint would mean one credential to configure and rotate instead of one per developer.

It also collapses the "install a local process" step across client types. The VS Code MCP page lists compatibility across Claude Code, Claude Desktop, Cursor, Windsurf, VS Code + Copilot and any MCP client — in stdio mode, each of those spawns vscode-mcp-server itself. In a remote deployment they would all dial into the same address instead, which is simpler to standardize once for a team than to repeat per machine.

The tradeoff sits on the other side of that same coin: a remote server has to actually be run, kept online and monitored by someone, which a local npx process launched by the client does not. Local trades that operational load for per-machine setup; remote trades per-machine setup for an always-on service someone owns.

Does local or remote change the security surface?

Whichever way it's deployed, an MCP server's real attack surface is set by what its tools are allowed to do once called — not simply by where the process sits. The GitHub MCP pitfalls list concrete examples: fine-grained tokens have scope limits that are easy to get wrong (the "all repositories" toggle does not include private repos by default), and create_or_update_file commits through the API, which skips GPG signing, pre-commit hooks and CI unless branch protection blocks it — which is why the guidance is to push to a branch and open a pull request rather than commit straight to a main branch.

Running that server locally keeps the PAT on the developer's own machine, inside their own client config. Running it remotely concentrates that same token, and its scope, on a shared server that every connected client can trigger. Centralizing raises the stakes of a single leaked credential, which is exactly why the scope discipline described in the GitHub pitfalls — smallest scope, write access only with explicit human approval in the loop — carries more weight once several people share one endpoint instead of each holding their own token.

Rate limits become a shared-resource question too once a server goes remote. GitHub's API allows 5,000 requests per hour for an authenticated PAT, according to the GitHub MCP page — enough for a triage pass of roughly 200 issues at five calls each, about 1,000 requests, but a wider audit across many repositories can approach that ceiling faster when several teammates draw on the same remote instance and token instead of each running an isolated local copy.

None of this makes one mode categorically safer than the other — a poorly scoped token is a problem locally too, and a well-scoped one is fine remotely. What changes is who's exposed if it leaks: one developer's machine in local mode, or every client connected to the shared endpoint in remote mode. Before adopting either, the checklist in How to Audit an MCP Server Before Install — checking scopes and maintenance signals before installing — applies the same way to both.

How do you configure each mode in VS Code and Claude Code?

Configuring stdio/local mode is a matter of pointing the client at a command to run. For VS Code MCP that's mcpizy install vscode through the MCPizy CLI, which writes the config automatically, or npx -y vscode-mcp-server added by hand. For GitHub MCP it's the same shape: mcpizy install github, or npx -y @modelcontextprotocol/server-github supplied with a scoped PAT as an environment variable.

The exact config file and schema differ by client. VS Code's own mcp.json format is covered in VS Code mcp.json: the full schema, with examples, and the step-by-step flow for adding a server is in How to Add an MCP Server to VS Code. Both describe the same stdio shape: a command, optional arguments, and any environment variables the server's tools need — for GitHub MCP, that's the fine-grained PAT referenced in its own pitfalls.

What changes for a remote deployment is what goes in that config block. Instead of a command and arguments to spawn locally, the client needs a URL to dial into and whatever authentication the HTTP/SSE endpoint expects on the connection itself, rather than an environment variable read by a freshly spawned process. The tool list itself — for GitHub MCP: get_repository, list_issues, create_issue, list_pull_requests, create_pull_request, get_file_contents, create_or_update_file — doesn't change with the transport, only how the client reaches it.

FAQ

Can the same MCP server run in both modes?

Yes — local vs remote is a deployment choice, not a different server. The GitHub MCP server and the VS Code MCP server both install today as local stdio processes via npx, spawned directly by the client, but nothing about their tool definitions ties them to that transport. The same code that npx -y @modelcontextprotocol/server-github runs locally is what a remote deployment would run behind an HTTP/SSE endpoint instead.

Is remote less secure than local?

Not inherently — the exposure differs rather than the risk being categorically higher. The GitHub MCP pitfalls describe risks that exist in either mode, like an over-scoped PAT or a commit made through create_or_update_file that bypasses GPG signing and CI. Local mode limits a leaked credential's reach to one developer's setup; remote mode concentrates it on a shared endpoint, which is why scope discipline matters more once a server is shared.

Where do I check before installing either mode?

The checklist in How to Audit an MCP Server Before Install covers scopes, maintenance signals and sandbox behavior, and applies whether the server in question runs as a local npx process or behind a remote endpoint. For a config-level walkthrough specific to VS Code, VS Code mcp.json: the full schema, with examples shows what a stdio entry actually looks like before you add one.