WebMCP Wants to Turn Every Website Into an Agent Tool

The way AI agents use websites today is a hack: they read the screen, guess which buttons to click, and hope the layout has not changed. WebMCP, a proposed open web standard that Google previewed at I/O 2026, wants to replace that guesswork with a contract. It lets a website expose structured tools, JavaScript functions and HTML forms, directly to browser-based agents, so instead of scraping your interface an agent can call the exact actions you have chosen to offer. It is an attempt to make the web natively legible to the agents that are about to start using it in bulk.

• WebMCP is a proposed open standard for exposing a website's capabilities as structured tools to browser AI agents.
• Sites define tools, JavaScript functions and HTML forms, that an agent can call directly, instead of parsing the visual UI.
• It borrows the Model Context Protocol idea and brings it into the browser, giving pages and agents a shared vocabulary.
• Google unveiled it at I/O 2026 alongside HTML-in-Canvas and element-scoped view transitions, part of a broader "agentic web" push.

What is WebMCP, in plain terms?

It is a way for a web page to advertise what it can do to a machine, not just to a human. The name nods to the Model Context Protocol, the emerging convention for describing tools to AI models, and WebMCP brings that idea inside the browser. A site author defines a set of tools, which can be JavaScript functions or HTML forms, and annotates them so an agent running in the browser understands what each one does, what inputs it needs, and when to use it. The agent then reads that manifest and invokes the tools directly. Crucially, this reuses the site's existing code and forms rather than requiring a separate backend API, so the same login form or search box a person uses becomes a callable action for an agent.

RelatedWebAssembly's JSPI Finally Closes the Async Gap

Why is screen-scraping such a bad foundation?

Because it is guessing dressed up as automation. When an agent drives a site by interpreting the rendered page, every interaction depends on the visual layout staying exactly where the model expects it. A redesign, an A/B test, a moved button or a new consent banner can silently break the whole flow, and the agent has no reliable way to know it clicked the wrong thing. It is also slow and expensive, since the model has to reason over the entire visual interface just to find one control, and it is a security minefield, because an agent that can click anything can be tricked by hidden or malicious page elements. WebMCP swaps that fragile perception loop for an explicit contract: the site says, here are the five things you can do and here is how, and the agent stops improvising.

How does it fit the wider "agentic web" push?

It is the interaction layer of a bigger bet Google is placing on the browser. At I/O 2026 the company paired WebMCP with rendering advances like the HTML-in-Canvas API and element-scoped view transitions, all aimed at a web where AI agents are first-class users, not awkward guests. The strategic tension underneath is real: the browser wars have shifted from whose search results you see to whose agent gets to act on your behalf inside the page. A standard like WebMCP matters because it decides whether that agentic future is open, any agent can read any site's declared tools, or locked to whichever company controls the dominant browser and assistant. Proposing it as an open web standard rather than a Chrome-only feature is Google trying to get ahead of that question, though a proposal is a long way from cross-browser reality.

What are the risks and open questions?

Security and consent sit at the center. If a page can hand an agent a set of powerful tools, the standard has to make it impossible for a malicious site to expose actions the user never intended to authorize, or to trick an agent into calling something harmful, which means permissions, provenance and clear user consent have to be designed in, not bolted on. There is also the perennial problem of adoption: a web standard is only useful if browsers and site authors actually implement it, and the last mile of getting Chrome, Firefox and Safari to agree, then persuading millions of sites to annotate their tools, is where most ambitious proposals stall. And there is a deeper question of incentive. Sites spent two decades optimizing to keep humans on the page and monetize their attention; a web designed for agents that complete tasks and leave upends that model, and not every publisher will want to make itself that easy for a bot to use.

RelatedChrome 150 Ships HTML-in-Canvas and Declarative Updates

Our take

WebMCP is aiming at the right problem, which is more than most agent hype can claim. Driving websites by screen-scraping was always a transitional kludge, and anyone who has watched an agent fumble a redesigned checkout knows it does not scale. Giving sites a way to declare their capabilities to agents is the obviously correct architecture, the same reason APIs beat screen-scraping everywhere else, and reusing existing forms and functions is a genuinely clever way to lower the adoption cost. The hard parts are the ones that always decide these efforts: a security and consent model strong enough to keep agents from becoming a new attack surface, cross-browser agreement in a market where the browser is now a competitive weapon, and a reason for publishers to cooperate with a future that may route users past their business model. Proposed as an open standard, WebMCP is the right instinct. Whether it becomes infrastructure or another good idea that never escaped one vendor's browser is the whole story from here.

Original analysis by GenZTech. Proposal status current as of July 2026. More at Chrome for Developers.