What Is WebMCP? Your Website's API for AI Agents

WebMCP (Web Model Context Protocol) is a W3C browser standard that lets a website expose its own features to AI agents as structured, callable tools, through a new navigator.modelContext API. Instead of an agent taking a screenshot of your page and guessing where to click, your website hands it a list of the things it can do and the exact parameters each one needs. It inverts the control: the website tells the agent what's possible, rather than the agent reverse-engineering your interface. Authored by engineers from Google and Microsoft through the W3C Web Machine Learning Community Group and first announced on February 10, 2026, WebMCP is now in a public origin trial in Chrome 149.

When I first wrote about Chrome becoming an AI agent, Gemini could already scroll, click, and fill forms autonomously. That was the first half of the agentic-Chrome story: agents getting better at pretending to be human. WebMCP is the second half, and it's the more interesting one, because it stops the pretending entirely.

Updated June 9, 2026: WebMCP moved from a Chrome 146 flag preview to a public origin trial running Chrome 149 through 156. Corrected the unverified "Edge ships native WebMCP" claim (it isn't in Microsoft's official Edge 147 release notes), added WebMCP-vs-MCP-vs-llms.txt and browser-support comparison tables, added John Mueller's endorsement of WebMCP over llms.txt, and documented the four-tool WebMCP implementation now running on No Hacks.

Contents

• The problem with agents clicking buttons
• What WebMCP actually is
• Two ways to expose tools
• Human in the loop, by design
• Where WebMCP stands now (June 2026)
• WebMCP vs MCP vs llms.txt
• Which browsers support WebMCP?
• What this means for website owners

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 my 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, and was first announced on February 10, 2026. 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, and it's worth saying plainly because it's the conceptual breakthrough: WebMCP inverts the control. Today the agent has to figure out what your website can do. With WebMCP, your website tells the agent what it can do. A website registers tools using the new navigator.modelContext API, with each tool's inputs and outputs described by a JSON Schema:

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, reads the JSON Schema, calls the function with the right parameters, and gets structured data back. The whole interaction replaces dozens of screenshot-capture-interpret-click cycles with one structured tool call.

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 most powerful 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 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.

Where WebMCP stands now (June 2026)

WebMCP has graduated from a behind-a-flag prototype into a public origin trial that runs from Chrome 149 through Chrome 156. This is the part that's moved fastest since WebMCP first appeared. The Chromium "Intent to Experiment" was filed on May 15, 2026 and approved three days later. An origin trial means you can register your origin and run WebMCP on real users in production, not just on your own machine behind chrome://flags. The sole agent consuming those tools today is Gemini in Chrome.

On the cross-browser question, be careful what you believe. Plenty of secondary write-ups claim Microsoft Edge 147 ships native WebMCP support. I checked Microsoft's own Edge 147 web-platform release notes (April 9, 2026), and WebMCP is not in them, while the other on-device AI APIs of the moment (Prompt, Writer, Rewriter, Proofreader, WebNN) are. So treat Edge support as unconfirmed for now. What is verifiable, and still meaningful, is that Microsoft co-authored the spec alongside Google through the W3C. A second browser vendor helping write the standard is a real signal about its direction. A second browser shipping it is not yet a fact.

The endorsements are starting too. Answering operators on Reddit in June 2026, Google's John Mueller called the rival llms.txt file "purely speculative for now (the file has existed for years, yet none of the AI systems use it)," and said he likes "the WebMCP approach, as well as the commerce integrations" because "they have clear goals & processes" (reported by Search Engine Journal). When a Google Search advocate steers people toward the capability layer over the identity file, that's a signal about where the platform thinks the value is.

It is still early. Community Group draft status, Gemini-in-Chrome as the only consumer so far, and an opt-in model that requires you to do the work are all real constraints. But "real code in a public origin trial you can run on live users" is a very different place than "a proposal behind a flag," which is where this was four months ago.

WebMCP vs MCP vs llms.txt

Three agent-facing standards get confused constantly because the acronyms look alike. They answer different questions:

The short version: MCP connects agents to your back end, llms.txt describes your identity to agents, and WebMCP exposes your capabilities to agents in the browser. WebMCP and llms.txt are the two competing bets on the agentic web, identity versus capability, and that split is worth its own article. (Companion piece coming: llms.txt vs WebMCP, the identity bet vs the capability bet.)

Which browsers support WebMCP?

What this means for website owners

Websites are heading toward two interfaces: a visual one for humans and a structured tool surface for agents. A public origin trial already live in Chrome, and a standard co-authored by Microsoft and Google, make that direction hard to bet against.

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.

I implemented WebMCP on No Hacks itself, the JavaScript-API way. When a WebMCP-capable browser loads the site, it registers four callable tools through navigator.modelContext.registerTool. Two cover the glossary: list_terms to discover every term, and define_term to return a canonical definition with its source URL. Two cover the agentic-browser landscape: list_agentic_browsers to enumerate every tracked product by category, and get_browser for the full detail on one. Each tool reads from the same data file that powers the human-facing page, so an agent and a reader never get different answers, and the agent surface can't drift from the content. I used the imperative JS API rather than the declarative form annotations here because these are lookup tools, not form submissions. Running it on a live site, rather than only writing about it, is the fastest way to find where the rough edges actually are.

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.

The web is building a structured layer for agent interaction, and it's building it as an open standard through the W3C. Put the pieces together, MCP for backend tools, A2A for agent communication, NLWeb for website content, and now WebMCP for in-browser tools, and the infrastructure of the agentic web is taking shape, fast. The developers who get familiar with navigator.modelContext during this origin trial 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.