A shopper asks the AI agent in their browser to find a pair of waterproof trail running shoes under $140, and then has the agent add the right pair to the cart. Previously, when an AI agent shopped at an online store, it could only look at the webpage like a human, guessing where the search box was and which button added items to the cart; as soon as the page layout changed, that approach could break. Now, the store page tells the AI agent in the browser directly: here are two ready-made actions—searching for products and adding to the cart—that you can call directly by name. This approach of having a webpage list callable actions directly for an AI agent inside the browser is called WebMCP.
On October 21, 2026, Cloudflare and Commerce.com partnered to launch a deployment that turned this capability into a platform-level default configuration, placing it directly at merchants’ request entry point. Commerce.com was formerly the e-commerce infrastructure company BigCommerce; after the company changed its name, its merchant control panel and technical documentation continued to use the BigCommerce brand name, and the rest of this article refers to the platform as Commerce.com.
This rollout of WebMCP support is a unified move at the platform layer that requires no storefront to modify its own frontend template code. The platform simply attaches a script at the ingress layer where storefront requests enter, turning the switch on by default right at the request entry point; if a merchant does not want to expose this capability, the store admin panel also provides a toggle they can turn off at any time. According to the official announcement, the rollout covers nearly 100,000 domains—a figure that represents the number of custom store domains connected to the platform’s network, not 100,000 active stores. Without modifying a single line of their own code, these nearly 100,000 store domains now have product search and add-to-cart actions on their webpages, ready for AI agents in visitors’ browsers to call directly by name.
When a platform turns the switch on by default, it looks as though it is making the decision on behalf of every merchant. Yet if the platform does not turn it on for them, would merchants make the change themselves? Almost certainly not. Take an online outdoor gear shop or a regional apparel brand with a few million dollars in annual revenue: the owner and operations team spend every day occupied with merchandising, inventory stocking, return on ad spend, and warehouse fulfillment. To turn their existing storefront into a site that agents can call directly, they would have to spend extra money hiring engineers to rewrite store templates, untangle product query and inventory APIs, and keep shipping updates to track a protocol that is still evolving. The money required for retrofitting and maintenance is certain, whereas how many actual orders browser agents will bring to the store remains an unknown on the monthly financial statement. Faced with certain R&D spending and uncertain order returns, most merchants will choose to wait and see. It is not that they fail to understand the technology; the math simply does not pencil out from the standpoint of an individual store.
Across Cloudflare’s own network, AI agent requests grew by 1,700% in a single year. Even so, the top websites with the strongest engineering capabilities have barely moved. According to Cloudflare’s own framework for site agent capabilities, a website must first identify who the visitor is at the foundational layer, and then successively build four layers of capability above it: being readable, discoverable, callable, and payable. Cloudflare used its own network to conduct an agent readiness scan of high-traffic domains, examining Agent Readiness across 200,000 high-traffic domains: only 3.9% of sites have implemented even the most basic layer—returning streamlined Markdown on demand—while the vast majority still return raw webpages cluttered with heavy styling and scripts. Higher layers require sites to publish standard interface cards or interface directories, known as MCP Server Cards and API Catalogs, yet across those 200,000 high-traffic domains, fewer than 15 in total had configured them. The fact that even top-tier sites with the deepest R&D resources have hardly deployed them on their own shows that site-by-site retrofitting does not work in terms of engineering economics.
Because site-by-site retrofitting does not pay off, shoppers’ agents and merchants are trapped in a deadlock of mutual waiting. Agents wait for merchants to open up interfaces, and merchants wait for agents to bring real traffic; neither side is willing to make the first move. When browser vendors and agent client developers see that barely a dozen out of 200,000 high-traffic domains offer ready-made tool directories, they cannot persuade users to abandon traditional simulated page clicks and rely on a new protocol. Conversely, scattered merchants see that agent traffic has yet to reach scale, so they will not pull engineers off other work to write the first line of integration code. Relying on individual merchants to invest in R&D one by one will never break this cycle of mutual waiting.
The only way to break this deadlock is for a platform that hosts a large number of merchants to make the change all at once, turning it on by default for every merchant. The solution deployed by Commerce.com and Cloudflare takes exactly this path: Commerce.com enables WebMCP by default across its nearly 100,000 store domains, giving store pages ready-made tools that browser agents can call directly without merchants touching a line of store code, while anyone who wants to opt out can simply turn it off in the admin panel. In an opt-in system where the feature is off by default and waits for merchants to adopt it voluntarily, the vast majority of small and midsize merchants will leave it untouched because they do not understand the new technology or cannot spare engineering staff, making it hard for client agents to find enough callable stores. In an opt-out system where the feature is on by default, merchants gain the capability without doing anything, and only the minority with concerns around risk control, branding, or pricing need to go into the admin panel to opt out. This default-on, admin-opt-out mechanism spares the vast majority of merchants the cognitive and engineering burden of learning a new protocol, while keeping the final decision of whether to remain open in each merchant’s hands.
When rolling out a new protocol, leaving integration work to scattered tenants and waiting for merchants to make the change themselves is not a strategy; it is hope. Individual merchants cannot make the economics of one-off retrofits work, and clients cannot afford to wait for tens of thousands of stores to schedule their own rollouts one by one; only a platform that holds a unified entry point can save every merchant the cost of duplicated effort through a single centralized upgrade. Replacing merchant-by-merchant retrofits with a platform-level default-on switch plus admin opt-out—allowing the supply side to cross the initial scale threshold overnight—is the viable path out of a cold start.
To turn this default switch into engineering reality, the partnership between Cloudflare and Commerce.com had to solve two problems at once: first, installing the same set of tools across nearly 100,000 store domains without modifying store code one merchant at a time; second, allowing each merchant to turn it off individually, with the opt-out taking effect for their store as soon as they click the button. The platform obviously could not go in and modify every store’s frontend templates directly, because stores run all kinds of legacy template versions; bulk code changes would easily clash with merchants’ own scripts and would be difficult to roll back if anything went wrong. Conversely, if the platform merely injected a generic script at the outer network gateway without a unified backend interface to call, that script would have no way to share the same shopping cart with the page the shopper is currently browsing.
Cloudflare’s approach is to work along the website’s existing request
path. It already sits between the store’s server and the shopper’s
browser, forwarding every webpage visit. According to Cloudflare’s
official introduction to the WebMCP beta published in
August 2026, when a store’s origin server sends a regular webpage to a
shopper, the page first passes through Cloudflare’s edge nodes. There,
Cloudflare uses HTMLRewriter
to rewrite the page on the fly and insert a small bridge script,
requiring no changes to the store’s own code or deployment. Once inside
the browser, this script does not search for products, check inventory,
or modify the cart on its own. Its only job is to act as a messenger: it
registers with document.modelContext, the browser interface
dedicated to registering tools for AI agents, and tells the agent in the
browser that this store offers two actions—searching for products and
adding to the cart—which can be called directly by name and parameters
whenever needed, without taking screenshots to guess button locations or
parsing complex HTML tags.
When the shopper actually asks the agent in their browser to find a
pair of trail running shoes in the right size and put them in the cart,
the execution pipeline kicks into gear. The browser agent invokes the
tool directly by name; the bridge script in the page catches the
instruction and sends a request within the shopper’s current browser
session to /api/mcp under the store’s own domain, handing
the call over to the unified storefront API service already built into
the platform’s backend—Commerce.com’s Storefront
MCP. Because this request is sent directly from the shopper’s
browser under the store’s own domain, the browser automatically attaches
the shopper’s current login state, member pricing, currency settings,
and cart session. The price the agent retrieves is the exact price the
user sees on screen, and once the agent finishes calling the add-to-cart
interface, the user can click the cart icon in the top-right corner of
the page and find the newly selected running shoes already waiting
inside.
Once tool delivery and API invocation are working, how do you give
each of those nearly 100,000 store domains its own opt-out switch that
takes effect immediately? Although these online stores appear to the
outside world under each merchant’s independent brand domain, under the
hood they are all centrally hosted by the platform through Cloudflare
for SaaS, which manages customer domains in bulk and lets the
platform attach a metadata tag recording configuration state to each
domain. When a merchant chooses to opt out in the Commerce.com control
panel, the platform backend updates that domain’s tag to the opted-out
state. When subsequent shoppers visit that store, Cloudflare reads the
tag at the edge node using Configuration
Rules (for example, checking
cf.hostname.metadata.webmcp_opt_out eq "true"), stops
injecting the script into the page, and sends the origin server’s
original webpage straight to the visitor. The entire process requires no
code redeployment and no extra database lookups, and it has no impact on
traffic to any other store.
Viewed across the entire request path, what makes this solution viable is not that the edge nodes are particularly intelligent, but that the platform backend had already standardized the search and add-to-cart interfaces across all these stores. In this division of labor, Cloudflare’s edge nodes merely inject the script into the browser as the webpage passes through, whereas the actual work of filtering products by criteria, checking real-time inventory, and updating the shopping cart is handled entirely by Commerce.com’s platform backend. As a result, even though the frontend pages of nearly 100,000 stores may look completely different, they all share the same standardized interface foundation. This is also the key to whether other platforms can replicate this approach: if every store on a platform has its own custom backend logic and lacks unified search and add-to-cart interfaces, then no matter how many pages the edge nodes inject the script into, the requests sent by that script will have nothing to call.
At the final step of this chain, the system deliberately preserves a human confirmation boundary: the agent can help the shopper search, compare specifications across products, and even add items to the cart, but the final checkout and payment step must still be completed by the user clicking through in person. The advantage of this design is twofold: on one hand, it prevents an agent from misreading a size or quantity and charging the user’s card outright; on the other hand, it allows merchants’ existing payment compliance, card verification, and fraud-prevention workflows to continue operating as usual without modification. From the bridge script slipped into the browser as the webpage passes through the edge node, to the unified backend API called via the store’s own domain, to the domain-tag-driven opt-out switch and the human checkout boundary—stringing this entire workflow together is what enabled the platform to install the switch across nearly 100,000 store domains without changing a single line of merchant code.
Cloudflare was able to flip the agent switch for nearly 100,000 store domains on Commerce.com because it sits at the entry point every request must pass through to reach a website. Yet not every platform has a CDN, and most software companies neither control edge nodes nor manage DNS resolution for their customers. If you build a content management system, a website builder, a payment gateway, or a vertical SaaS product, does this approach of retrofitting in bulk at the entry layer still hold?
Strip away the outer shell of the network edge, and three underlying conditions emerge: what shared foundation the platform hosts on behalf of its tenants, how uniform the tenants’ actions are on top of it, and whether the platform can change the default on tenants’ behalf without negotiating with them one by one. A reverse proxy is only one form of entry point; code registries, page rendering engines, payment clearing rails, and multi-tenant databases are equally indispensable shared foundations for tenants. Measured by this yardstick, not every platform can turn agent tools into an all-on default with a single switch; the real rule is that the more unified the shared foundation, the broader the scope of what can be defaulted.
These three conditions may sound abstract, but applied to your own platform, they boil down to three questions. Taken together, the three answers determine whether your platform can make this interface layer a default or only offer it as an option. First, in day-to-day operations, which layer of infrastructure is centrally hosted by the platform—where tenants do not maintain the underlying code, yet every core business transaction must pass through it? Second, when tens of thousands of tenants act on top of this foundation, are they each writing wildly different custom logic, or are they repeating highly uniform standard workflows? Third, if the platform installs an agent protocol adapter on this foundation, does it have sufficient permission boundaries and safety guardrails to change the default configuration directly for all tenants, without requiring every tenant to send engineers back to modify code or sign off one by one?
The answers to these three questions differ from platform to platform. Testing them against four familiar platforms reveals four distinct outcomes: WordPress, Wix, Stripe, and Shopify. They are not here as product recommendations. They are four answers to the same set of questions across four platforms. From a loose open-source plugin ecosystem, to a fully managed frontend site runtime, to highly standardized payment flows and a multi-tenant e-commerce foundation, the more tightly the foundation is consolidated, the wider the scope in which the platform can change the default on behalf of its tenants:
| Platform | What It Hosts for Tenants | How Uniform Tenant Actions Are | How Far It Can Default |
|---|---|---|---|
| WordPress | Plugin registry | Plugins are written independently with unstandardized capabilities | Can only provide a registration framework; plugins decide for themselves whether to go public |
| Wix | Page rendering and site runtime | Site structure is standardized by the platform | Can turn on the browser layer by default for all sites |
| Stripe | Payment and transaction flows | Payment actions are uniform across the industry | Can turn on the payment and catalog layers by default for all merchants |
| Shopify | Product, inventory, and order data | Product and checkout models are unified | Can turn on storefront tools by default for all merchants |
Looking first at the two rows in the upper half of the table, which
sit closest to content and pages, action uniformity directly drives the
gap in how much can be defaulted. WordPress
6.9 introduced the Abilities API so plugins can register abilities,
which the official
MCP Adapter then converts into MCP tools that by default require a
server-side meta.mcp.public flag before being exposed
externally; precisely because plugins are written independently and
their capabilities are not uniform, WordPress can only provide a
registration framework and cannot default a single set of tools across
all plugins. By contrast, Wix directly controls page rendering and the
site runtime, with site structure standardized by the platform; as a
result, beyond offering the developer-facing Wix
MCP and Wix Site MCP for visitor agents connecting to individual
sites, it can turn on the in-browser Wix WebMCP frontend layer by
default across all sites.
Continuing down the table toward transactions and data, the convergence of foundation and actions carries a platform’s control over defaults right into the core transaction layer. Stripe hosts payment and transaction flows for merchants, offering the Agentic Commerce Suite, ACP, and Shared Payment Tokens while hosting ACP endpoints, catalog syndication, tax and shipping calculations, and Radar fraud protection; because payment actions are highly uniform across the entire industry, it can turn on the payment and catalog layers by default for all merchants. At an even higher level of uniformity, Shopify holds products, inventory, and checkout on its own multi-tenant foundation with completely unified product and checkout models, enabling it to use UCP and Storefront MCP to turn on the entire suite of storefront tools by default for all merchants.
For platforms, this perspective can immediately be used to set priorities: before writing any code, instead of envying someone else’s edge network or payment license, first ask yourself: which layer of shared foundation do we host for our tenants? And how uniform are our tenants’ actions on top of it? Collaboration and HR software, for instance, hosts permission tables and approval workflow engines, while local services platforms host store scheduling and booking interfaces. Where tenant actions are uniform, capabilities can be turned on by default, and when external protocols evolve in the future, the platform only needs to update the translation layer once; where actions are not uniform, the platform can only build a registration framework or leave the work to vertical vendors.
For AI Builders creating products around these platforms, this table also signals which layer of your ecosystem the platform itself is going to absorb. WordPress’s plugin layer is fragmented, and the business capabilities of individual sites are hard to consolidate into a single standard mold, leaving room for vertical tools. Conversely, Shopify’s product and checkout layers are highly unified; generic tools built around checking inventory, finding products, and running standard checkouts will quickly be made default by the platform, so the real opportunity lies in the segment the platform cannot reach.
Turning on tool invocation by default across nearly 100,000 store domains looks like an overnight bulk transformation, but this platform switch is only genuinely useful when three conditions hold at the same time. These three conditions govern the page, the browser, and the action respectively; if any one of them is missing, the platform cannot default the capability, and the remaining work falls back to the merchants themselves or to vertical software vendors.
The first condition is that the store page must go through the platform’s standard rendering path. BigCommerce’s official FAQ explicitly states that this default WebMCP integration only applies to stores built with Stencil templates. Small and midsize merchants that use this standard template system get it enabled automatically. Larger brands with higher transaction volumes on the platform, however, often rebuild their frontends using a decoupled Headless architecture, treating Commerce.com solely as a product and order backend while developing their own frontend pages with frameworks like Next.js and hosting them on external servers. As soon as a merchant bypasses the Stencil template rendering pipeline and same-origin routing, Cloudflare can no longer step into the page to inject the script, leaving those major brands outside the reach of the default switch.
The second condition is that the shopper’s agent must run in a browser that supports WebMCP and have an active browser page session. According to the WebMCP entry on Chrome Status, this feature is still in the experimental stage in Chrome, Microsoft Edge’s origin trial is scheduled through the end of March 2027, and neither Firefox nor WebKit-based Safari supports it yet—meaning the default browser on Apple devices cannot use it for now. Even when the browser does support it, this design of injecting tools into the page context requires the user to have the browser open and viewing the webpage at that moment. If a shopper is using a smart speaker, a mobile operating system’s voice assistant, or a cloud-based agent placing orders in the background without an active browser page session, this mechanism cannot be used either.
The third condition is that the action must look the same across stores. For actions like searching for products or adding items to a cart, a store selling running shoes and a store selling insulated tumblers use the exact same interface, so the platform can handle them uniformly with a single set of tools. When it comes to verifying dental insurance deductibles, routing tiered property-maintenance dispatch tickets, or calculating B2B procurement contract prices based on annual agreements and volume tiers, however, the logic varies wildly from merchant to merchant. The business rules and data for these industry-specific actions are tucked away inside each merchant’s own internal systems or offline contracts; because they never pass through the platform’s shared entry point in the first place, the platform naturally cannot standardize them.
Even when all three conditions hold, we still do not know whether anyone is actually using it today. The announcements from Cloudflare and Commerce.com only mention the rollout’s coverage, without disclosing actual tool call volume, merchant opt-out rates in the admin panel, or checkout conversion rates. Having 100,000 store domains enabled by default only shows that the platform has unilaterally rolled out the interface; it does not mean 100,000 agent transactions have taken place on the platform. How many users are actually calling these interfaces from experimental browsers, and how many merchants have already flipped the switch off, are questions that no public operational data can currently answer.
Once you see clearly where this switch works and where it does not, the boundary in the division of labor for enterprises becomes clear as well. For generic actions where all three conditions hold, the platform can handle the job by default; as soon as even one condition fails to hold, the remaining territory is where enterprises must work out for themselves whether to rent, buy, or build—which is the question we will examine in the next article.