Source: blog.cloudflare.com/webmcp-commerce
Commerce.com, which runs almost 100,000 domains on Cloudflare, asked to enable WebMCP for all of its stores once the preview was available. Cloudflare's edge implementation, launched in beta in August, injects a script that makes the tools available without site owners writing code. WebMCP is still an experimental proposed standard in early preview and is available behind Chrome flags, in Origin Trials, in some agentic browsers and in developer environments.
WebMCP was originally a single on-or-off switch for a whole domain zone, which did not fit thousands of merchant vanity domains on shared zones. The companies used Configuration Rules and custom hostname metadata so that an opt-out flag on a merchant's storefront bypasses WebMCP for that site. Commerce.com's MCP server is at /api/mcp rather than /mcp, so a zone-level setting passes a custom path into the injected script. If a store's MCP server is offline or a browser does not support WebMCP, the script exits and the page loads normally.
The tools run inside the shopper's active browser session on the storefront's domain, so the agent sees the same prices and cart, and no credentials go to a third party. Cloudflare passes tool definitions and actions between the browser and Commerce.com's backend MCP server without changing them. The shopper still clicks checkout personally, which keeps payment details in the shopper's hands.
Why it matters if you build agents
Agents running in a shopper's browser can call search_products and add_to_cart on participating storefronts instead of clicking through cookie banners and variant menus. Developers building shopping agents should check whether a site exposes WebMCP tools through document.modelContext and keep HTML interaction as a fallback. On Commerce.com stores, server-side MCP and WebMCP offer the same shopping tools, so one integration can cover both paths.
Get stories like this every weekday
One short email with the day's agent tooling news.