Something changed at Google I/O 2026. Alongside the usual parade of model updates and cloud product announcements, Google and Microsoft quietly introduced a proposal that has significant implications for anyone building browser agents: WebMCP.
If you have been following Anthropic's Model Context Protocol—and if you build on Anchor, you almost certainly have—WebMCP will feel immediately familiar. It is MCP applied to the browser itself, and it is worth understanding now, while it is early.
The Problem WebMCP Solves
Browser agents today interact with websites the same way a blindfolded person might: by interpreting what they can see on screen and guessing at the underlying structure. Visual DOM scraping works, but it is inherently brittle. A website redesign breaks your agent. A dynamic component that renders slightly differently on a Tuesday breaks your agent. A modal that appears only under specific conditions breaks your agent.
The deeper problem is that websites were never designed to be machine-readable in the way agents need them to be. The HTML on a product page communicates information to a human eye. It does not expose a clean, stable interface for an agent trying to complete a purchase workflow.
WebMCP proposes a fix: let websites declare the tools they offer, directly in the page, so agents can call structured functions instead of simulating clicks.
How It Works
WebMCP offers two implementation paths, both designed to be low-friction for site developers.
The declarative API uses HTML attributes on existing form elements—toolname, tooldescription, and toolparamdescription—to register tools without writing a single line of JavaScript. A search form annotated this way becomes callable as searchProducts({query: "laptop"}) rather than requiring the agent to find the input, type into it, and wait for results to render.
The imperative API gives JavaScript developers more control, using navigator.modelContext.registerTool() with JSON Schema definitions for complex, dynamic interactions. Both approaches execute in-browser with access to the user's session and cookies—no backend changes required.
The standard is currently in Chrome 149 origin trial. Microsoft Edge added support in March 2026. Firefox has committed to Q3 support; Safari is expected in Q4. For sites that need cross-browser coverage today, a polyfill is available.
The Numbers That Matter
Early benchmarks from the WebMCP origin trial are striking. Structured WebMCP calls produce 67% fewer errors and 45% better task completion rates compared to visual scraping on the same pages. E-commerce workflows—a notoriously difficult category for browser agents—see agents completing purchases roughly three times faster on WebMCP-enabled sites.
These numbers reflect something intuitive: when an agent can call a defined function instead of interpreting a rendered interface, a large class of failure modes simply disappears.
What This Means for Agent Developers
The adoption picture is still early. Roughly 12% of enterprise websites have started WebMCP implementation, with e-commerce leading at 41%. For most production agent workflows, visual DOM interaction remains the primary path for the foreseeable future.
That said, WebMCP is worth tracking closely for two reasons.
First, if you are already building on MCP—which Anchor's infrastructure is designed around—the mental model transfers almost directly. WebMCP is an extension of the same pattern: tools described by schema, called with structured inputs, returning structured outputs. Teams with existing MCP workflows are, by most accounts, around 90% of the way there.
Second, when a site does implement WebMCP, you want your agent infrastructure ready to take advantage of it. The reliability gains are not marginal. An agent that can call a placeOrder function is categorically more reliable than one parsing a checkout flow rendered in React.
WebMCP and Existing Browser Infrastructure
One misconception worth addressing: WebMCP does not make cloud browser infrastructure obsolete. The two systems are complementary. WebMCP-enabled pages handle the interaction layer more cleanly—but the agent still needs a browser to load those pages, authenticate, manage sessions, and handle the overwhelming majority of sites that will not implement WebMCP for years, if ever.
Reliable IP reputation, coherent browser fingerprints, and persistent session state remain critical regardless of whether the target site speaks WebMCP. What changes is that on sites that do support it, your agent can delegate the navigation complexity to the site's declared interface rather than reconstructing it from the DOM.
The Trajectory
WebMCP is early. The standard is not finalized, browser support is still rolling out, and most of the web has not heard of it yet. But the direction it signals—a web that is designed to be agent-readable, not just human-readable—is meaningful for anyone building on browser infrastructure today.
The teams best positioned to benefit are the ones already building agent workflows on solid infrastructure. When WebMCP-enabled sites become common enough to matter, the shift from visual scraping to structured tool calls will be a configuration change, not a rewrite.
See how Anchor handles both WebMCP and traditional browser automation →
