July 2, 2026 · 6 min read
MCP — the Model Context Protocol — started as a local protocol. You ran a server as a subprocess on your machine, an AI client like Claude Desktop connected to it via stdin/stdout, and tools were called over that pipe. It worked well for local tools. But it created a problem: every user had to install and configure the server themselves.
WebMCP is the answer to that problem. It's MCP over the web — servers that live at a URL, accessible from a browser, no installation required. Here's how it works and what it changes.
Standard MCP uses stdio transport: the client spawns a subprocess (npx some-mcp-server) and talks to it over stdin/stdout. This works perfectly for local tools — file system access, code execution, local database queries. The tool runs on your machine, touches your files, done.
But for remote tools — APIs, hosted services, shared indexes — stdio is the wrong model. You're starting a local process just to proxy requests to a remote server. Every user has to install Node.js, run npx, configure a JSON file. The tool itself is stateless and remote, but setup feels local and heavy.
WebMCP uses HTTP with Server-Sent Events (SSE) as the transport layer. Instead of a subprocess, the MCP server is just a URL. The client sends requests over HTTP and receives streaming responses via SSE.
This means:
No installation. The server lives at a URL. Users connect by pasting a URL into their MCP client, not by running a package manager command.
Works from a browser. HTTP+SSE is the native web stack. A browser can connect to a WebMCP server without any local runtime — no Node, no Python, no subprocess.
Hosted tools. The server operator handles deployment, updates, and scaling. Users always get the latest version without updating a local package.
A WebMCP server is an HTTP server that implements the MCP protocol over two endpoints:
GET /mcp → SSE stream (server pushes events to client)
POST /mcp → client sends requests (tool calls, list tools, etc.)The message format is the same JSON-RPC structure as stdio MCP — the protocol doesn't change, just the transport. A server that implements both stdio and HTTP can serve local and web clients from the same codebase.
AgentReady's MCP server is a good example. The npm package (@agentreadyweb/mcp) is a thin stdio bridge — it receives requests from the MCP client over stdio and forwards them to AgentReady's hosted Next.js server over HTTP. The actual logic lives at the URL, not in the package. WebMCP removes the bridge entirely: clients connect to the URL directly.
Support is growing. Claude.ai's web interface supports remote MCP connections — you can connect a WebMCP server from the browser without any local setup. Cursor and Claude Desktop support HTTP transport in addition to stdio, so they can connect to WebMCP servers too.
The pattern for connecting is typically: go to settings, add an MCP server, paste the URL instead of entering a command. The client handles the HTTP+SSE connection automatically.
Any tool that's inherently remote or shared. Some examples:
Documentation indexes — a shared index of developer docs that any agent can query. The index lives on a server, not on each user's machine.
API wrappers — tools that call external APIs (weather, maps, databases). No reason to run these locally.
Team-shared tools — internal tools a whole team needs access to, deployed once and shared via URL rather than installed per-machine.
Product integrations — a SaaS product exposing MCP tools for its users. The server handles auth and logic; users connect with a URL.
For tools that genuinely need local access — your file system, local databases, running processes — stdio remains the right model. WebMCP doesn't replace stdio, it complements it.
Stdio MCP has a distribution problem. Every MCP server on GitHub comes with a setup README that starts with "install Node.js" and ends with editing a JSON config file. That's a meaningful barrier for non-technical users and a friction point even for developers.
WebMCP makes MCP servers feel more like web services — you get a URL, you paste it in, it works. That's a fundamentally lower barrier to adoption. Expect the number of useful MCP servers to grow significantly as WebMCP support matures, because building and distributing a hosted HTTP server is something most developers already know how to do.