WebMCP: How to Optimize for AI Agents and Measure What They Do

What WebMCP is – and isn't

A browser agent has to infer what your buttons do from a screenshot and the DOM, and it often gets it wrong. WebMCP takes that burden off it: your site declares its actions, and the agent calls them directly. This happens inside the browser, so it isn't a parallel world to the AI browsers, but structured help within normal browser operation. Unlike simply filling out existing forms, as the site operator you actively provide this, whether it's a shop, a booking site, or a B2B form.

The two APIs

WebMCP offers two ways to expose an action as a tool. The rule of thumb: if the action is already an HTML form, use the declarative API; if it isn't, use the imperative one.

Declarative: annotating existing forms

The declarative API works exclusively with <form> elements. You can't turn a single button, a <div>, or anything else into a tool with it, that's what the imperative API is for.

This is how the tool comes about: you attach toolname and tooldescription (both required) to the form, and toolname becomes the tool's name. Every input field automatically becomes a parameter via its name attribute. The special part: the browser also translates the normal HTML rules into the tool schema, required becomes mandatory, a <select> becomes a fixed list of choices, type, min, and max become limits. You explain the fields with toolparamdescription, the browser reads the rest from the form.

<!-- Becomes the tool "searchFlights" with the parameters -->
<!-- from, to, class, passengers, and when. -->
<form toolname="searchFlights"
      tooldescription="Searches for flights between two locations on a date"
      toolautosubmit>   <!-- Agent is allowed to submit itself -->
 
  <!-- Required fields, free text -->
  <input name="from" required
         toolparamdescription="Departure location or IATA code, e.g. CGN">
  <input name="to" required
         toolparamdescription="Destination or IATA code, e.g. JFK">
 
  <!-- fixed list of choices: the agent may only use these values -->
  <select name="class" toolparamdescription="Travel class">
    <option value="economy">Economy</option>
    <option value="business">Business</option>
    <option value="first">First</option>
  </select>
 
  <!-- number with limits -->
  <input name="passengers" type="number" min="1" max="9" value="1"
         toolparamdescription="Number of travelers">
 
  <input name="when" type="date"
         toolparamdescription="Departure date">
 
  <button type="submit">Search</button>
</form>

So declarative is more than just three attributes: you keep using the existing form semantics. The full attribute list, and how HTML rules become the schema, is in the Chrome documentation.

Whether the agent is allowed to submit itself is something you decide per form via the toolautosubmit attribute. Without the attribute, the agent only fills in the fields, the browser sets focus on the submit button, and the human has to click it themselves. With the attribute, the agent submits itself.

By default, the agent gets the result by the form submitting normally and the next page loading. If you'd rather return it a structured result without a page change, you intercept the submit event and respond via respondWith() (code in the measurement section below).

Imperative: actions as JavaScript functions

If the action isn't a form, you register the tool via navigator.modelContext. You provide a name, description, an input schema, and an execute function that runs on every call. Inside execute you simply call your existing JavaScript functions, you don't have to build anything new:

navigator.modelContext.registerTool({
  name: "addToCart",
  description: "Adds the displayed product to the cart",
  inputSchema: {
    type: "object",
    properties: { quantity: { type: "integer", minimum: 1, default: 1 } }
  },
  async execute(args) {
    return doAddToCart(args);   // your existing logic
  }
});

This way you give the browser your own, clearly scoped functions and retain full control over the schema and execution. Only the tools you register are callable, this doesn't create a new attack surface for your site.

How to make the AI agent visible in your tracking

The common pixel/DOM agents (Atlas, Comet, Claude for Chrome) run in a real user's browser and look, in your logs, like fast humans. WebMCP gives you the missing signal, in two ways depending on the API.

Imperative is the most robust, because your code runs on every call. You log directly inside the function:

async execute(args) {
  gtag("event", "agent_call", { tool: "addToCart" });   // e.g. to Google Analytics 4
  return doAddToCart(args);
}

Declarative gives you the signal for free from the browser: on the submit event sits a read-only flag, agentInvoked. The browser sets it, you only read it, true if an agent triggered the form, false on a human click.

form.addEventListener("submit", (event) => {
  if (event.agentInvoked) {
    // 1) report to Google Analytics 4
    gtag("event", "agent_submit", { tool: form.getAttribute("toolname") });
    // 2) optional: return a structured result to the agent
    event.preventDefault();
    event.respondWith(process(new FormData(form)));
    return;
  }
  // Human → normal flow
});

Measurement happens in the browser, from there you push the signal into your analytics (above via gtag to Google Analytics 4, or alternatively via the GTM dataLayer) or straight into the data warehouse. That way you can see when the channel starts picking up for your business, instead of flying blind.

Where WebMCP stands today

WebMCP is an open standard from Google and Microsoft in the W3C Web Machine Learning Community Group. Since May 2026 it has been in official Chrome, as an origin trial in version 149, so it can already be tried out on real sites. Edge is expected, Firefox and Safari haven't announced anything. And it's model-agnostic: you build your tools once, and any agent that speaks the standard can use them.

So far, exactly one agent consumes WebMCP tools: Gemini in Chrome. All the others (Claude, ChatGPT/Atlas, Perplexity, Edge) keep clicking and scraping. So it's genuinely in use, but conceivably narrow: one agent, one browser, test operation.

That could change quickly, though. WebMCP sits inside Chrome, the browser with roughly 65% market share. If Google moves the feature out of the paid US preview and rolls it out broadly or for free, reach jumps by a multiple of anything a single extension like Claude for Chrome could ever achieve. When that happens is an open question.

The upshot: small effort now, potentially a big channel later. Build WebMCP in now if you want the measurement head start. You shouldn't expect broad traffic this year, but once Google flips the switch, you don't want to be starting from scratch.

Where to start

Conclusion