Back to blog

Web MCP at the Edge: What Cloudflare's 100K-Store Rollout Means

•7 min read•AgentReady Team•Industry news
A storefront page gets a WebMCP script from a CDN edge node linked to an MCP server, and a browser agent lists search and cart tools.

On October 21, Cloudflare and Commerce.com switched on web MCP for almost 100,000 storefront domains in one go. Merchants didn't write a line of code. Cloudflare's edge now injects a small script into each page, and that script hands AI browser agents a set of shopping tools, like product search and add to cart, through the browser's WebMCP interface (Cloudflare).

That's the largest single WebMCP deployment we've seen, and it changes the question site owners should ask. The question is no longer whether to hand-code WebMCP tools. It's what your site should expose to agents, and where that logic should live.

TL;DR

  • Cloudflare injects a WebMCP bridge script at the edge, and Commerce.com used it to give nearly 100,000 stores agent-callable shopping tools without touching their code.
  • The bridge only exposes tools your own MCP server already advertises, so the real work is still designing a good MCP server and clear tool descriptions.
  • WebMCP is still experimental (Chrome flags and an origin trial), so treat edge injection as a cheap early bet that sits on top of solid HTML and structured data, not a replacement for them.

What Cloudflare and Commerce.com actually shipped

Cloudflare first released its edge version of WebMCP as a developer preview in August. You go to Agent Readiness > WebMCP in the dashboard, toggle it on for a domain and pick "packs" of tools. Cloudflare then uses HTMLRewriter to add one script tag to every HTML response, served from your own origin under /.webmcp/ (Cloudflare, August).

There are two packs so far. The Content Credentials pack (c2pa) gives agents tools to read C2PA metadata on images. The Site MCP Server pack (mcp-server-client) is the interesting one: it reads the tools your MCP server lists and registers each of them in the page, proxying calls back to your /mcp endpoint.

Commerce.com, which runs on Cloudflare, asked to turn this on across every store at once. Its tools include search_products (query, max price, size) and add_to_cart (product ID). The tools run inside the shopper's live browser session, so the agent sees the same prices and cart as the human. Checkout stays with the shopper, who clicks the final button themselves (Cloudflare).

Merchants who don't want it can flip an opt-out switch in their Commerce.com dashboard. According to Cloudflare, opted-out stores get no injected script at all (WebProNews).

Why edge-injected web MCP matters for websites

The hard part of WebMCP has never been the API. It's getting a product team to prioritise frontend work for agents that most users don't run yet. Edge injection removes that blocker. If your MCP server exists, a dashboard toggle makes those same tools available to any browser agent visiting your pages.

It also fixes a duplication problem. Commerce.com already ran a server-side MCP for agents that connect directly. Both paths expose "the same set of shopping tools," its product director told WebProNews. One server, two doors: remote agents connect to /mcp, and in-browser agents get the same tools via the page.

There's a shift in who controls the agent experience, too. With a hand-built WebMCP integration, your frontend developers own the tool list. With edge injection, your MCP server owns it, and your CDN decides whether it ships. So the people who configure your CDN now make product decisions about agents. Make sure they know that.

Technical breakdown and trade-offs

What the injected tag looks like

This is the tag Cloudflare adds to Commerce.com storefronts:

<script type="module" src="/.webmcp/bridge.js"
  data-packs="c2pa,mcp-server-client"
  data-mcp-url="/api/mcp"></script>

data-mcp-url defaults to /mcp. Commerce.com's server lives at /api/mcp, so Cloudflare added a zone-level setting for a custom path. If the browser has no WebMCP support, or your MCP server is down, the script exits and the page loads normally.

Per-hostname control

Commerce.com runs thousands of vanity domains on shared zones, so a zone-wide on/off switch didn't work. Cloudflare tied WebMCP to Configuration Rules and custom hostname metadata. The opt-out rule matches cf.hostname.metadata.webmcp_opt_out eq "true" and sets webmcp_enabled to false.

The trade-offs

ApproachEffortWho owns the toolsBest for
Hand-coded WebMCP in your frontendHighFrontend teamComplex flows tied to page state
Edge-injected bridge (Cloudflare)Low, if an MCP server existsMCP server and CDN configSites that already run an MCP server
No WebMCP, good HTML onlyLowestNobodyContent sites where agents mostly read

The catch is simple: no MCP server, nothing to bridge. And tool quality is only as good as your tools/list output. Vague names and thin descriptions get passed straight through to the agent. We covered the declarative and imperative options for hand-built tools in WebMCP declarative vs imperative API.

