Gemini in Chrome is about to call WebMCP. The "no agent uses it yet" excuse just got an expiry date.

For most of 2026 the honest objection to WebMCP went like this: "Cool API. But no mainstream agent actually calls navigator.modelContext, so why ship it?"

I've made that argument myself in writing — it was true, and it was the right question to ask before spending a sprint on it.

Google just changed the answer. In its Google I/O 2026 round-up, the Chrome team wrote, plainly:

"Gemini in Chrome will soon support WebMCP APIs."

And as one developer who shipped WebMCP on their own site put it: "The sole agent consuming those tools today is Gemini in Chrome." So the picture for mid-2026 is: one named, mainstream, hundreds-of-millions-of-installs agent is the first real consumer — and it's coming from inside the browser most of your users already run.

That doesn't make WebMCP "done." But it does turn the objection from "no agent will ever call this" into "there's now a named agent and a soon." That's a very different bet.

Nothing about the spec. WebMCP is still an origin trial (Chrome 149–156), still experimental, still opposed by WebKit, still un-called by most agents today. If you were waiting for the standard to "settle," it hasn't.

What changed is the shape of the risk. Before: you instrument your site for an audience of zero, indefinitely. Now: you instrument it for a consumer that Google has publicly committed to shipping, riding in the default browser on most of your traffic. The expected value of being ready moved.

Here's the asymmetry that makes this an easy call once the consumer is named:

navigator.modelContext

isn't present, your code does nothing. No agent in the browser, no behavior change, no risk.The whole interaction replaces dozens of screenshot-capture-interpret-click cycles with one structured tool call. That's the entire pitch: reliability and speed for the agent, and for you, a flow that an agent can finish instead of fumble.

Don't rebuild anything. Wrap what you have, feature-detect, and lose nothing if the spec stalls:

if (navigator.modelContext) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search the catalog and return matching products.",
    inputSchema: {
      type: "object",
      properties: { query: { type: "string" } },
      required: ["query"],
    },
    async execute({ query }) {
      // call the SAME search you already expose to humans
      const results = await fetch(`/api/search?q=${encodeURIComponent(query)}`)
        .then((r) => r.json());
      return { content: [{ type: "text", text: JSON.stringify(results) }] };
    },
  });
}

Pick the two or three actions that are your business — search, add-to-cart, "book a call," "get a quote," "check availability" — and expose those first. One source of truth: the tool calls the same handler your buttons do.

Here's the move that turns "soon" into something you can actually manage. Once your tools are registered, log every agent call: which tool, what arguments, did it succeed. Because the day Gemini in Chrome (or any agent) first invokes one of your tools, you want to see it — not infer it three months later from a weird analytics blip.

That signal is genuinely useful:

You can wire this yourself with a few fetch

beacons. Full disclosure: I work on Latch — a one-line open-source script that exposes your existing search/cart/forms as WebMCP tools, and whose paid tier records exactly this (which agent called what, and whether it worked). I'm biased, so take the plug with salt — but instrument it

But the core thing has changed, and it's worth saying clearly: the strongest reason to not ship WebMCP — "no agent will ever call it" — now has a name attached to its expiry. The cheap, reversible, feature-detected version costs you an afternoon. I'd take that bet.

Building agent-ready sites? The vendor-neutral writeup is at latch.tools/webmcp, and the open-source client is on GitHub (MIT).