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.

What actually changed

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.

Why being early is cheap (and why late is expensive)

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

• The cost to expose a tool is tiny. WebMCP tools are thin wrappers over handlers you already have — your site search, your cart, your booking form. You're not building new functionality; you're describing existing functionality in a way an agent can call.
• The cost of feature-detecting is zero. If navigator.modelContext isn't present, your code does nothing. No agent in the browser, no behavior change, no risk.
• The cost of being late is real. When Gemini in Chrome starts driving task completion on agent-ready sites, the sites that already exposed their search/checkout/booking flows are the ones that get completed instead of abandoned. You don't want to discover that gap from a competitor's conversion numbers.

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.

What to ship today (the honest version)

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.

The part nobody tells you to do: instrument it

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:

• It tells you which of your flows agents reach for first (so you instrument the next ones).
• It tells you where tool calls fail (bad schema, ambiguous descriptions, missing params) — agent UX debugging you can't do blind.
• It's the earliest possible read on agent-driven traffic to your site, before it's big enough to show up anywhere else.

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 somehow, with us or with a logging endpoint of your own. The teams that can answer "when did the first agent call our site, and what did it try?" are going to make much better decisions in the next six months than the ones guessing.

The honest caveats, kept honest

• It's "will soon," not "today." Don't promise your PM agent traffic next week.
• It's an origin trial. APIs can change; register for the trial rather than assuming stability.
• WebKit still formally opposes WebMCP. Multi-engine ubiquity is not guaranteed. That's exactly why feature-detection (lose nothing if it stalls) is the right posture.

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).