2026-07-23 · agentic web · protocol stack

WebMCP and server-side MCP: two doors, not two rivals

One registers tools inside the page, for browser agents in a visible tab. The other serves headless agents over HTTP. Different callers, different discovery — same storefront.

TL;DR — WebMCP is a proposed web standard, in origin trial since Chrome 149, that lets a web page register structured tools for AI agents operating in the browser. It is easy to read as a competitor to the Model Context Protocol servers your site may already expose. It isn't one. WebMCP tools live in the page and run in a visible tab; server-side MCP endpoints answer headless agents over HTTP. They have different callers, different discovery mechanics and different execution contexts — and a WordPress site can, eventually, hold both doors open at once.

What WebMCP actually is

WebMCP is an open proposal in the W3C Web Machine Learning community group, with Chrome shipping the first implementation behind an origin trial from Chrome 149. The problem it addresses is what Chrome's documentation calls actuation: today, a browser agent completes a task on your site by simulating a human — reading the DOM, guessing which button does what, typing into fields, clicking. Every step of that guesswork is a place to fail.

WebMCP replaces guessing with declaration. The page itself registers tools — search, filter_results, checkout — with names, descriptions and JSON Schema for their input parameters, returning structured results. There are two ways to do it: an imperative API, where JavaScript registers tool functions, and a declarative API, where annotations on standard HTML forms turn them into tools. When a browser-integrated agent lands on the page, it sees the registered tools and calls them instead of puppeteering the interface. The tools execute visibly, in the tab, in front of the user.

Three structural facts worth underlining

Before comparing anything, three properties of WebMCP shape everything downstream. They come straight from Chrome's own documentation, not from our reading of it.

The server-side door: MCP over HTTP

Now the other door. A remote, server-side MCP deployment exposes an HTTP endpoint speaking JSON-RPC 2.0 (Streamable HTTP is one of the protocol's two standard transports, alongside stdio) that any agent can call — no browser, no tab, no page. Our own KaliCart MCP plugin is a small, read-only example: it exposes a WordPress site's posts and pages as five tools (site_info, site_map, list_content, search_content, get_content) on a single endpoint, with discovery at a .well-known path, returning clean Markdown. The commerce equivalent is the KaliCart Bridge, which exposes a WooCommerce catalog to agents on the merchant's own domain — and, with consent, to federated search across the network. Details and documentation live at mcp.kalicart.com.

The callers here are headless by nature: assistants answering a question, shopping agents comparing offers, pipelines reading content. They discover servers the way machines discover things — well-known paths, manifests, registries — and they call tools from wherever they run. No screen is involved, and no one is watching the call happen.

The differences, side by side

Put the two doors next to each other and the shape of each becomes obvious.

Google maintains its own comparison of WebMCP and MCP, and it draws the same line: these are complementary mechanisms for different agent contexts, not two contenders for one job.

Two doors on the same storefront

Which brings us to the question a WooCommerce merchant should actually ask: do I have to choose? No — and eventually you shouldn't. The same site can expose a server-side MCP surface for the agents that never open a browser, and register WebMCP tools for the agents that arrive with a user in a tab. The tools can even mirror each other: the search_products a Bridge exposes over HTTP today is, almost verbatim, the tool a product listing page would register via WebMCP tomorrow.

Our order of operations is deliberate, and it follows the same rule we apply everywhere else: measure before you claim, and build where the traffic is. The measurable agent traffic on real WooCommerce catalogs today is headless — assistants and shopping agents calling HTTP endpoints. That door is open now. WebMCP's callers are still in preview, the spec is still moving, and there is no discovery mechanism for a crawler to find in the meantime. So WebMCP sits on our watchlist, not on our roadmap: the trigger to build is real browser-agent traffic on real merchant sites, not a specification milestone. When that traffic arrives, the second door gets built — as a progressive enhancement on the same catalog contract, not as a rewrite.

Two doors, one storefront. The mistake would be reading the new door as a replacement for the one agents are already walking through.

Sources