WebMCP (Web Model Context Protocol) lets websites expose JavaScript functions and HTML forms as named, agent callable tools, turning pixel scraping into an interface contract sites can design and audit, at least inside Chrome 149.
Chrome just put a proposed web standard into real-world testing that lets websites declare, in code, the actions AI agents are allowed to take inside the browser, replacing the brittle practice of agents inferring intent from screenshots and pixel coordinates.
The proposal is WebMCP (Web Model Context Protocol), and it entered an origin trial in Chrome 149, Google confirmed this month. Origin trials let sites opt in to an unstable, in-progress feature before it ships as a standard, and they let real agents call real functions against real pages, with the user still in the loop.
The mechanism is straightforward. A website exposes a set of "tools": named operations with declared inputs, outputs, and descriptions. An in-browser agent discovers them the same way it would find an API, but the API is being served by the page the user is already on. Two surfaces are defined in the Google Chrome for Developers WebMCP documentation: a Declarative API, which works through HTML form annotations such as toolname, tooldescription, and toolautosubmit, and an Imperative API, where developers register a tool in JavaScript via document.modelContext.registerTool with a name, description, input schema, and execute function.
The pitch is that this turns agent behavior into something a site can design, version, and audit, rather than something that survives only as long as the CSS does. The trade press read, captured in InfoQ's coverage of the Chrome origin trial, frames it as a structured contract replacing non-deterministic DOM scraping and screenshot-clicking.
The early performance story is suggestive but not yet corroborated. One anonymous developer running a forked Chrome DevTools MCP server with WebMCP tool execution reported on Hacker News that token usage dropped roughly 90 percent once the agent stopped iterating through screenshot-action-screenshot loops. That figure is a single self-measured benchmark, not an independent replication, and it should be read as labeled commentary about the cost shape of agent interactions, not as a published performance result.
The proposal is also tightly scoped. WebMCP is client-side only; it does not import the server-side concepts of MCP, like resources, and it is positioned as a browser counterpart to backend MCP rather than a replacement. The work is being shepherded inside the Web Machine Learning Working Group, where it sits alongside the broader Chrome AI work unveiled at I/O 2026. The only shipping surface today is the Chrome 149 origin trial, and registration runs through Chrome's origin trials console.
That vendor concentration is one of two structural questions the standard will have to answer. The first is governance. The team writing the proposal is also the team shipping the only browser that runs it, and there is no public signal yet from Mozilla or Apple on whether they will implement WebMCP or wait for a more neutral venue. Until that changes, "standard" is being used loosely; the working artifact is a Chrome trial of a spec that is moving.
The second is the new attack surface that comes with declaring tools at all. The proposal authors themselves flag indirect prompt injection as the primary threat: an agent that calls a tool whose description or output was shaped by an untrusted third party can be steered in ways the user did not ask for. The Chrome WebMCP documentation prescribes annotation hints for this, untrustedContentHint for externally sourced data and readOnlyHint for non-mutating operations, and recommends that developers run AI evaluations against targeted user journeys rather than relying on tool declarations to be safe by construction. Security gating is enforced at the origin level, with a Permissions Policy named "tools" that defaults to self, and cross-origin iframes that want access need an explicit allow="tools" directive.
The reference implementations hint at how a site author is expected to think. Demos published by GoogleChromeLabs on GitHub include a pizza order form (imperative), a flight search component (imperative), and a French bistro menu (declarative), small enough to read in a sitting, and a Model Context Tool Inspector extension that lets developers watch and exercise the tools a page exposes.
Two caveats are worth holding onto through the next browser cycle. First, WebMCP requires a live browsing context, so headless server-side agents do not get any of this; the page has to be open in a real browser tab. Second, sites that do not opt in do not get any of this either. The DOM-scraping fallback does not disappear for the long tail of the web; it just stops being the path a developer would choose for a flagship flow.
The standard is in motion, and the Chrome 149 origin trial is the first place where the friction between a declared interface and a learned-from-pixels one will get measured in production. What to watch is whether a second browser engine signals intent, and whether the prompt-injection mitigations get adopted as normative rather than advisory.