There's an uncomfortable fact under all the WebMCP excitement, and the skeptics are right to keep raising it:

As of June 2026, none of the mainstream AI agents actually call navigator.modelContext on your site. Not ChatGPT Agent, not Claude, not Gemini, not Perplexity. They all still read your page by DOM-scraping or by taking screenshots and clicking pixels. Patrick Brosset's updates and studiomeyer's "Reality Check" both lay this out plainly, and it's worth repeating because the hype usually skips it: WebMCP is a W3C Community Group draft, not a standard, shipping behind a flag in Chrome and a Chrome 149 origin trial — and the agents that would consume it haven't wired it up.

So why would you add WebMCP tools to your site right now?

I think there's an honest answer, and it isn't "because it's the future, trust me." Let me make the actual case — including the part most "install it now" posts skip, which is what to do so the install doesn't quietly rot.

The cost side is genuinely near-zero

The reason "wait and see" feels safe is an assumption that adopting early is expensive. For WebMCP specifically, it mostly isn't — if you do it right:

• It's feature-detected, so it can't break anything. The entire surface lives behind if ("modelContext" in navigator). In every browser that doesn't ship the API — which today is almost all of them — your code is a no-op. Zero runtime cost, zero risk to existing users.
• It shouldn't add a second codebase. A WebMCP tool should be a thin, typed front door to a function your UI already calls. Your search_products tool calls the same productSearch() your search box calls. If you find yourself writing new business logic to satisfy an agent, stop — that's the expensive version, and it's the version that drifts out of sync.
• There's no migration to undo. Because it's additive and detected, "we were too early" has no cleanup cost. You delete a script tag.

Done this way, the real cost of shipping WebMCP today is an afternoon, not a bet-the-roadmap commitment.

The benefit side is a dated option, not a promise

What you're actually buying with that afternoon is an option that's worth the most precisely when it's least certain.

When agents do start calling typed tools — and the people building both the browsers (Google, Microsoft) and the agents are the same companies pushing this spec — the sites that already expose tools win the first wave of agent traffic with no scramble. The gap you're closing isn't "agent can read my page" (DOM scraping already half-works); it's "agent can complete the thing I sell on my page reliably, in one call instead of ten guessed clicks."

You don't have to believe that's six months away or eighteen. The point of an option is that you don't need to know the date. You need the cost of holding it to be low (it is) and the payoff if it hits to be high (for anything transactional, it is).

The part the "install now" posts skip: you won't notice when it starts mattering

Here's the failure mode of "ship it and forget it." You add the tools, they sit behind a feature flag in browsers nobody's agent uses yet, and then... nothing tells you when that changes. Six months later an agent does start calling search_products — and you find out from a billing anomaly, or a support ticket, or never.

If WebMCP is an option, you want to know the moment it goes in the money. That means instrumenting your tools from day one. At minimum, log every invocation yourself:

if ("modelContext" in navigator) {
  navigator.modelContext.registerTool({
    name: "search_products",
    description: "Search the product catalog",
    inputSchema: {
      type: "object",
      properties: { query: { type: "string" }, maxPrice: { type: "number" } },
      required: ["query"],
    },
    async execute(args) {
      // 👇 the line most implementations forget
      beacon("webmcp_tool_call", { tool: "search_products", args, ts: Date.now() });
      const results = await productSearch(args); // same fn your UI calls
      return { content: [{ type: "text", text: formatResults(results) }] };
    },
  });
}

That beacon() is the difference between "we have WebMCP somewhere" and "an agent called our search tool 240 times last Tuesday and 12 of those turned into carts." The second sentence is the one that gets WebMCP a line in next quarter's budget. The first one gets it quietly deleted in a cleanup PR.

Things worth capturing per call: which tool, the arguments (sanitize PII), whether execute succeeded, latency, and any user-agent / client hints you can get. You're building the dashboard that answers "are agents here yet, and what do they do when they arrive?" — which is the only honest way to manage an option instead of a guess.

Bottom line

The skeptics and the boosters are both right, and they're not actually in conflict:

• Skeptics: no agent calls WebMCP today. True. Don't let anyone tell you the robots are already shopping your store. They aren't yet.
• Boosters: ship it anyway. Also true — because it's cheap, feature-detected, and additive, and because the payoff lands exactly when you can't predict the date.

The synthesis is: ship it early, reuse your own handlers so it can't drift, and instrument it so you see the first real agent call the day it happens — not a quarter later. Adopt the option and the meter, or you've adopted neither.

Disclosure: I work on Latch, an open-source (MIT) one-line script that does the boring half of the above for you — it exposes your site's existing search/cart/forms as WebMCP tools (feature-detected, reusing your own handlers, valid schemas), and the optional hosted tier is exactly the "meter": it shows which agents call your tools and what they do, so you see the first agent visit instead of finding out from a billing anomaly. If you'd rather just understand the standard, the WebMCP guide is vendor-neutral, and the code is on GitHub. Happy to argue the trade-offs in the comments.