Why storefronts need a machine-readable interface

Most shopping agents today operate by parsing a page's HTML: they inspect the DOM, infer which element behaves like a button, click it, and retry when the guess fails. The approach is expensive in tokens, slow, and fragile — a theme update can break it entirely.

WebMCP, a proposed browser standard from Google, replaces that guesswork with structured tools exposed on the page, such as search_products. An agent calls the tool it needs directly instead of hunting for controls. The standard is still experimental and in early preview, reachable through the Chrome flag chrome://flags/#enable-webmcp-testing, Chrome Origin Trials, some agentic browsers, and developer environments including Cloudflare Kitesurf.

Cloudflare shipped an edge implementation of WebMCP in beta in August: enabling it injects a small script at the edge that surfaces the tools automatically, with no code changes from site owners. Commerce.com, a commerce platform running nearly 100,000 domains on Cloudflare, asked whether the capability could be switched on for every store at once.

What Commerce.com gains

Kristina Pototska, Product Management Director at Commerce.com, frames the motivation around merchant control:

“Merchants keep asking us how they can keep up with agentic shopping. When a shopper asks an agent to find something, merchants want their store to be in the answer. They want to keep the customer, keep control of the checkout, and do it without rebuilding their site. WebMCP helps with all three. The agent gets real tools to search products, check details, build a cart, and get a checkout link, so it doesn’t have to guess its way around the page. The human shopper stays on the merchant’s site, and the merchant keeps the relationship.

We wanted to turn this on in a secure way, and without asking merchants to edit their theme or do anything by hand. That’s where the Cloudflare partnership worked perfectly.

WebMCP also works side by side with our server-side MCP, and together they cover the different ways people shop with agents. Server-side MCP supports agents that connect to a store directly, like an assistant helping someone shop across several sites. WebMCP supports agents that work in the shopper’s browser. It’s the same set of shopping tools in both cases, so merchants don’t have to choose between the two or manage them separately.”

Two design principles carry the integration. The tools run inside the shopper's active browser session on the storefront's own domain, so the agent sees the same prices and cart, no credentials leave for a third party, and the visit remains on the merchant's site. Cloudflare, in turn, acts as the edge delivery layer in front of Commerce.com's backend MCP server, proxying tool definitions and actions unchanged so merchants retain control of tool logic.

Anatomy of an agent request

A request such as "Find me a waterproof trail running shoe under $140 in size 10 and add it to my cart" shows the difference. Without WebMCP, the agent simulates clicks and runs into cookie banners, misread variant drop-downs, or bot challenges aimed at separating automated traffic from real customers.

With WebMCP, the agent discovers the store's tools on document.modelContext and issues two calls:

  1. search_products({ query: "trail running shoe", max_price: 140, size: 10 })
  2. add_to_cart({ product_id: "shoe_123" })

Because execution happens inside the shopper's session on the store's domain, the cart reflects changes immediately. Commerce.com's backend MCP server drives the commerce flow, and the shopper completes the purchase by clicking checkout — payment details stay protected and the final buy decision belongs to the human.

Edge controls for shared zones

The obstacle was granularity: WebMCP was originally designed as a single on-or-off switch for an entire zone. Commerce.com needed to enable the mcp-server-client toolpack — an edge bridge that proxies tool definitions and requests from its backend MCP server to the visitor's browser — for thousands of merchant vanity domains sharing zones through Cloudflare for SaaS, while letting each store owner opt out easily.

Rules over allowlists

Rather than build a custom allowlist, Cloudflare tied WebMCP to existing Configuration Rules and custom hostname metadata. Commerce.com enables WebMCP on its main zone and adds an edge rule that reads merchant metadata; when a merchant flips the opt-out switch in their dashboard, Cloudflare bypasses WebMCP for that storefront:

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

Evaluation happens at the edge before the page is served, so an opted-out store incurs no extra latency, no remote lookups, and no injected scripts.

Custom paths and fallbacks

Real-world partner testing surfaced gaps. The bridge initially expected every site's MCP server at /mcp, but Commerce.com's lives at /api/mcp. The fix was a configurable MCP URL at the zone level, passed into the injected script tag:

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

If a store's MCP server is offline or the browser lacks WebMCP support, the script exits and the storefront loads normally, leaving human shoppers unaffected.

Where this goes next

Cloudflare says it will keep investing in WebMCP as the standard evolves, beginning with making a site's tools easier for agents to discover. The two companies plan to continue the collaboration. A panel on storefront readiness for peak season — "Getting your storefront agent ready for peak season" — is scheduled for Cloudflare Connect in San Francisco on October 21, 2026, with Pototska alongside Justis Blasco (CTO and Co-Founder, Popmenu), Ross Harvey (Head of Infrastructure, Fruugo), and Josh Mills (VP of Engineering, Gopuff).