InfoQ put Cloudflare's WebMCP preview into its August 10 feed. Cloudflare's canonical announcement is dated August 6 and marked updated August 10. The primary source describes one dashboard switch under Agent Readiness > WebMCP. Once enabled, Cloudflare uses HTMLRewriter at its edge to inject a same-origin /.webmcp/bridge.js reference into each HTML response. The bridge finds the proposed document.modelContext browser interface, assembles the enabled packs, and registers named tools with input schemas. If a browser lacks the interface, Cloudflare says the bridge returns without changing page behavior. No application code at the origin has to move.
The preview starts with 2 packs. Cloudflare says Content Credentials reads the first few kilobytes of C2PA provenance metadata from images, but does not cryptographically verify the signatures and reports signatureVerified: false. The Site MCP Server pack discovers an existing server's tools through tools/list. Its proxy sends tools/call to the same-origin /mcp endpoint with credentials set to same-origin, so it uses the visitor's existing session. Cloudflare says every current tool executes in the visitor's browser without a round trip to a Cloudflare server. That avoids handing the agent a backend API key. It also makes the authenticated browser a live authority boundary: a cleaner interface does not make a consequential action safe by itself.
For agent builders, the contract is the substantive change. Cloudflare and InfoQ describe the current loop plainly: visual browser automation spends tokens interpreting layouts, can misread a control, and often breaks when a site changes its interface. A named tool with a JSON input schema narrows the action and its expected output. Just as important, a structured call can distinguish a missing tool, an execution error, and a valid empty result. A client that silently falls back to scraping recreates the ambiguity and can report a failed call as nothing new. WebMCP reduces one class of brittleness only when clients keep those states separate.
For publishers, the same machinery is a control surface. Cloudflare lets the site owner select packs and enable more later without redeploying the origin. Chrome's documentation says WebMCP requires an origin-isolated document and that the tools Permissions Policy defaults to self, blocking cross-origin iframe access unless it is explicitly allowed. Those are real boundaries. But the site's menu is curated: a publisher can expose one useful action, omit another, and shape how an agent perceives the service. Machine-readable does not mean complete or neutral. It means a negotiated surface controlled by the origin.
Do not read this as a browser standard shipping everywhere. The sources contradict one another on milestones. Cloudflare calls WebMCP experimental in Chrome 146. InfoQ says Chrome 145+. Chrome's documentation, updated August 7, says its origin trial starts with Chrome 149 and local testing requires a flag. Those numbers cannot all describe the same availability. What they jointly support is that WebMCP remains proposed, Chrome-only, and subject to change. The machine-readable web is arriving here as an opt-in contract among site, browser, and agent, not a universal replacement for HTML.