What it means for site owners

If you run a store, Commerce.com's rollout raises the bar quietly. An AI shopping agent comparing three stores can call search_products on one of them and has to scrape the other two. Nobody has published conversion data on this yet, so don't expect miracles, but the direction is obvious.

If you're not on Commerce.com, the same pattern still works: one MCP server, exposed remotely and bridged into the page.

Keep expectations honest about reach. Chrome's docs still call WebMCP "a proposed web standard" that is "subject to change," with an origin trial from Chrome 149 and a testing flag at chrome://flags/#enable-webmcp-testing (Chrome for Developers). Today, most agents visiting your site still read the DOM. Clean headings, labelled forms and JSON-LD remain the floor.

Security matters too: the bridge calls your MCP endpoint with the visitor's existing session, so every tool you list runs with their cookies. Read WebMCP security risks and mitigation before you list anything that changes account data.

How to act on it: a checklist

  1. Decide what agents should do on your site. Pick 2 to 5 tasks with clear inputs, like search, check stock, add to cart or book a demo. Leave payment and account changes for the human.

  2. Build or tidy your MCP server. Give each tool a verb-noun name (search_products, not tool1), a one-sentence description and typed parameters. Return compact JSON.

  3. Make it discoverable. Serve it at /mcp if you can, or note the custom path. Our guide to remote MCP server discovery covers server cards.

  4. Turn on the bridge on a staging hostname first. Then confirm the tag is there:

    curl -s https://staging.example.com | grep webmcp
    
  5. Test with a real agent. Enable the Chrome testing flag and check that each tool appears and returns what you expect.

  6. Keep the HTML fallback strong. Agents without WebMCP still need labelled forms, landmarks and Product JSON-LD.

  7. Measure the baseline. Run a free AgentReady scan before and after. The Browser Readiness pillar checks WebMCP tools and tool discoverability, and the MCP Presence pillar checks whether agents can find your server without scraping.

Check your own site

This story touches two parts of the Agent Readiness Score. Browser Readiness (40%) looks for WebMCP form tools, structured data and tool discoverability, while MCP Presence (20%) checks for a discoverable MCP server. A low score in both usually means agents can only scrape your pages. Start with how to implement WebMCP if you're new to it. A single-page scan is free and takes about a minute. Scan your site free.

Key takeaways

  • Cloudflare's edge bridge turned on web MCP for nearly 100,000 Commerce.com stores with no merchant code changes.
  • The bridge only republishes tools from your own MCP server, so server design and tool descriptions decide the quality.
  • Per-hostname rules and opt-outs mean CDN settings now shape what agents can do on your site.
  • WebMCP is still experimental in Chrome, so semantic HTML and JSON-LD stay essential for every other agent.
  • Keep checkout and account changes with the human, and audit what each tool can do with a logged-in session.

FAQ

What is web MCP?

Web MCP, usually written WebMCP, is a proposed browser standard that lets a website expose structured tools to AI agents running in the browser. An agent calls a named function like search_products instead of clicking through the page. Chrome supports it behind a testing flag and an origin trial, and the API is still subject to change.

How does Cloudflare's WebMCP feature work?

You enable it under Agent Readiness > WebMCP in the Cloudflare dashboard and choose packs. Cloudflare then adds a script tag to each HTML response, served from /.webmcp/ on your own domain. The Site MCP Server pack reads the tools your MCP server lists and registers them in the page, sending calls back to your /mcp endpoint.

Do I need an MCP server to use edge-injected WebMCP?

For anything beyond the image metadata tools, yes. The Site MCP Server pack has nothing to expose unless your server answers tools/list with real tools. If you don't run one, you can still hand-code WebMCP tools in your frontend, or focus first on labelled forms and structured data that every agent can read.

Is WebMCP safe to turn on for an online store?

It can be, if you scope the tools carefully. Calls run in the shopper's session, so any tool you list acts with their cookies. Commerce.com keeps checkout with the human, which is a sensible line. Avoid tools that change passwords, addresses or payment details, and validate every input on the server as you would for a normal form.

If you already run an MCP server, try the bridge on a staging hostname this week and test one tool end to end in Chrome. If you don't, start by finding out where your site stands today. Run a free AgentReady scan.

Sources

Is Your Website Ready for WebMCP?

Test your site to see your AI Readiness Score and understand exactly what you need to fix.

Check Your AI Readiness Score