Right now, a browser agent trying to buy running shoes on an e-commerce site does roughly what a person would. Find the search bar, type a query, click, wait for results to render, then try to make sense of whatever the page displays. The agent is reading an interface built for human eyes and working backward to figure out what it means. Every layout change, every A/B test can break the sequence.
WebMCP, currently in a Chrome 149 origin trial and incubating in a W3C community group with Google and Microsoft co-authoring the spec, proposes something different. A website can publish structured tool definitions that tell an agent what actions are available, what inputs they expect, and what the response looks like. The agent calls searchProducts("running shoes") and gets back structured JSON. No screenshot parsing. No simulated clicks.
WebMCP runs inside the browser tab, reusing the user's live session and cookies. Anthropic's MCP connects agents to backend servers via JSON-RPC. They solve problems at different layers.
The improvement is real. But so is the question it opens: who decides what the agent can see?
Two Kinds of Editorial Choice
WebMCP has two APIs, and each one represents a different kind of choice by the site operator.
The Declarative API adds attributes to existing HTML forms. A newsletter signup gets a toolname and tooldescription; the browser auto-generates a schema from the form's fields. The form still works for humans, but agents can now see it as a callable tool. Progressive enhancement. A site with twelve forms might mark up three, though. Which forms get the attributes is already a selective representation, just a quieter one than writing JavaScript.
The Imperative API is more deliberate. The site registers JavaScript functions with names, descriptions, typed input schemas, and execution handlers. A searchProducts tool might accept a query string and a category parameter constrained to an enum: ["all", "clothing", "electronics", "books"].
Look at that enum. The actual product catalog almost certainly has more than four categories. Maybe "clearance" isn't listed. Maybe the full taxonomy runs fifty categories deep and the operator decided agents get a simplified view. The tool definition is a selective representation, and the agent has no way to know what was left out.
What the Agent Inherits
When a site publishes tool definitions, it's publishing its model of what matters about itself. The descriptions, the parameter names, the enum values, the return shapes. An agent receiving a searchProducts tool with a four-item category filter inherits that framing as the complete picture. There's no mechanism for the agent to ask "what else is there?"
And these definitions aren't static. The site can update its enum, remove a tool, add parameters. The agent's world reshapes accordingly, with no notification mechanism and no versioning contract. Today's editorial choice can change tomorrow without the agent or its operator knowing.
The practical status is early. Chrome 149 origin trial, Gemini in Chrome as the only current consumer, Firefox and Safari uncommitted. Performance claims circulating in developer blogs (67% fewer errors, 45% better task completion) trace to sources with undisclosed methodology. Treat them as directional.
But the architectural pattern is already legible. Once a website publishes tool definitions, it functions as a contract the agent trusts. What the site included shapes what the agent can do. What the site omitted disappears from the agent's world. A new kind of editorial power over agent behavior, and so far, nobody is measuring what gets left out.
Things to follow up on...
- Chrome's official WebMCP docs: The Chrome for Developers documentation walks through both APIs with working code examples, including best practices on tool naming, schema design, and avoiding overlapping tool definitions.
- WebMCP versus backend MCP: Chrome's team published a short guide on when to use WebMCP and when to use MCP, which clarifies how the two coexist for sites that need both browser-side and server-side agent integration.
- The methodological fine print: An arXiv paper (2508.09171) provides the closest thing to a disclosed benchmark for WebMCP performance, measuring token reduction and cost savings across 1,890 API calls rather than the "fewer errors" framing that circulates in developer blogs.
- Browser agents without structured tools: Fordel Studios published a practitioner-level explainer on how AI browser agents navigate the web today, covering the hybrid architecture of selectors, accessibility trees, and vision that WebMCP aims to partially replace.