Data
State of WebMCP
An honest snapshot of adoption, and the limits of detecting it today.
No data yet. MCPWebsite V0.1 doesn't persist scan history — this page will populate once results are stored and aggregated in a future version.
Where things stand
WebMCP is early: a W3C Community Group proposal with one shipping implementation (Chrome, from Chrome 146 Canary, February 2026, behind an origin trial). No other major browser ships it yet, and there is no centralized directory of which sites implement it.
Why detection is hard for a static scanner
WebMCP tools are registered by JavaScript at runtime (navigator.modelContext.registerTool()). A scanner that only fetches and reads HTML — which is what MCPWebsite's V0.1 scanner does, deliberately avoiding headless-browser automation for cost and scope reasons — cannot execute that code. It can only look for the literal API call in the scripts it already has.
How we report it
Every scan reports one of three WebMCP states, and we never collapse the second two into a flat "no":
- Detected — a literal
registerTool()call was found in an inline script and could be parsed. - Unable to verify — the page references WebMCP-adjacent code or loads external scripts we didn't inspect, so we can't rule it in or out.
- Not detected — no related signal was found anywhere in the inline scripts we could read.
What's next
As the specification stabilizes and adoption grows, this page will track real adoption data gathered from MCPWebsite scans. For now, treat WebMCP as a forward-looking signal — most of your Agent Readiness score should come from the fundamentals: accessibility, structured data, business information, and clearly identifiable actions.