Turning On WebMCP Across Nearly 100,000 Storefronts Without Editing a Theme

Agents can write code and pass the bar exam, but buying a pair of shoes online still trips them up. The problem isn't reasoning. It's that storefronts were built for people who can see a page and click what they want, and agents have to reconstruct that experience from raw markup.

Most shopping agents today read a site's HTML, work out which element is the add-to-cart button, click it, and retry when they guess wrong. That's slow and token-hungry. It's also fragile: a theme update that moves a button can break a flow that worked yesterday.

What WebMCP changes

WebMCP is a browser standard from Google that lets a page advertise structured tools to an AI agent. A store might expose a tool called search_products, and the agent calls it directly with the parameters it needs instead of hunting for a search box. Tools are discovered through document.modelContext, so the agent knows what the page can do before it touches anything.

The standard is still an experimental proposal in early preview. You can reach it today through an experimental Chrome flag (chrome://flags/#enable-webmcp-testing), through Chrome Origin Trials, in some agentic browsers, and in developer environments such as Cloudflare Kitesurf. That's a narrow audience, which is why the interesting question isn't whether WebMCP works in a demo. It's how a merchant with thousands of domains turns it on without asking each one to change code.

Cloudflare's answer was an edge implementation, released in beta in August. Switch it on and Cloudflare injects a small script at the edge that makes the tools available. Site owners don't write anything.

Why Commerce.com pushed for it

Commerce.com runs a flexible commerce platform and already uses Cloudflare to serve nearly 100,000 domains. When the preview opened up, the team asked a direct question: could WebMCP go on for every store at once?

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

"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."

She also points out that Commerce.com's server-side MCP covers a different case. Server-side MCP serves agents that connect to a store directly, such as an assistant comparing products across several sites. WebMCP serves agents that operate inside the shopper's own browser. Both expose the same shopping tools, so merchants don't have to maintain two sets of logic.

That split matters for how the integration is built. The WebMCP tools run inside the shopper's active session on the storefront's domain. The agent sees the same prices and the same cart the shopper sees, no credentials go to a third party, and the visit stays on the merchant's site. On the server side, Cloudflare acts as the edge delivery layer for Commerce.com's backend MCP server, proxying tool definitions and actions without modifying them. The merchant keeps control of the tool logic.

What the agent actually does

Take a concrete request: "Find me a waterproof trail running shoe under $140 in size 10 and add it to my cart."

Without WebMCP, the agent simulates clicks. Cookie banners get in the way, variant drop-downs get misread, and bot challenges meant to separate automated traffic from customers can stop the flow entirely. Each failure costs another round of page parsing.

With WebMCP, the agent finds the store's tools and makes two calls:

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

Because the agent runs in your browser session, the cart updates in real time. When you're ready to pay, you click checkout yourself. Your payment details never pass through the agent, and the final purchase stays in your hands. My read is that this checkout boundary is what will make merchants comfortable with the model. Agents handle discovery and assembly; the human still authorizes the money.

The hard part: one switch for many domains

WebMCP was originally built as a single on-or-off switch for an entire domain zone. That works for one site. It doesn't work when thousands of merchant storefronts sit on shared zones through Cloudflare for SaaS, each on its own vanity domain, and some merchants don't want agent traffic at all.

Commerce.com wanted to enable its mcp-server-client toolpack, which acts as an edge bridge. It forwards tool definitions and requests from the backend MCP server to the visitor's browser. The team needed a platform-wide default with a per-merchant way out.

Opt-outs at the edge

Rather than build a custom allowlist, the solution reuses two existing Cloudflare features: Configuration Rules and custom hostname metadata. WebMCP is enabled on the main zone, and a rule checks each merchant's metadata. When a merchant flips the opt-out switch in the Commerce.com dashboard, the rule disables WebMCP for that storefront:

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

Because the rule is evaluated at the edge before the page is served, an opted-out store gets no extra latency, no remote lookup, and no injected script. That's a cleaner design than having the browser check a list on every load.

Adjustments from running it live

A preview release always surfaces details nobody planned for. The first was the MCP path. The bridge assumed every site's MCP server lived at /mcp, but Commerce.com's server sits at /api/mcp. The fix was a configurable MCP URL setting 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>

The second concerned failure modes. If a store's MCP server is down, or a shopper's browser doesn't support WebMCP, the script exits quietly. The storefront loads as it always did, and human shoppers notice nothing.

What to watch next

The open problem the teams highlight is discovery: helping agents find a site's tools more easily. Right now a tool set is only useful if the agent knows to look for it, and the standard is still settling. Cloudflare and Commerce.com say they'll keep iterating as WebMCP matures. For developers, the practical takeaway is that the opt-out pattern, a platform-wide default with per-tenant metadata checked at the edge, is reusable well beyond commerce.