Commerce.com uses Cloudflare to open its stores to AI shopping agents with WebMCP

What Commerce.com and Cloudflare announced

Commerce.com, the company behind the BigCommerce e-commerce platform, is using Cloudflare to give AI shopping agents a structured way into its merchants' online stores. In a Cloudflare blog post published on 21 October 2026, the two companies describe switching on WebMCP, an experimental browser standard that lets a web page offer agents named tools such as search_products, across Commerce.com storefronts. Commerce.com already runs almost 100,000 domains on Cloudflare, and it asked whether WebMCP could be enabled for all of its stores at once rather than one site at a time.

To make that work, Cloudflare built a platform-wide switch with a per-merchant opt-out, a configurable path for Commerce.com's own MCP server, and fallbacks that leave the store untouched when something is missing. The post was timed to Cloudflare Connect in San Francisco on 21 October, where Commerce.com product management director Kristina Pototska was scheduled to join a panel on getting storefronts ready for agent shopping during the holiday peak.

The two companies do not say how many stores have the tools live today, or how many merchants have opted out, so the 100,000 figure describes Commerce.com's footprint on Cloudflare rather than confirmed active deployments. Commerce, according to its website, also owns the Feedonomics product-feed service and the Makeswift visual editor.

What WebMCP is

Most shopping agents today work from a site's HTML. They look at the page, guess which button does what, click, and try again when they are wrong. Cloudflare's post calls this slow and token-hungry, and notes that something as small as a theme change can break it. WebMCP is a proposal for a different approach: a page registers tools, each a JavaScript function with a natural-language description and a structured input schema, and an agent running in the browser calls them directly. The page exposes them through document.modelContext.

The proposal positions WebMCP as a client-side complement to server-side integrations built on the Model Context Protocol. A backend MCP server talks to an AI platform directly and bypasses the website, so state and login sessions have to be duplicated on the server. WebMCP tools run inside the page the user already has open, with their session and their cart, and the visible interface stays in sync with what the agent does.

Support is still early. According to the project's implementation status page, Chrome 149 and Edge 150 have origin trials, Chrome also has a testing flag for local development, ChatGPT Desktop supports it, and Brave has added experimental support to its Leo assistant. Mozilla and WebKit have open standards-position requests but no implementations. Cloudflare describes WebMCP as a browser standard from Google that is still an experimental proposal in early preview.

How Cloudflare's edge bridge works

Cloudflare launched a developer preview of WebMCP on its network in August. When a site owner switches it on in the dashboard, Cloudflare uses its HTMLRewriter to add one script tag to every HTML response, pointing to a bridge script served from the same origin. The bridge checks whether the browser exposes WebMCP; if not, it does nothing. If it does, it registers tools from groups Cloudflare calls packs.

The August preview shipped two packs. A Content Credentials pack reads C2PA provenance metadata from images on the page, reporting rather than cryptographically verifying it. A Site MCP Server pack asks the site's own MCP server which tools it offers and registers a browser-side proxy for each one, so calling the tool sends a request back to the site on the visitor's origin with the visitor's existing session. The tools use the Model Context Protocol's own tool and result types, which means an agent that already speaks MCP needs nothing special to drive the page.

The Commerce.com deployment relies on that second pack, which Cloudflare calls mcp-server-client. In this set-up Cloudflare acts as the delivery layer at the edge, passing Commerce.com's tool definitions and actions through unchanged, and Commerce.com's backend MCP server decides what the tools do. It is a browser-side counterpart to Cloudflare's earlier work on MCP servers and skills for its own API.

Turning it on for every store, with an opt-out

The practical problem was scale. WebMCP on Cloudflare was designed as a single switch for an entire domain zone, but Commerce.com uses Cloudflare for SaaS to host thousands of merchant vanity domains on shared zones. Turning it on for the zone would turn it on for every store, with no way for an individual merchant to decline.

Instead of building a custom allowlist, Cloudflare hooked WebMCP into two existing features: Configuration Rules and custom hostname metadata. Commerce.com enables WebMCP for its main zone and adds an edge rule that checks each merchant's metadata. If a merchant flips an opt-out switch in the Commerce.com dashboard, the rule sets webmcp_enabled to false for that storefront. Because the rule is evaluated at the edge before the page is served, Cloudflare says an opted-out store sees no extra latency, no remote lookups and no injected script.

Two more changes came out of the partnership. Cloudflare's bridge originally expected every site's MCP server at /mcp, while Commerce.com's lives at /api/mcp, so Cloudflare added a zone-level setting for a custom MCP URL that is passed into the injected script tag. And if a store's MCP server is offline or a shopper's browser does not support WebMCP, the script simply exits and the store loads normally for human visitors.

What a shopper's agent can do

Cloudflare gives an example request: find a waterproof trail running shoe under $140 in size 10 and add it to the cart. Without WebMCP, an agent has to simulate clicks and can be tripped up by cookie banners, size drop-downs or bot challenges meant to tell automated traffic from real customers. With WebMCP, the agent finds the store's tools on the page and makes two calls, one to search_products with the query, maximum price and size, and one to add_to_cart with the chosen product.

According to Pototska, the tools let an agent search products, check details, build a cart and get a checkout link. Because they run inside the shopper's own browser session on the store's domain, the agent sees the same prices and cart as the shopper, and Cloudflare says no credentials go to a third party. The purchase itself is not delegated: the shopper clicks checkout and enters payment details, which keeps the final decision with the human.

Pototska said WebMCP works alongside Commerce.com's existing server-side MCP. The server-side version serves agents that connect to a store directly, such as an assistant shopping across several sites, while WebMCP serves agents working inside the shopper's browser, and both expose the same set of shopping tools so merchants do not have to manage them separately.

Why it matters for agentic shopping

Commerce platforms are racing to be legible to AI agents before the holiday season. Shopify recently opened its catalogue and Shop Pay checkout to any AI agent through Shop MCP, a server-side approach. Browser agents are spreading at the same time, from OpenAI's ChatGPT extension that can read and act in Chrome tabs to agentic browsers from several vendors. A storefront that exposes clean tools gives those agents a reliable path to its products instead of leaving them to scrape and guess.

For merchants, Pototska framed the appeal as keeping control: the store stays in the agent's answer, the shopper stays on the merchant's site, and the merchant keeps the checkout and the customer relationship, without rebuilding the site. For Cloudflare, the deployment is a large real-world test of a feature it introduced only two months ago, and the opt-out and custom-path fixes show the kind of adjustments a preview needs before it can run across a multi-tenant platform.

Limits and open questions

WebMCP is not a finished standard. Only Chromium-based browsers have origin trials, Firefox and Safari have not committed, and the API could change before it ships broadly, which is why Cloudflare says it will keep investing as the standard evolves, starting with making a site's tools easier for agents to find. Until more agents and browsers support it, most shoppers will see no difference at all.

Security and trust questions remain open too. Tools that act inside a logged-in session can add items to a cart on the shopper's behalf, so the protections against prompt injection or a malicious page steering an agent matter. The post does not discuss abuse controls beyond keeping checkout manual, nor how merchants will measure agent traffic or conversions. Making a store's tools on by default with an opt-out is convenient, but merchants who want to decide for themselves will need to know the switch exists. The deployment numbers that would show real uptake have not been published yet.