The First 81 WebMCP Deployments — 72 Are One Script

WebMCP is the W3C draft that lets a web page register typed, callable tools with the browser — document.modelContext.registerTool() — so an agent running in your browser can drive a site’s actual functionality instead of scraping its DOM. Chrome ships it as an origin trial (149–156). No mainstream agent calls these tools yet. It is exactly the kind of forefront that is worth measuring from t=0, so we started measuring it.

We probed the 730 providers in the catalog that already run a hosted MCP endpoint — the population most likely to have gone browser-native too. The probe is deliberately narrow: it only counts a provider when the modelContext object and a registration call appear in the same script served by the provider’s own pages, so an article about WebMCP can never score as shipping it. That caution turned out to be necessary — at least one provider already markets a plain server-side MCP endpoint as its “WebMCP Server.”

The result

Seventy-two of the eighty-one are one <script> tag. ReadMe.io’s documentation-hub bundle registers a search_docs tool on every docs site it hosts — we verified the registration in the bundle itself, which feature-detects document.modelContext ?? navigator.modelContext and calls registerTool. A documentation platform quietly made seventy-two API providers’ docs agent-drivable, and it is a fair bet most of them don’t know.

The provider-engineered deployments number nine: Cloudflare (on two properties), Zapier, Nylas, Render, and four self-hosted — two of which serve a shared /.webmcp/bridge.js pattern that looks like a framework fingerprint worth watching.

Six of the eighty-one ship only the original navigator.modelContext surface, which Chrome deprecated in 150 when the spec moved tools onto document. That is the other curve worth having from day one: not just who adopts a draft API, but who keeps up when it moves — a feature-detected draft API that stops matching fails silently, and we know because our own homepage tools did exactly that before this pass caught it. apis.io registers WebMCP tools on its homepage and Stack page, and the rebuild onto the current document surface — with adoption telemetry this time — is in the pipeline.

What the Kin Score does with it

WebMCP is now an observed signal in the Agent Readiness layer — tracked on every scoring pass, worth zero points. The raw count already clears the 25-provider line that normally promotes a signal to a scored dimension, and we are deferring anyway: 72 of the 81 are one platform’s engineering, and a dimension that credited them would be handing providers points for ReadMe’s work — the same wrong-party credit the 0.18.0 rubric release just spent two checks removing. The number that has to clear the line is providers whose own engineering shipped the tools. That number is nine.

When enough of the web is registering its own tools, this becomes a graded dimension with a real band re-cut. Until then the count prints on every scoring run, and the curve — adoption, platform attribution, and deprecated-surface decay — accumulates in the open. The specification itself is profiled at standards.apievangelist.com.