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

As of June 2026, no mainstream AI agents call WebMCP tools, relying instead on DOM scraping or pixel clicking. A developer argues that shipping WebMCP today is low-cost and creates a valuable option for when agents do adopt the protocol, provided the tools are instrumented from day one to track usage.

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.