← Blog

July 2, 2026 · 5 min read

WebMCP vs stdio MCP: which transport should you use?

TL;DR: Stdio MCP is right for local tools (file system, code execution, local databases) and developer-only use cases. WebMCP (HTTP+SSE) is right for hosted tools and products you want to distribute — it reduces setup to pasting a URL. The middle path is a stdio bridge package that proxies to a hosted HTTP server, giving users familiar setup while actual logic runs remotely.

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.

Quick summary

FactorstdioWebMCP (HTTP+SSE)
Setup for usersInstall runtime, run npx, edit configPaste a URL
Local file/system accessYesNo
Works from browserNoYes
Shared/team toolsHard — each user installsEasy — one URL
UpdatesUsers run npm updateDeploy once, everyone gets it
LatencyNear-zero (local)Network round-trip

When stdio is the right choice

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.

When WebMCP is the right choice

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.

The middle path: stdio bridge to HTTP

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.

What clients support each

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.

The bottom line

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.

Frequently asked questions

When should I use stdio MCP instead of WebMCP?

Use stdio when your tool needs to interact with the local machine — file system tools, local database clients, code execution environments, or shell wrappers. Stdio is also fine for tools you're building just for yourself, where the one-time setup friction of editing a JSON config file and installing a package doesn't matter.

What is the stdio bridge pattern for MCP?

The stdio bridge pattern uses an npm package as a stdio transport that proxies requests to a hosted HTTP server. The user gets the familiar stdio setup experience, but the actual logic runs remotely. Updates to the server are instant without users having to update the package. As WebMCP client support grows, the bridge can be deprecated in favor of direct URL connections.

Which MCP clients support WebMCP HTTP transport today?

Claude.ai web, Claude Desktop (recent versions), and Cursor (recent versions) support WebMCP HTTP+SSE transport. stdio transport works across Claude Desktop, Cursor, Windsurf, and most IDE extensions. Supporting both transports is the safe choice for broad compatibility today.