Run Lighthouse's Agentic Browsing category against your homepage. Three of its six audits will come back N/A. Not passed. Not failed. Not applicable, because your site doesn't implement WebMCP, and almost nobody else's does either.
That N/A is the whole story of WebMCP right now. There is a real spec. There is a real Chrome implementation you can turn on today. There is real audit tooling that checks it. There is also no primary source naming a single production adopter. Both halves are true at the same time, and nearly everything written about WebMCP picks one half and pretends the other doesn't exist.
So here's the version I'd give a client who asked whether they should care.
What WebMCP is, and what the name gets wrong
Chrome's documentation describes WebMCP as "a proposed web standard to help you build and expose structured tools for AI agents."
The load-bearing word is expose. Today, an agent that lands on your checkout has to work out your interface the way a person would: read the page, guess which input is the quantity field, click whatever looks clickable, hope the layout doesn't move underneath it. WebMCP inverts that. Your page hands the browser a list of things it can do, each with described parameters. Search products. Add to cart. Check a delivery date. The agent calls the tool, your code runs the action, and nobody has to reverse-engineer a div.
Then there's the name. WebMCP borrows from MCP, and that borrowing has caused more confusion than it saved. Implementing WebMCP is not the same as running an MCP server for your product, and it's not the same as publishing an MCP Server Card so agents can discover you (that's a separate signal, one Cloudflare's readiness checker looks for under Protocol Discovery). WebMCP is a browser API. Chrome's docs say it is "primarily designed for local browser workflows with a human in the loop": an agent already inside a browser tab, on a page a user opened, with that user watching. Chrome also acknowledges the discoverability gap outright. Nothing in WebMCP tells the outside world your tools exist.
If you were hoping this means agents anywhere on the internet can now transact with your backend, it doesn't. It means an agent driving a browser session on your site gets a cleaner interface than screen-scraping.
Where WebMCP came from, and how far it has actually gotten
| Question | Where it stands |
|---|---|
| Spec status | "Proposed", incubating in the W3C Web Machine Learning Community Group |
| Where to read it | webmachinelearning.github.io/webmcp, repo sitting at roughly 3.3k GitHub stars |
| Chrome | Origin trial, Chrome 149 through 156. Active, expires around late October 2026 |
| Firefox | No signal |
| Safari | No signal |
| Gating | Origin isolation, plus a tools Permissions Policy |
An origin trial is not a shipped feature. It's Chrome asking developers to try something so the spec can be revised before anything gets locked in. Two of the three major engines haven't publicly said a word yet. That isn't a knock on WebMCP. Standards incubate slowly on purpose, and this one is doing what the process asks of it. It does mean whatever you build against it now, you may end up rebuilding.
What a site can expose: registered tools and annotated forms
Two paths, and they cost wildly different amounts of engineering.
The imperative path
`document.modelContext.registerTool(...)` in JavaScript. You define a tool, describe its parameters with a JSON schema, attach a handler. This is the powerful version: anything your app can do becomes callable.
It's also the one that needs actual design thinking. What should an agent be permitted to do? What must it confirm with the human first? What happens when it calls the same tool twice because a response was slow? These are product decisions dressed up as an API, and no amount of markup will answer them for you.
The declarative path
Attributes on a form you already have:
- `toolname` — what this thing is called
- `tooldescription` — what it does
- `toolparamdescription` — what a specific field means
- `toolautosubmit` — whether an agent may submit it without a human touching anything
There's also `SubmitEvent.agentInvoked`, so your handler can tell whether a submission came from a person or an agent. Small detail, large consequences. That flag is where your rate limiting and fraud checks are going to live, plus your analytics, unless you enjoy explaining a conversion spike that turned out to be a crawler.
The declarative path matters more than it looks, because most of it isn't new work. A form with real labels and correct autocomplete attributes is already most of the way there. Adding two attributes to a well-built form is an afternoon. Adding them to a form assembled out of unlabeled divs and click handlers is a rewrite wearing a WebMCP hat.
Why Lighthouse marks its WebMCP audits N/A
Google added an Agentic Browsing category to Lighthouse in v13.3.0 (May 2026). It shipped to Chrome 150 DevTools and PageSpeed Insights, and it's scored as a fraction, 2/3 rather than 67/100. Six audits, and three of them are WebMCP:
| Audit | What it does |
|---|---|
| webmcp-registered-tools | Informative. Lists the tools your page registered |
| webmcp-form-coverage | Informative. Flags forms with no toolname or tooldescription |
| webmcp-schema-validity | Pass/fail on errors in your WebMCP JSON Schema |
On standard Chrome, all three are N/A. So the category most people are actually being graded on is a three-check test: the accessibility tree, cumulative layout shift, and whether your llms.txt is well-formed. You can run it yourself with `npx lighthouse <url> --only-categories=agentic-browsing`.
We benchmarked a few sites in August 2026. Stripe scored 3/3. Shopify got 2/3, tripped by ARIA role and button-name violations. Airbnb managed 1/2 on ARIA parent/children violations. Our own site started at 2/3 before we fixed our llms.txt formatting.
Worth sitting with what actually failed there. Not one of those sites dropped a point on WebMCP. They dropped points on buttons without accessible names. Google's own framing post from June 2026 calls the category "informational and unbenchmarked" and lists three focus areas: accessibility, stability, WebMCP integration. I don't think that ordering is accidental. If you want the full breakdown of every check, we pulled the category apart in what Lighthouse's Agentic Browsing audit actually checks.
Who is actually using WebMCP
No named production adopters appear in any primary source. Google's line is that "global consumer brands" are experimenting, without naming any. No mainstream agent consumes WebMCP yet, though Google says Gemini in Chrome "will soon support WebMCP APIs." John Mueller, reported by Search Engine Journal in June 2026, said "I like the WebMCP approach…" That's the high-water mark of public endorsement. Someone at Google liking the idea.
So if you've been shown a slide with a row of logos under the heading "WebMCP adopters," ask where it came from. I went looking. There's no source.
Meanwhile the agent traffic is real and growing. HUMAN Security's July 2026 data puts Comet at 47.1% of agentic browsing, the Claude Chrome extension at 24%, ChatGPT Atlas at 15.5% (now being sunset) and ChatGPT Agent at 6.1%, with agentic traffic up 7,851% year over year across 2025. But 76% of that activity sits on product and search routes. Checkout is 2.6%. Those agents are reading pages and clicking things. None of them are calling registered tools. So the boring layer is what pays off this quarter, and we went deeper on that gap in agentic commerce: when the buyer is an AI agent.
What to do today, and what to wait on
| Do now | Pilot | Wait |
|---|---|---|
| Fix accessibility-tree violations. Any single failure zeroes that audit | toolname / tooldescription on your two or three highest-value forms | Rebuilding your app around tool registration |
| Real <label for>, real <button>, stable layout, no ghost overlays | Handle SubmitEvent.agentInvoked in one flow and watch what shows up | Any roadmap commitment that assumes WebMCP ships as specced |
| Sane field names and autocomplete values | Register one read-only tool. Not "place order" | Treating WebMCP as a requirement, because nothing requires it |
The order matters. Google's guidance on building agent-friendly sites says agents perceive your pages three ways: screenshots, raw HTML, and the accessibility tree, which it calls "a high-fidelity map that ignores the visual 'noise' of CSS." Fix that map and all three views improve at once. Layout stability is on the same list for a plainer reason. Google's note on the CLS audit says agents taking screenshots "will likely be confused if your website layout is constantly shifting."
None of this is exotic. It's the same work that makes a site usable for people who navigate by keyboard or screen reader, which is why Google closes its own checklist with the line "Everything we suggest to make a site 'agent-ready' also makes sites better for humans." We've made a similar argument about why user experience decides whether a product survives, and the overlap here isn't a coincidence.
If your forms are clean and your accessibility tree is quiet, WebMCP is a small, cheap experiment you can run before the origin trial expires in October. If they aren't, it's a distraction from whatever is costing you agent conversions today. In my experience most teams can't tell you which of those two they are.
That's usually the first thing worth finding out, and it's what our free agent-readiness audit is for: we run the audits, read what an agent actually sees on your key flows, and tell you where WebMCP belongs in your queue. Which, for most sites in August 2026, is not at the top.
