How Commerce.com and Cloudflare are getting storefronts ready for AI agents

What it claims

Cloudflare's edge WebMCP feature, launched in beta in August, now runs across Commerce.com's almost 100,000 domains. Shopping agents call structured tools such as search_products and add_to_cart on document.modelContext instead of parsing HTML and simulating clicks. The tools run inside the shopper's own browser session on the merchant's domain, so the agent sees the same prices and cart. No credentials go to a third party. Checkout stays manual: the backend returns a checkout link and the human clicks it.

How it works

Cloudflare injects a bridge script with the mcp-server-client toolpack. The bridge proxies tool definitions and calls unchanged from Commerce.com's backend MCP server, so the merchant keeps control of tool logic. Commerce.com says the same tool set also serves agents that connect directly to its server-side MCP, so merchants do not manage two tool sets.

WebMCP was originally a single on/off switch per zone. Commerce.com hosts merchant vanity domains on shared zones via Cloudflare for SaaS, so per-store control comes from a Configuration Rule that reads custom hostname metadata:

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

The rule is evaluated at the edge before the page is served. An opted-out store gets no injected script, no remote lookup and no added latency.

flowchart TD
  A[Storefront request] --> B{hostname metadata opt-out?}
  B -- yes --> C[Page served, no script]
  B -- no --> D[Inject bridge.js]
  D --> E{Browser supports WebMCP and MCP server up?}
  E -- no --> F[Script exits, page loads normally]
  E -- yes --> G[Tools on document.modelContext]
  G --> H[Proxied to backend MCP server]

How to use it

The bridge originally assumed every MCP server lived at /mcp. Commerce.com's lives at /api/mcp, so a zone-level configurable MCP URL setting was added. The injected tag then looks like this:

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

To test as an agent client, enable chrome://flags/#enable-webmcp-testing. WebMCP is also available through Chrome Origin Trials, some agentic browsers, and Cloudflare Kitesurf.

Limits

WebMCP is an experimental, proposed Google standard in early preview. The Cloudflare feature is in beta. Agents in browsers without WebMCP support get nothing, because the script silently exits. Tool discovery is still weak: Cloudflare names helping agents find a site's tools as its next work item. The post gives no figures for adoption, agent success rates, latency or token savings.