Cloudflare Turns on WebMCP for Nearly 100,000 Commerce.com Storefronts

Buying shoes online is still hard for AI agents. Not because models cannot reason about products, but because storefronts were built for humans: agents that shop today mostly read the HTML, guess which button does what, click, and retry when a theme change breaks their assumptions. Cloudflare’s announcement today describes a deployment that tries to change that at scale: Cloudflare says it has turned WebMCP on platform-wide for Commerce.com, giving nearly 100,000 merchant storefronts — any that have not opted out — structured shopping tools for agents, all at once.

What actually shipped

The mechanics matter more than the headline number. WebMCP is a proposed browser standard from Google — still experimental, available behind Chrome flags (chrome://flags/#enable-webmcp-testing) and in Chrome origin trials — that lets a page declare typed tools an agent can call directly, such as search_products or add_to_cart, instead of simulating clicks on a DOM it has to interpret. Cloudflare shipped an edge implementation in beta in August: enable it, and Cloudflare injects a small script at the edge that makes those tools available, with no code changes by the site owner.

What is new this week is the scale and the control model. Commerce.com — the company behind BigCommerce, Feedonomics and Makeswift — already runs its roughly 100,000 merchant domains on Cloudflare, using Cloudflare for SaaS to host thousands of merchant vanity domains on shared zones. Rather than toggle WebMCP per zone, Commerce.com enabled it once platform-wide and Cloudflare built a per-merchant opt-out: a Configuration Rule evaluated at the edge checks custom hostname metadata, and if a merchant flips an opt-out switch in their dashboard, WebMCP is bypassed for that store with no injected script and no added latency.

Commerce.com’s opt-out rule, from Cloudflare’s post:

{
  "action": "set_config",
  "expression": "cf.hostname.metadata.webmcp_opt_out eq \"true\"",
  "action_parameters": { "webmcp_enabled": false }
}

The engineering details reveal how a lab feature becomes a platform default. Cloudflare’s edge WebMCP feature was originally a single on/off switch per domain zone, which did not fit a SaaS host with thousands of tenants on shared zones. And the bridge originally expected every site’s MCP server at /mcp; Commerce.com’s lives at /api/mcp, so Cloudflare added a configurable MCP URL setting. If a store’s MCP server is offline or the visitor’s browser lacks WebMCP support, the injected script exits and the storefront loads normally — human shoppers never notice.

Why agents and merchants both care

Two design choices do the real work. First, the tools execute inside the shopper’s active browser session on the storefront’s own domain, so the agent sees the same prices and cart as the human, and no credentials pass to a third party. When the purchase is ready, the shopper still clicks checkout themselves. Second, Cloudflare acts only as the edge delivery layer proxying tool definitions and actions unchanged from Commerce.com’s backend MCP server — the merchant keeps ownership of the tool logic, and Commerce.com notes the same shopping tools also work through its server-side MCP for agents that connect directly rather than in-browser.

For operators building agentic commerce, the consequence is concrete: on an enabled storefront, an agent that would previously fight cookie banners, misread variant dropdowns and trip bot challenges can instead make two typed calls — search_products({query: "trail running shoe", max_price: 140, size: 10}) and add_to_cart({product_id: "shoe_123"}) — fewer tokens, fewer failure modes.

Read the caveats before you replan your roadmap

Distinguish the layers. The deployment is live on Cloudflare’s edge, but the browser standard underneath it is still a proposal in early preview: Chrome’s own documentation describes WebMCP as under active discussion and subject to change, notes it is primarily designed for local browser workflows with a human in the loop, and warns that complex sites may need refactoring to handle interface state. Reach is also bounded — only browsers that implement WebMCP (flagged Chrome, origin-trial sites, some agentic browsers) will ever see the tools, and clients must visit a site directly to discover them. Until WebMCP support spreads beyond those browsers, agents running in ordinary browser sessions will still fall back to reading the page the old way.

According to Cloudflare, this is a platform-wide rollout covering almost 100,000 domains — and the pattern it used, platform-level enablement, per-tenant edge opt-out, silent fallback, is a template any SaaS host can copy. If you run storefronts or publish product data, the practical next step is the one we have recommended before: register a few real tools first rather than redesigning your site, and understand how MCP-style tool surfaces differ from scraping. For teams weighing accessibility-versus-tooling bets on the agentic web, the WebMCP-versus-ARIA debate is the policy fight worth watching as adoption grows.

Cloudflare and Commerce.com say they will keep investing as the standard evolves, starting with making tools easier for agents to find.