- Cloudflare says Commerce.com, which runs almost 100,000 domains on Cloudflare, asked to enable WebMCP across its stores. Agents then call store tools instead of guessing at page buttons.
- The design choice that matters is control: Cloudflare says each merchant can opt out from a dashboard switch, and opted-out stores get no injected script.
- WebMCP is still an experimental browser proposal. Leaders should ask which tools their platform exposes, who can switch them off, and how their bot rules treat agents.
A storefront is becoming a menu for machines
A website used to be a page a person reads. Increasingly it is also a menu that software orders from. The question for a retailer is who writes that menu, and who can take items off it.
Cloudflare published a case study this week that makes the question concrete. Commerce.com, a commerce platform that runs almost 100,000 domains on Cloudflare, asked whether it could turn on a new browser feature called WebMCP for all of its stores at once. Cloudflare says it built a per-merchant opt-out to make that possible.
Why shopping agents struggle today
Cloudflare describes most shopping agents as visitors working without labels. They study the page's underlying code, make a best guess at what each control does, and retry after a miss. Cloudflare says this is slow, uses a lot of tokens (the units AI models charge for), and can break after something as small as a theme change.
Cloudflare's walk-through involves a shopper who wants waterproof trail shoes in size 10 for less than $140. Without WebMCP, Cloudflare says, the agent can be stopped by cookie banners, misread variant drop-downs, or run into bot challenges meant to filter out automated traffic.
How the mechanism works
WebMCP is a proposed browser standard from Google. A page uses it to offer an agent named tools, such as search_products. The agent calls the tool with exact inputs, for example a query, a maximum price and a size. It does not hunt for buttons.
Cloudflare launched an edge version in beta in August. When a site owner turns it on, Cloudflare injects a small script at the edge, the network layer that serves the page. The script makes the tools available without the owner writing code. The agent finds them on document.modelContext, a browser object where pages list their tools.
For Commerce.com, Cloudflare uses a toolpack called mcp-server-client. It acts as a bridge and passes tool definitions and requests, unchanged, between Commerce.com's backend MCP server and the visitor's browser. Cloudflare says the tools run inside the shopper's own live session on the store's domain. The cart updates as normal, and Cloudflare says no login details are handed to an outside party.
The shopper still finishes the purchase. Cloudflare says the person clicks checkout themselves.
The real decision is the opt-out
WebMCP was first built as one on-or-off switch for a whole domain zone. Commerce.com hosts merchant domains on shared zones through Cloudflare for SaaS, so one switch would have covered every store. Cloudflare says it instead used two existing features, Configuration Rules and custom hostname metadata.
Commerce.com enables WebMCP on its main zone. A rule then checks each merchant's metadata. If the merchant flips an opt-out switch in the Commerce.com dashboard, Cloudflare skips WebMCP for that store. Cloudflare says an opted-out store gets no added delay, no remote lookup and no injected script.
This shows where control now sits. For years a merchant controlled how a store looked. Now the merchant also decides whether machines get a menu at all, though the platform decides what is on it. A default-on design with an easy exit is a governance choice, and each merchant has to know it exists.
Commerce.com's Kristina Pototska says merchants want their store to appear in an agent's answer while keeping the customer and the checkout. She says WebMCP supports all three without rebuilding the site.
What the post does not show
WebMCP is an experimental proposal in early preview. Cloudflare says access is limited to testers: an experimental Chrome flag, Chrome Origin Trials, some agentic browsers and developer environments. Because it sits behind flags and trials, it is unlikely to be in wide shopper use yet.
The post comes from Cloudflare, the vendor, with a quote from its partner. It gives no figures on sales, error rates or how many merchants opted out. This is one platform's rollout, not evidence of an industry trend.
The post also describes practical fixes. Commerce.com's server sits at /api/mcp, not the /mcp path the bridge expected, so Cloudflare added a zone-level setting for a custom path. Cloudflare also describes a quiet failure mode. If the store's tool server is unreachable, or the browser cannot use WebMCP, the script stops and the regular storefront appears.
Questions to put to your team
First, ask whether your commerce platform offers agent tools, and whether they are on by default. Ask who in your company can switch them off, and how fast.
Second, ask which actions the tools expose. Pototska lists search, product details, building a cart and a checkout link. Confirm that your platform's list matches what you intend.
Third, ask your security team how current bot rules treat shopping agents. Cloudflare names bot challenges as one thing that trips agents today. Blocking them or admitting them should be a deliberate choice, not an accident of configuration.
Once a store publishes a menu for machines, someone in the company has to own that menu.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Cloudflare.
