# No agent calls WebMCP yet. Here's the honest case for shipping it today — and how to know the day that changes.

> Source: <https://dev.to/r0bertini/no-agent-calls-webmcp-yet-heres-the-honest-case-for-shipping-it-today-and-how-to-know-the-day-52ld>
> Published: 2026-06-20 01:05:39+00:00

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

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 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*:

`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.`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.Done this way, the real cost of shipping WebMCP today is an afternoon, not a bet-the-roadmap commitment.

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

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.

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

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