July 2, 2026 · 5 min read
MCP supports two main transport modes: stdio (the original, subprocess-based approach) and HTTP+SSE (what's being called WebMCP). If you're building or connecting to MCP servers, you'll need to pick one — or support both. Here's how to think about it.
| Factor | stdio | WebMCP (HTTP+SSE) |
|---|---|---|
| Setup for users | Install runtime, run npx, edit config | Paste a URL |
| Local file/system access | Yes | No |
| Works from browser | No | Yes |
| Shared/team tools | Hard — each user installs | Easy — one URL |
| Updates | Users run npm update | Deploy once, everyone gets it |
| Latency | Near-zero (local) | Network round-trip |
Use stdio when your tool needs to interact with the local machine. File system tools, local database clients, code execution environments, shell wrappers — these all need to run where the files and processes are. There's no network equivalent for reading ~/.ssh/config or running a local test suite.
Stdio is also fine for tools you're building just for yourself. The setup friction (edit a JSON config, install a package) is a one-time cost that doesn't matter when you're the only user. Most developer tooling MCP servers fall here.
Use WebMCP (HTTP+SSE) when the tool is inherently remote — it calls an external API, queries a hosted index, or does something that doesn't require touching the local machine.
More importantly, use WebMCP when you're distributing a tool to many users. The stdio setup experience is rough. Users need Node installed, need to run npx, need to find and edit the right config file in the right directory. For a developer building their own tooling, that's fine. For a product you're shipping to customers, it's a support burden and a conversion killer.
WebMCP turns "install this MCP server" into "add this URL". That's a significantly better onboarding story.
Some servers support both by using a bridge pattern: an npm package (stdio transport) that proxies to a hosted HTTP server. The user installs the package — gets the familiar stdio setup — but the actual logic runs remotely. Updates to the server are instant; the package rarely needs bumping.
This is a reasonable transitional approach while WebMCP client support catches up. The tradeoff is that you maintain two things: the bridge package and the HTTP server. As WebMCP support grows across clients, the bridge becomes unnecessary overhead and you can deprecate it.
stdio: Claude Desktop, Cursor, Windsurf, most IDE extensions. Mature support, works everywhere.
WebMCP (HTTP+SSE): Claude.ai web, Claude Desktop (recent versions), Cursor (recent versions). Support is growing — not universal yet, but moving fast.
If you're building a server today for broad compatibility, supporting both transports is the safe call. If you're building for a specific client that supports WebMCP, go HTTP-only and skip the complexity.
stdio for local tools and developer-only use cases. WebMCP for hosted tools, products, and anything you want non-technical users to connect to. When in doubt and you're building something remote, go WebMCP — the friction reduction is significant and client support is only improving.