Cloudflare has added a new toggle to its dashboard that injects a WebMCP bridge into any site’s pages, letting AI agents discover and invoke site-provided tools without touching the origin server’s code. The move removes the most labor-intensive step in making a web property “agent-ready,” but developers still define useful tools and monitor their use.

Why the edge toggle matters

WebMCP is an API used to register tools. Until now, getting a site onto that protocol required manually inserting a bridge script on every page. Cloudflare’s new “Browser Run → Agent Readiness” switch automates that injection at the edge, adding the script as HTML leaves Cloudflare’s network and reaches the visitor’s browser.

The benefit is clear: a static site hosted anywhere can now expose its content to AI agents with a single click. No changes to the origin server, no front-end rebuild.

What the feature actually does

When the toggle is enabled two things happen:

  • Edge injection – Cloudflare appends a small JavaScript payload to outgoing HTML. It works for both traditional static pages and modern SPAs that rely on client-side routing.
  • Browser bridge – The script runs in the user’s browser and registers the site with the WebMCP API, announcing the tools it can provide.

Cloudflare ships the preview with two pre-packaged tool packs:

  1. Content Credentials – exposes C2PA (Coalition for Content Provenance and Authenticity) metadata attached to media files, allowing agents to verify provenance.
  2. Site MCP Server – acts as a proxy that forwards tool calls to an MCP server you already run behind the scenes.

These packs solve the distribution problem: you no longer need to sprinkle bridge code across every page to make the site reachable by agents.

What still falls on the developer

Turning the switch on does not magically turn a shopping cart or a flight-search form into an AI-callable tool. The bridge merely announces that a site can provide tools; the site must still define them. Two conditions are required for a tool to be usable:

  • An MCP server must be running somewhere that the proxy can reach.
  • The developer must register each tool via the document.modelContext API, specifying the tool’s name, input schema, and expected output format.

If a search tool is exposed, the developer must ensure the returned data is clean, structured, and useful to downstream agents. Otherwise the tool will be invoked but provide little value.

Observability is another missing piece. The current release does not surface logs that show which agents called which tools or where calls failed. Teams must roll their own instrumentation—capturing request IDs, response times, and error codes—to verify that the bridge and the underlying MCP server behave as intended.

Who stands to gain, and who must act

  • Site owners who already run an MCP server can flip the Cloudflare switch and instantly get edge-level distribution of their existing tool set. The edge injection handles the plumbing, letting them focus on tool design.
  • Businesses that want AI agents to perform actions (searching product catalogs, booking appointments, etc.) still need to write the tool definitions and test them thoroughly. The toggle does not replace that work.
  • Teams must consider the trust implications of exposing internal APIs to any agent that discovers the site.

Takeaway

Cloudflare’s edge-hosted WebMCP toggle eliminates the manual step of inserting a bridge script into every page, opening the door for any site to become discoverable by AI agents. The real work—designing meaningful tools, securing them, and building observability—remains on the developer’s side. Use the toggle to solve the distribution puzzle; then turn your attention to the capability and trust challenges that determine whether agents can actually do anything useful on your site.