Remote vs Local MCP Servers: When to Use Each
Every MCP server runs in one of two places: as a subprocess on your machine (local stdio) or on a different host you connect to over HTTP (remote). The choice affects latency, security posture, deployment cost, and how multi-user setups behave. Here is how to pick, with the cases each one decisively wins.
The two transport models in one minute
The MCP specification defines a message format (JSON-RPC over a bidirectional channel) but leaves the transport up to the implementation. Two transports are in active use as of 2026:
Local (stdio)
The client spawns the server as a subprocess and pipes JSON-RPC over stdin/stdout. Zero network. Server runs as the user. Credentials passed via environment variables at launch.
command: npx -y @modelcontextprotocol/server-filesystem
Remote (HTTP)
The client connects to an HTTPS endpoint. Streamable HTTP (current spec) or SSE (deprecated) handles bidirectional traffic. Server runs anywhere — OAuth 2.1 handles auth.
url: https://mcp.sentry.dev
Side-by-side comparison
| Local (stdio) | Remote (HTTP) | |
|---|---|---|
| Latency per call | Sub-millisecond | 20-200ms typical |
| Concurrency | Limited by local resources | Server handles it; scales out |
| Filesystem access | Yes, with allowlist | No (server cannot see your disk) |
| Credential model | Env vars (API keys, PATs) | OAuth 2.1 + PKCE (2025-06-18 spec) |
| Multi-user | One client per process | Yes, scoped per user via OAuth |
| Cost | Free (your hardware) | Often metered or paid |
| Setup time | Seconds (single command) | OAuth flow on first connect |
| Data egress | None inherently | Conversation context flows to remote |
| Best clients | Claude Desktop, Cursor, VS Code | ChatGPT connectors, any client |
| Sandbox effort | You set it up (container, scoped user) | Already sandboxed by provider |
When to pick each
Use local (stdio) when:
- The workflow touches your local filesystem (Filesystem, Git, code execution).
- You need the lowest possible latency for interactive flows.
- You want zero data egress — the conversation stays on your machine.
- The integration is fundamentally about your machine (Puppeteer driving local Chromium, dev-tool inspection).
- You prefer free over metered.
Use remote (HTTP) when:
- The integration is intrinsically remote (Slack, HubSpot, Stripe, Notion).
- You need concurrency or scale that exceeds your local machine.
- You want OAuth-based auth instead of long-lived API tokens in env files.
- Multiple users on a team need the same MCP — remote scopes per user via OAuth.
- You are wiring into ChatGPT — only remote MCPs work as ChatGPT connectors.
The same MCP often supports both
Mental model: where does work happen?
The fastest way to pick is to ask where the work physically happens. If the answer involves "this machine" — files, processes, local databases, local browsers — local stdio is the right transport. If the answer is "somewhere on the internet" — SaaS APIs, hosted browsers, hosted vector stores — remote is the right transport.
Edge cases:
Hosted browsers (Browserbase, Stagehand)
The browser runs remotely on Browserbase\'s infrastructure but the MCP is usually installed locally as a stdio binary that calls out. The MCP itself is local; the work is remote. Latency follows the work, not the MCP.
Local databases connected to a SaaS
A local Postgres MCP talking to a Supabase project: install the MCP locally for low latency, but understand the network hop to Supabase is what defines the practical performance. The stdio choice does not buy you sub-millisecond if the destination is remote.
ChatGPT and other web-only clients
ChatGPT runs in the browser; it cannot spawn stdio subprocesses. The only MCPs that work with ChatGPT are remote ones. Same for any browser-based MCP client. This forces the choice if your target client is web.
Security trade-offs in plain terms
Local: maximum capability, maximum trust required
A local stdio MCP runs as you. It can read your env vars, your home directory (subject to its allowlist), and anything else your user can. The mitigation is to scope each MCP's capabilities (allowlist directories, read-only modes) and to run high-risk MCPs (Puppeteer, code execution) under a container or scoped user.
Remote: smaller capability, bigger network surface
A remote MCP cannot touch your machine, but your conversation context flows to it. The OAuth 2.1 model in the 2025-06-18 spec narrows the credential blast radius — leaked tokens cannot be replayed against other services because of audience binding. For SaaS integrations, remote is usually the lower-risk choice if the provider is trustworthy.
For a deeper look at credential scopes, sandboxing patterns, and prompt-injection mitigations, see the MCP Security guide.
Frequently asked questions
What is the difference between a remote and a local MCP server?
Local MCPs run as a subprocess of the MCP client on your machine. They communicate over stdio — the client writes JSON-RPC to stdin and reads from stdout. Remote MCPs run on a different host and speak HTTP (typically Streamable HTTP or, for older servers, Server-Sent Events). The client connects via URL and credential rather than spawning a process.
Which is faster — remote or local MCP?
Local stdio is almost always faster per tool call because there is no network round-trip. The trade-off is that local servers run on your machine, so heavy work (browser automation, large model inference) competes with everything else you are running. For workloads that need real concurrency or hosted compute, remote wins despite the higher per-call latency.
Are remote MCPs less secure than local?
Different threat models. Local stdio servers have the same permissions as you — including filesystem read/write and env var access. Remote servers are limited to whatever they expose plus the credentials you hand them, but the credentials and your conversation context travel over the network. The 2025-06-18 spec mandates OAuth 2.1 with PKCE for remote MCPs, which closes most of the historical auth gaps.
Can the same MCP server run both modes?
Many do. The MCP specification defines the message format, not the transport. Servers like Sentry, Cloudflare, GitHub, and several others ship both a stdio binary for local use and a hosted endpoint for remote use. The capability surface is usually identical between modes.
When should I prefer remote MCP?
When the workflow needs concurrency, when you do not want to run heavy processes locally, when the integration is intrinsically remote (Slack, HubSpot, Stripe), or when you want OAuth-based auth instead of long-lived API tokens. For multi-user setups (team installs, ChatGPT connectors), remote is the only practical choice.
When should I prefer local MCP?
When the workflow touches the local filesystem (Filesystem, Git), when you need the lowest possible latency, when you want zero data egress, or when the integration is fundamentally about your machine (Puppeteer driving a local browser, code execution against local processes). Local also avoids per-call costs on metered remote MCPs.
What about streamable-http vs SSE?
Streamable HTTP is the current spec transport — bidirectional, supports streaming responses, and handles disconnects gracefully. Server-Sent Events (SSE) was the original remote transport, deprecated in the 2025-06-18 spec. Older servers may still expose SSE, but new remote MCPs should target Streamable HTTP. Clients like Claude Desktop and Cursor handle both for compatibility.
Continue reading
Choosing where the MCP runs is one of three setup decisions. The auth and sandboxing story lives in the security guide; the per-client config files live in the setup guides.
More guides
Fundamentals
What Is MCP? A Plain-English Guide to Model Context Protocol
6 min read
Setup Guide
Best MCPs for Cursor in 2026 (Ranked + Setup)
8 min read
Setup Guide
Best MCPs for Claude Desktop in 2026 (Ranked + Setup)
9 min read
Setup Guide
Best MCPs for Claude Code in 2026 (Ranked + Setup)
8 min read
Setup Guide
Best MCPs for Windsurf in 2026 (Cascade-Ready Setup)
8 min read
Setup Guide
Best MCPs for VS Code in 2026 (Agent Mode + .vscode/mcp.json)
8 min read
Strategy
MCP Registry vs Curated Directory: Which Should You Use?
5 min read
Setup Guide
Best MCPs for ChatGPT: The Apps and Connectors Worth Installing
9 min read
Tutorial
How to Add an MCP Server to ChatGPT (Developer Mode + Apps Directory)
7 min read
Security
MCP Security: What to Know Before You Install
9 min read
Role Guide
Best MCPs for Marketers in 2026 (SEO, Email, Analytics)
8 min read
Fundamentals
MCP vs Function Calling: What’s the Difference?
6 min read