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.
WebMCP is MCP over the web — servers that live at a URL accessible from a browser without installation. Classic MCP uses stdio transport (a local subprocess), which requires every user to install a runtime, run npx, and edit a config file. WebMCP uses HTTP+SSE so users connect by pasting a URL instead. The protocol is the same JSON-RPC structure; only the transport changes.
Any tool that is inherently remote or shared works well as a WebMCP server: documentation indexes that any agent can query, API wrappers calling external services, team-shared internal tools deployed once and shared via URL, and SaaS product integrations where the server handles auth and logic. Tools that need local file system or process access still belong on stdio.
Claude.ai's web interface supports remote MCP connections from the browser without local setup. Cursor and Claude Desktop support HTTP transport in addition to stdio. The pattern for connecting is: go to settings, add an MCP server, paste the URL instead of entering a command. Support is growing — not universal yet, but moving fast.