Right now an AI agent “uses” your website the way a tourist reads a city from a helicopter: it scrapes your DOM, parses screenshots, and reverse-engineers what each button probably does. WebMCP is the move from helicopter to front door. The site hands the agent an actual key. It is a browser-native API that lets a site register structured tools through navigator.modelContext.registerTool, which an in-browser AI agent can then call by name. Google announced it at Google I/O 2026, and it landed as a Chrome 149 origin trial in May. This post covers what it is, what I shipped on GuardingWP this week, the product insight nobody is talking about, and the honest answer to “but nothing calls it yet.” Treat it as part of building modern sites for an agentic web.
What WebMCP actually does (and what it replaces)
Today’s agent browsing is clumsy. The agent takes a screenshot, walks the DOM, pokes at the accessibility tree, and guesses. WebMCP flips the model. The site declares its capabilities as named tools, and the agent calls them directly with structured input.
The API is small. You call navigator.modelContext.registerTool(tool, { signal }), where tool is an object with name, description, inputSchema, and an execute callback. The execute callback receives the structured input and returns a Promise. I returned the MCP-style content block, { content: [{ type: “text”, text }] }, which mirrors the server-side MCP convention. The spec itself only specifies Promise<any>, so that shape is my choice, not a requirement.
The status matters as much as the API. WebMCP is a W3C Draft Community Group Report dated May 20, 2026 (spec). That is incubation. It is explicitly not a W3C Standard and not on the Recommendation track. It is co-edited by Google (Khushal Sagar, Dominic Farolino) and Microsoft (Brandon Walderman), it has 87 open issues as of this week, and at least two sections are still marked TODO, including requestUserInteraction. So why bet on it at all? Chrome and Edge together hold about 73.55% of the browser market (Statcounter, April 2026). Both are Chromium-based, and both vendors co-authored the spec. Even if formal cross-browser standardization stalls, a de facto standard across three quarters of browsers is its own kind of real.
What I shipped on GuardingWP
One tool. GuardingWP, a SaaS I built for scanning WordPress security, now registers scan-wordpress-security({ url }) on the client, behind a feature check.
The tool itself
The input is a single WordPress site URL. The output is deliberately thin: WordPress yes or no, a letter grade, a numeric score, the single most-severe finding, and a deep link to the full report. That is it.
The interesting part is what sits behind it. The tool’s execute() calls the exact same /api/report endpoint my normal scanner uses. So every guard I already built applies automatically: the 55-second cooldown, the SSRF URL validation, the per-host rate limit, the result cache, the concurrency slot. I added no new server attack surface, because there is no new server code. The tool is a wrapper.
The whole thing is feature-detected with if (navigator.modelContext). On the browsers that ship the API today, which is almost none, the tool registers. On every other browser, nothing happens and nobody notices. That is pure progressive enhancement: no degraded experience, no fallback to maintain, no risk to the existing scanner.
The funnel-disintermediation insight
Here is the part no explainer covers, and the part I think actually matters.
WebMCP can quietly eat your own funnel. If your tool hands the agent everything, the agent consumes your entire value proposition and the user never lands on your page. They get your answer in a chat window. You get nothing: no visit, no signup, no relationship, no idea it happened. The better your tool, the worse this gets. That is disintermediation, and you create it for yourself the moment you return too much.
So I designed the output to lead back to me. The tool returns a teaser, not the report. A grade and the single worst finding are enough signal to make the result feel real and to earn a click. They are not enough to replace the full scan, which is where the actual value and the conversion live. The agent gets a useful, honest answer. The user gets a reason to come to the site.
Then I closed the loop on the click. I added a ?url= deep-link that prefills the scanner and auto-runs it. When the agent does its headless scan through the tool, that warms my five-minute result cache. So when the user follows the link, the full report is usually already computed and lands instantly. The agent’s call pays for the user’s wait.
This is not a clever trick bolted on afterwards. It is the first-principles question you should ask about any tool you expose: does this output earn the next step, or give the whole thing away? The data backs the instinct. Walmart saw roughly 3x lower conversion on in-chat AI purchases compared to redirecting users to its own site (Commercetools agentic commerce research). The click is not friction to be removed. For now it is where the money still is.
The honest part: almost nothing can call this yet
Let me be blunt about the traffic. It is near zero.
Gemini in Chrome announced WebMCP support as “coming soon” at Google I/O 2026 on May 19. It has not shipped. No other major agent has committed to calling these tools: Anthropic’s 2026 MCP roadmap has no explicit WebMCP entry, and there is no commitment from ChatGPT either. This is a Google-led bet, and I want to say that out loud rather than imply broad industry adoption that does not exist.
There are two honest camps on WebMCP. The optimists point to the Google I/O spotlight, Expedia’s live demo, and a real roster of trial adopters: Booking.com, Shopify, Etsy, Instacart, Target, Credit Karma, TurboTax, Redfin. The skeptics point to Chrome-only support, 87 open issues, critical spec sections still TODO, and the fact that nothing calls these tools in production today. Both camps are correct, which is the strange part: the bull case and the bear case are true at the same time.
Both camps are answering the wrong question. They are debating “will it win,” which nobody can answer yet. The question I can answer is “is the expected value positive given my build cost.” Mine was a few hours wrapping an endpoint I already had. Downside if it dies: I lose those hours and a tool registers for nobody. Upside if the agentic web lands: I am early on infrastructure my competitors have not touched. The agentic AI market sat around $8.5 billion in 2026 and is projected near $35 billion by 2030 (Deloitte/Gartner via Wix AI Search Lab). Gartner expects 15% of day-to-day work decisions to be made autonomously by agents by 2028. I do not need those numbers to be right. I only need the upside to be worth a thin wrapper. It is. The same logic applies to GEO: you prepare the surface before the traffic arrives, because the prep is cheap and the catch-up is not.
Why a security scanner is the textbook WebMCP fit
Not every feature on your site maps cleanly to a tool. A scanner does, and the reasons make a useful filter for your own site. A good WebMCP tool needs three things:
- Clear structured input. One unambiguous parameter the agent can fill. A URL string qualifies. “Help me plan my trip” does not.
- Deterministic structured output. The result is data the agent can hand back, not a stateful flow. A grade and a finding qualify.
- Read-only, no confirmation required. The tool reads and reports. It does not buy, mutate, or commit anything on the user’s behalf.
scan-wordpress-security hits all three. Input is a URL, output is a grade plus a finding, and a scan changes nothing, so I never need requestUserInteraction. Which is convenient, because that part of the spec is still TODO. Checkout and subscription changes are the opposite case: they mutate state and need user confirmation, so they need the confirmation gate that does not exist yet. Do not ship those as tools today. Ship the read-only ones.
The prep is cheap now.
The agentic web is not a future state you brace for. It is a present-tense infrastructure bet you can place cheaply today. Building a site an AI agent can operate is now a thing you do in practice, not a thing you theorize about, and it costs about an afternoon for a read-only tool. If you want a site built with this kind of infrastructure in mind, that is how I build.
The prep is cheap now.