WebMCP: Inside Chrome 149's Plan to Kill DOM-Scraping Agents
For two years, every "browser agent" demo has worked the same shaky way: an LLM stares at a screenshot, guesses which pixel is the checkout button, and clicks. WebMCP — Google's new origin-trial standard landing in Chrome 149 — is an explicit attempt to retire that approach. Instead of agents pretending to be humans, websites declare their own tools, and agents call them like an API.
It's the most consequential thing Google announced at I/O 2026, and almost nobody outside the platform-engineering crowd is talking about it.
The Problem WebMCP Solves
Browser agents today rely on actuation — Chrome's term for "an agent simulating manual mouse clicks and text input, as though it were the human user." That works in demos and fails in production for three predictable reasons:
- DOM brittleness. A class name changes from
btn-primarytobtn-checkout, and the agent breaks. - Visual ambiguity. Two buttons say "Continue." The agent picks the wrong one.
- Multi-step compounding error. A 6-step workflow at 90% step-accuracy completes 53% of the time. At 5 steps, 59%. The math is unforgiving.
The fix WebMCP proposes is structural. Instead of the agent inferring what the page can do, the page declares it — with explicit names, JSON Schemas, and execution functions.
"Instead of an agent reviewing the element, such as a button or a field, to understand its purpose, the website declares the element's purpose, so it's used correctly." — Chrome for Developers documentation
Two APIs, One Standard
WebMCP ships in Chrome 149's origin trial with two surfaces. Pick based on how much JavaScript you're willing to write.
Imperative API: JavaScript tool registration
This is the power-user path. You call navigator.modelContext.registerTool() and hand it a name, description, JSON Schema, and an execute function:
navigator.modelContext.registerTool({
name: 'toggle_layer',
description: 'Control pizza layers (sauce, cheese). Use "add", "remove", or "toggle".',
inputSchema: {
type: 'object',
properties: {
layer: { type: 'string', enum: ['sauce-layer', 'cheese-layer'] },
action: { type: 'string', enum: ['add', 'remove', 'toggle'] },
},
required: ['layer'],
},
execute: ({ layer, action }) => {
toggleLayer(layer, action);
return `Performed ${action || 'toggle'} on layer: ${layer}`;
},
});
Tool registration is reversible via AbortSignal, which means tools can appear and disappear with route changes — important for SPAs.
Declarative API: HTML annotations
The lower-effort path is annotating standard <form> elements. The form becomes the tool; the fields become its parameters. No JavaScript required if the form already does what you need.
Google's reference demos — WebMCP zaMaker (imperative), Travel demo in React (imperative), and Le Petit Bistro (declarative) — are all open-source on the GoogleChromeLabs/webmcp-tools repo.
Three Primitives That Make It Real
The spec hangs on three building blocks:
| Primitive | What it does |
|---|---|
| Discovery | A standard way for pages to register tools with agents (e.g., checkout, filter_results) |
| JSON Schemas | Explicit input/output definitions that cut hallucination |
| State | A shared, real-time view of the current page context |
That third one — state — is the underrated piece. The agent doesn't just know what tools exist; it knows what's in the cart right now. That's the difference between "click the cheese button" and "remove cheese from the current order."
How It's Gated
WebMCP is locked behind a new Permissions Policy called tools. It defaults to self:
- Tool registration is enabled in top-level and same-origin contexts.
- Tool registration is disabled in cross-origin iframes.
To allow tools inside an embedded iframe, you'd add allow="tools" to the iframe element. This is the same security pattern the web uses for camera, microphone, and clipboard — and it's a sane choice. Without it, any ad iframe could expose hostile tools to a user's agent.
For local development before Chrome 149 lands, the flag lives at chrome://flags/#enable-webmcp-testing.
WebMCP vs. MCP — They're Not the Same Thing
Anthropic's MCP (Model Context Protocol) and Google's WebMCP share an acronym and a worldview, but they sit in different places in the stack:
- MCP is a back-end protocol. AI platforms connect to service providers through hosted MCP servers. Servers run somewhere; the agent calls them remotely.
- WebMCP is a browser standard. Tools live in the page the user is currently viewing. The agent talks to them through
navigator.modelContextinside the same browser tab.
The two complement each other. An agent might call an MCP server to look up a customer record, then call a WebMCP tool on the airline's site to actually rebook the flight. Same agent, two protocols, one workflow.
The Limitations Google Actually Admits
Credit where it's due — Chrome's own docs list what WebMCP can't do:
- Browsing context is required. Tools are JavaScript; JavaScript needs a tab. No headless support.
- Complex sites need refactoring. If your app's state lives in a sprawling Redux tree, you'll be plumbing tool definitions through it.
- Tool discoverability is per-site. Agents must visit a URL to know its tools exist. There's no global registry.
That last point matters. WebMCP doesn't solve the navigation problem ("how does my agent find a flight-booking site?"). It only solves the interaction problem once the agent gets there.
Who Implements It First
The early-preview program is open via Chrome's developer site, and the experimental origin trial begins in Chrome 149. Google's own Gemini-in-Chrome features will plug into WebMCP — natural, since Google ships both. Microsoft Edge is expected to follow given the shared Chromium base.
The standard itself lives in the W3C Web Machine Learning Community Group, on GitHub. The Chrome Status entry is feature ID 5117755740913664 — worth bookmarking if you want to track shipping signals.
What This Means for Web Developers
If WebMCP gains traction, the SEO playbook gets a sibling discipline: Agent Experience Optimization. The questions you'll be asked in 2027:
- Which of your site's actions are exposed as WebMCP tools?
- Are your JSON Schemas clean enough that an agent calls them correctly the first time?
- Does your
checkouttool include a confirmation step before charging the user's card?
The companies that ship clean tool surfaces will be the ones agents prefer to use. The ones that don't will get scraped, slowly, by agents fumbling through their DOM.
The Bottom Line
WebMCP is the boring, infrastructural standard that has to exist for agentic browsing to stop being a parlor trick. It won't trend on Hacker News the way Gemini Spark did, but in two years it'll be the layer those agents actually run on — assuming Chrome ships it, Edge follows, and developers find the Permissions Policy and JSON Schema tax worth paying. The bet Google is making is that they will. The bet against it is that nobody implements until someone forces them to. History suggests Google forcing the issue, via Gemini in Chrome, is exactly what's coming next.
