WebMCP (Web Model Context Protocol)

When an AI agent works inside a browser today, it mostly operates the page the way a human would: parse the rendered DOM, guess which button does what, fill fields, click, and hope the layout didn't change. That is brittle and slow. WebMCP proposes a direct channel instead: a site's own code registers named tools — searchFlights, addToCart, applyCoupon — on a standard browser interface, and an in-browser agent calls those tools with structured arguments.

The name signals the lineage. WebMCP borrows the core idea of mcp — a server advertising tools an AI client can call — but re-homes it in the browser. Anthropic's MCP is a server-side protocol spoken over JSON-RPC (stdio or HTTP) to connect a model to backend systems; WebMCP is a client-side JavaScript API, runs entirely in the page, and is sandboxed by the browser's existing security model. They are complementary, not competitors: a site could back its WebMCP tools with an MCP server, or not.

WebMCP is being incubated in a W3C community group with participation from browser vendors including Google and Microsoft, and early implementation work has appeared in Chrome's pre-release channels in 2026. As of 2026 it is a draft under active development, not a finished, broadly shipped standard — treat it as a direction the ecosystem is exploring for making websites "agent-readable" rather than something you can rely on in every browser today.

How it works

A page calls a browser API — the proposed shape is navigator.modelContext — to register one or more tools, each with a name, a natural-language description, a typed parameter schema, and a JavaScript handler function. A browser-side agent (built into the browser or an extension) reads that list the same way an MCP client reads a server's tool list via capability-discovery, decides which tool fits the user's goal, and calls it with arguments. The browser sits in the middle: it can require user confirmation before a tool runs, scope what a tool can touch, and keep the page's tools isolated from other origins. Because the handler is the site's own code, the site stays in control of what actually happens — the agent gets a clean, declared interface instead of a screen to reverse-engineer.

Example

A travel site adds three WebMCP tools: searchFlights(origin, destination, date), selectFlight(id), and startCheckout(). A user tells their browser agent "book me the cheapest nonstop to Berlin next Friday." The agent calls searchFlights, gets structured results, picks the cheapest nonstop, calls selectFlight, then calls startCheckout — at which point the browser shows the user a confirmation prompt before anything is purchased. No DOM scraping, no guessing which <div> is the price.

How it differs

Common misconceptions

FAQ