This is a submission for the Google I/O Writing Challenge
Right now, every AI agent that tries to use a website is basically doing this:
- Take a screenshot
- Guess what's on screen
- Click something and hope
- Take another screenshot
- Repeat until it works or gives up
It's the digital equivalent of reading someone's lips through a frosted glass window. It kind of works. It's slow, expensive, and breaks constantly on anything slightly dynamic — a modal, a lazy-loaded form, a JS-rendered button.
Google's answer to this is called WebMCP — Web Model Context Protocol. It entered a public origin trial in Chrome 149 on May 19, 2026, during the I/O Developer keynote. And I think it's the most consequential announcement of the whole event — not because of what it does today, but because of what it signals about where the web is going.
Let me show you what it actually is, how to use it right now, and why I have real questions about whether it will succeed.
What WebMCP Actually Does
The idea is simple: instead of making AI agents figure out what your website does by staring at it, you tell them explicitly.
WebMCP lets you expose structured tools — JavaScript functions and annotated HTML forms — directly to browser-based AI agents. The agent doesn't scrape. It calls your tool like an API.
There are two ways to implement it:
The Declarative API (for forms)
You annotate existing HTML forms with a data-mcp-tool attribute and a description. The agent reads the annotation and knows exactly what the form does.
All categories
Electronics
Clothing
Search
That's it. An agent seeing this form no longer has to guess what the fields mean or what the form does. You've told it.
The Imperative API (for JavaScript functions)
For more complex interactions, you register tools programmatically:
navigator.mcp.registerTool({
name: "add_to_cart",
description: "Add a product to the shopping cart by product ID and quantity",
parameters: {
productId: {
type: "string",
description: "The unique product identifier"
},
quantity: {
type: "number",
description: "Number of units to add",
minimum: 1
}
},
handler: async ({ productId, quantity }) => {
const result = await cartService.add(productId, quantity);
return { success: true, cartTotal: result.total };
}
});
An agent calling add_to_cart with { productId: "ABC123", quantity: 2 } will get a reliable result — no screenshot guessing, no DOM parsing, no retries.
Why I'm Genuinely Excited
1. This is a Google + Microsoft co-project
This is the detail that changes everything for adoption: WebMCP is developed jointly by Google and Microsoft in the W3C Web Machine Learning Community Group.
That's not just a Google standard. It's an emerging web standard with two of the biggest browser vendors aligned on the spec from day one. Cross-vendor agreement at this stage is rare and meaningful. It substantially increases the chance this becomes a real, lasting part of the web platform.
2. The timing is right
Browser agents — AI systems that navigate websites on your behalf — are growing fast. Gemini in Chrome, which will support WebMCP APIs, is one. Others are coming. Right now these agents are all fighting the same brittle DOM-scraping battle. WebMCP gives the web a way to meet them halfway.
Implementing WebMCP on your site today is the same category of investment as adding proper aria-label attributes in 2015 or adding og:title meta tags in 2012. It felt optional then. It became table stakes.
3. The developer experience is genuinely low-friction
The declarative API requires zero new JavaScript — just HTML annotations. You can expose your most common user flows to agents in an afternoon. The barrier is low enough that "let's try it" is a reasonable thing to say at a sprint planning meeting right now.
Where I Have Real Questions
I don't want to just be a hype machine, because there are genuine open questions here.
Firefox and Safari haven't committed
This is the elephant in the room. Mozilla and Apple have not signed on to WebMCP. For a standard to truly succeed on the web, it needs more than Chrome. Right now, if you implement WebMCP, it's Chrome-only by design.
That's not fatal — lots of meaningful features started as Chrome-only experiments before getting broader adoption. But it's a real constraint. If your user base is heavy on Safari (mobile web, Apple users), WebMCP tooling won't work for those agents browsing on Safari.
"No headless support" is a meaningful limitation
The official Chrome documentation is explicit: WebMCP requires a browser tab to be open. There's no support for agents to call your tools in a headless state.
This means WebMCP is specifically for in-browser agent interactions — not for server-side automation pipelines that many enterprise workflows rely on. For those use cases, you'd still need a backend MCP server. WebMCP and server-side MCP are complementary, not interchangeable.
The spec is not yet on the W3C official standards track
It currently lives in the W3C Web Machine Learning Community Group — an incubation space, not the full standards process. The path from origin trial to official web standard is long and uncertain. WebMCP could follow the path of Service Workers (proposed → standard → ubiquitous). Or it could follow the path of a dozen other promising origin trials that never made it.
What I'd Actually Recommend
If you maintain a web app with forms or user-facing workflows, here's what I'd do this week:
Step 1: Enable the flag in Chrome today
Go to chrome://flags and search for "WebMCP". Set it to Enabled, relaunch, and you can start testing immediately without waiting for Chrome 149.
Step 2: Pick your one most important user flow
Don't try to annotate everything. Pick the single form or interaction that an agent would most benefit from — a search form, a checkout step, a filter UI. Annotate it with the declarative API. It'll take an hour.
Step 3: Sign up for the origin trial
Visit the Chrome origin trial page and register your domain for the WebMCP trial. This lets you ship WebMCP support to real users before Chrome 149 hits stable.
Step 4: Watch what happens when Gemini in Chrome supports it
This is the moment that will make the investment pay off. When Google's in-browser agent can call your registered tools directly — that's when the "I annotated my forms" work starts delivering real value.
The Bigger Picture
Here's my actual take after sitting with I/O 2026 for a few days:
The Gemini model announcements are table stakes at this point. Every major AI lab releases faster, cheaper models every few months. That's not a story; it's a cadence.
WebMCP is different. It's infrastructure. It's Google (and Microsoft) trying to answer a structural question about the web's future: when AI agents become first-class citizens of the browser, what contract does a website make with them?
The answer they're proposing is WebMCP: an explicit, structured, queryable tool surface that gives agents what they actually need instead of forcing them to infer it.
If that standard gets adopted, it changes how we think about building for the web. We'll think about our web apps as having three user types: humans on desktop, humans on mobile, and AI agents. WebMCP is the API layer for the third type.
That is a genuinely new idea. And it came from a developer keynote that most people stopped watching after the Gemini 3.5 Flash benchmarks.
Are you going to try WebMCP in the origin trial? I'd love to hear which use cases you're thinking about — drop them in the comments.
Top comments (0)