Cloudflare turns any site into an MCP agent target

Cloudflare shipped a developer preview that turns on WebMCP for any site with one toggle, no origin code required, per its blog post. Any agent that already speaks MCP can drive the page unmodified. The preview's riskiest tool pack hands that agent the site's own MCP endpoint under the visitor's existing login.

The setup lives under Agent Readiness > Labs in the dashboard. Cloudflare's edge uses HTMLRewriter to inject a bridge script into every HTML response the site serves. That script registers MCP tools on document.modelContext, the browser surface Chrome 146 ships experimentally. Site owners opt into tool packs with a data-packs attribute instead of writing integration code themselves.

Every tool in the preview runs inside the visitor's own browser. None of it round-trips to Cloudflare's servers for the tool call itself. The Site MCP Server pack goes further. It calls the origin's own MCP endpoint using the visitor's existing session, not a fresh credential scoped to the agent.

Cloudflare's post doesn't say what auth or scoping the Site MCP Server pack applies before it lets an agent call the origin. It also doesn't say whether that check is left to the site owner to build.

Routing agent tool calls through a live user session blurs a line the origin used to draw itself. The endpoint can't tell an agent acting on the user's behalf apart from anything else riding that same session. Cloudflare ships the client-side agent surface first. The trust boundary question gets deferred to whoever flips the pack on. The origin's MCP endpoint ends up trusting whatever the browser session already trusts, agent or not.