Summary: Commerce.com has enabled Cloudflare’s beta edge implementation of WebMCP across its almost 100,000 domains, so AI agents can call structured tools like search_products instead of scraping HTML. The tricky part was scale: WebMCP was designed as a per-zone switch, so the two companies built edge-level opt-outs so each merchant keeps control. For platform builders, this is a working template for rolling out an experimental browser standard across thousands of tenant domains.
Why guess at buttons when you can call a tool?
Most shopping agents today work from a site’s HTML: look at the page, guess which button does what, click, retry. As the Cloudflare announcement puts it, a simple theme change can break that loop, and it burns tokens. WebMCP, a proposed browser standard from Google currently in early preview behind Chrome flags, gives agents structured tools on the page instead.
Cloudflare’s edge implementation, launched in beta in August, injects a small script so those tools appear without site owners writing code. Agents discover tools on document.modelContext and make clean calls like search_products({ query: “trail running shoe”, max_price: 140, size: 10 }) and add_to_cart. Because tools execute inside the shopper’s active browser session on the store’s domain, the cart updates in real time, and checkout stays a human click — payment details never go to a third party.
This pairs with the same pattern we covered in WebMCP Meets Headless Agent: How Firecrawl Bridges the Browser Gap — agents getting real page context rather than reverse-engineering markup.
The scaling problem: one zone, thousands of merchants
Commerce.com runs its storefronts on Cloudflare for SaaS, hosting thousands of merchant vanity domains on shared zones. WebMCP’s original design assumed a single on-or-off switch per zone. Turning it on for the main zone would have forced it on every merchant at once.
The fix leans on existing Cloudflare primitives rather than a custom allowlist: Configuration Rules plus custom hostname metadata. Commerce.com enables WebMCP zone-wide, then an edge rule checks each hostname’s metadata. If a merchant flips an opt-out switch in their dashboard, WebMCP is bypassed for that storefront:
{
"action": "set_config",
"expression": "cf.hostname.metadata.webmcp_opt_out eq \"true\"",
"action_parameters": {
"webmcp_enabled": false
}
}Because rules evaluate at the edge before serving the page, an opted-out store gets no injected scripts, no remote lookups, and no added latency.
Two integration details worth stealing
Working with a real partner surfaced gaps a preview release always has:
- Custom MCP paths. The bridge originally expected every site’s MCP server at /mcp; Commerce.com’s lives at /api/mcp. Cloudflare added a configurable zone-level MCP URL, passed into the injected script via data-mcp-url.
- Safe fallbacks. If the store’s MCP server is offline or the browser doesn’t support WebMCP, the script simply exits and the storefront loads normally for human shoppers.
Server-side and browser-side MCP, not either/or
Kristina Pototska, Product Management Director at Commerce.com, described the merchant motivation plainly: when a shopper asks an agent to find something, merchants want their store in the answer, with the customer relationship and checkout control intact. Commerce.com runs WebMCP alongside its server-side MCP — the server-side path serves agents connecting to stores directly, while WebMCP serves agents working inside the shopper’s browser, with the same shopping tools in both.
That dual approach mirrors where platform thinking is heading generally; we looked at the governance side of agent traffic in Detecting Shadow MCP Traffic: How Cloudflare Brings Agent Tool Calls Under Governance.
The takeaway
If you operate a multi-tenant platform, the useful pattern here isn’t WebMCP itself — it’s plumbing an experimental standard through edge config and tenant metadata so rollout is reversible per customer and costs nothing for those who decline. The catch: WebMCP is still an experimental preview behind Chrome flags and origin trials, so treat this as groundwork, not a launch-day dependency.