Two weeks ago, I wrote about Chrome becoming an AI agent. Gemini can now scroll, click, and fill forms autonomously. That was the first half of the agentic Chrome story.
Chrome v146 will ship with the other half.
WebMCP is a proposed web standard that lets websites expose structured tools directly to in-browser AI agents. Instead of an agent guessing which button to click or scraping your DOM to find a price, your website publishes a menu of tools with defined inputs, outputs, and behaviors. The agent reads the menu, calls the function, gets structured data back.
It changes the relationship between websites and AI agents entirely. I have been testing how AI agents handle web forms a lot lately, and the only thing I can say is that we need something like WebMCP, badly, if this will ever truly work.
The problem with agents clicking buttons
Current agentic browsing works through visual UI automation. Chrome's auto browse uses Gemini to "see" web pages and interact with them the way a human would. Click this button. Fill this form. Scroll down. Look for the checkout link. Other agentic browsers also do a version of this.
It works. It's also so very fragile.
Every time you redesign your website, change a button label, or rearrange its layout, agents relying on visual cues have to re-learn the interface. It's the same brittleness that plagued web scrapers for two decades (any Beautiful Soup fans here?), now applied to AI. The web UI was designed for human eyes and human hands. Forcing agents to navigate it visually is working against the grain of the medium. It CAN work. Very often, it will not.
WebMCP takes a different approach entirely. Instead of making agents better at pretending to be humans, it lets websites speak to agents in their native language: structured data with defined schemas.
What WebMCP actually is
WebMCP is MCP for the browser tab.
If you've been following along with our coverage of the Model Context Protocol, you know MCP is the universal adapter that connects AI agents to tools and data sources. MCP servers run on backend infrastructure, exposing tools that AI systems can call.
WebMCP brings that same model to client-side JavaScript. Your website becomes the MCP server. Tools are defined and executed right in the browser, no backend required.
The proposal comes from the W3C Web Machine Learning Community Group, authored by engineers from Microsoft and Google. It's being developed as an open web standard, not a Chrome-exclusive feature. And it's explicitly model-agnostic: it works with any AI agent, whether the agent is powered by Gemini, Claude, ChatGPT, or something open-source.
Here's the core idea. A website registers tools using a new navigator.modelContext API:
navigator.modelContext.registerTool({
name: 'searchFlights',
description: 'Search available flights by route and date',
inputSchema: {
type: 'object',
properties: {
origin: { type: 'string', description: 'Departure airport code' },
destination: { type: 'string', description: 'Arrival airport code' },
date: { type: 'string', description: 'Travel date' }
},
required: ['origin', 'destination', 'date']
},
execute: async (params) => {
const results = await searchFlightsAPI(params)
return { content: [{ type: 'text', text: JSON.stringify(results) }] }
}
})
An AI agent visiting this page doesn't need to find the search form, figure out which fields to fill, or guess at the submit button. It discovers the searchFlights tool, sees the schema, calls the function with the right parameters, and gets structured data back.
No DOM scraping. No layout guessing. A clean contract between website and agent.
Two ways to expose tools
WebMCP offers two approaches, and you can use both on the same page.
The JavaScript API (shown above) is the best approach. You register tools programmatically, define schemas, and provide execute functions. Full control over inputs, outputs, and the logic in between.
The HTML form approach is declarative. You annotate existing <form> elements with new attributes:
<form toolname="searchFlights"
tooldescription="Search available flights by route and date">
<input name="origin" type="text" required />
<input name="destination" type="text" required />
<input name="date" type="date" required />
<button type="submit">Search</button>
</form>
These two remind me of Schema.org and microdata.
The browser translates form fields into tool schemas automatically. When an agent invokes the tool, the browser pre-fills the form and (by default) waits for the user to click submit. Adding a toolautosubmit attribute allows the agent to submit directly.
The form approach is the one worth paying attention to. It builds on existing HTML. If your website already has well-structured forms with proper labels and input types, you're most of the way to a WebMCP implementation. Add a few attributes and your human-facing forms double as agent-facing tools.
Human in the loop, by design
WebMCP doesn't hand full control to agents. The security model is browser-mediated.
Tool calls go through the browser, not directly from agent to page. Users can review which tools an agent is accessing. Forms will require manual submission by default. The API includes agent.requestUserInteraction() for cases where a tool needs explicit user confirmation mid-execution. And tool calls execute sequentially, preventing agents from firing off dozens of actions simultaneously.
There's also a useful detail for developers: SubmitEvent.agentInvoked is a boolean flag that tells your form handler whether the submission came from an AI agent or a human. You can return structured data to agents while keeping the normal form flow for humans. Same form, different response paths.
CSS pseudo-classes (:tool-form-active on forms, :tool-submit-active on submit buttons) let you visually indicate when an agent is interacting with an element. Your users can see what the agent is doing, which builds trust in the whole interaction.
The Chrome 146 preview
Chrome 146 beta is now available with WebMCP behind a flag. To try it:
- Navigate to chrome://flags
- Search for "Experimental Web Platform features"
- Enable the flag and relaunch Chrome
Chrome 146 stable is expected around March 10, 2026. This is a developer trial, not a public launch. But it's real, working code that you can build against today.
There's already a Model Context Tool Inspector extension on the Chrome Web Store for viewing registered tools and testing them manually. Chrome DevTools is getting a dedicated WebMCP panel for debugging schema errors and failed tool calls.
What this means for website owners
If this standard gains traction, and having Microsoft and Google co-authoring the proposal is a strong signal, websites will eventually need two interfaces: a visual one for humans and a structured tool surface for agents.
That's less daunting than it sounds. The declarative form approach means your existing HTML forms can double as agent tools with minimal markup changes. The investment in semantic HTML and accessible forms that I've been writing about pays off once again.
The competitive implications are real. Today, when Chrome's auto browse visits your website and your competitor's website, it's guessing at both interfaces equally. Once WebMCP adoption picks up, the website that exposes structured tools gives agents a clear, reliable path to complete their task. The website that doesn't still forces agents to guess. All else being equal, the agent will prefer the path that works. It's cheaper that way.
This is also where Agent Experience Optimization evolves from "make your website accessible to agents" to "design your website's agent interface." Tool naming, schema design, and the quality of your tool descriptions become optimization surfaces. If that sounds familiar, it should. It's the same shift that happened when meta descriptions and structured data became optimization surfaces for search engines.
Very early days, clear direction
WebMCP is a proposal behind a flag in a beta browser. It doesn't have signals from Firefox or Safari yet. The interoperability story is unwritten.
But the direction is unmistakable. The web is building a structured layer for agent interaction, and it's building it as an open standard through the W3C. When you look at the full picture: MCP for backend tools, A2A for agent communication, NLWeb for website content, and now WebMCP for in-browser tools. The infrastructure of the agentic web is taking shape, fast.
For now, WebMCP is worth understanding and experimenting with. The developers who get familiar with navigator.modelContext today will be ready when it ships for real. And the website owners who start thinking about their website's tool surface, not just its visual surface, will be the ones agents prefer when the time comes.