WebMCP at Scale: How Commerce.com Deployed Agent Shopping Tools to 100,000 Storefronts

Commerce.com just flipped the switch on nearly 100,000 WebMCP endpoints simultaneously. Each storefront now exposes a uniform agent interface for browsing, cart management, and checkout, while preserving per-merchant authorization boundaries and existing payment flows. This is the largest known deployment of Model Context Protocol servers in a transactional, multi-tenant environment.

The deployment runs entirely on Cloudflare Workers, which means MCP servers execute at the edge with no central bottleneck. The architecture solves three hard problems: routing agent requests to the correct merchant backend, enforcing isolation between storefronts, and delegating payment orchestration back to each merchant's existing checkout flow instead of centralizing it.

Commerce.com could have exposed traditional REST endpoints for each store. WebMCP gives them something different: a standardized tool discovery protocol that AI agents already understand. When an agent connects to any Commerce.com storefront, it receives a manifest of available tools (browse_products, add_to_cart, initiate_checkout) without custom integration work.

The protocol also carries authorization context in every request. An agent session scoped to merchant A cannot accidentally execute a cart operation against merchant B's inventory. This boundary enforcement happens at the protocol level, not in application logic.

Key differences from REST:

Each Commerce.com domain gets its own WebMCP server instance running as a Cloudflare Worker. When an agent makes a request to shop.example.com/.well-known/mcp, the Worker:

The Workers runtime provides isolation between tenants. A compromised Worker for merchant A cannot access merchant B's KV namespace or Service Binding. Cloudflare's edge network handles routing, so there is no shared API gateway that could become a bottleneck.

// Simplified WebMCP Worker structure
export default {
  async fetch(request, env, ctx) {
    const merchantId = extractMerchantId(request.url);
    const authToken = request.headers.get('Authorization');

    // Validate token against merchant's IdP
    const session = await env.AUTH.verify(authToken, merchantId);
    if (!session.valid) return new Response('Unauthorized', { status: 401 });

    // Load merchant-specific tool manifest
    const manifest = await env.TOOLS_KV.get(`manifest:${merchantId}`);

    // Parse MCP request
    const mcpRequest = await request.json();

    // Route to merchant origin via Service Binding
    const response = await env.MERCHANT_ORIGIN.fetch(
      buildOriginRequest(mcpRequest, session)
    );

    return formatMcpResponse(response);
  }
};

The hardest part of multi-tenant MCP deployment is preventing cross-merchant leakage. Commerce.com uses three layers:

Token binding: Each authorization token includes a merchant ID claim. The Worker validates this claim before routing any tool invocation.

KV namespacing: Tool manifests and session state live in per-merchant KV namespaces. A Worker cannot read another merchant's namespace even if the code is compromised.

Service Binding isolation: Each merchant's origin server is bound to their Worker instance. There is no shared connection pool or routing table that could leak requests across tenants.

When an agent tries to execute a purchase action, the MCP server does not handle payment orchestration itself. Instead, it delegates back to the merchant's existing checkout flow by returning a tool response that includes a checkout URL and session token. The agent can then drive the merchant's native payment process without the MCP layer touching sensitive card data.

The per-domain Worker model means Commerce.com pays for 100,000 separate Worker invocations instead of routing through a single gateway. This costs more but eliminates shared failure modes. If one merchant's Worker crashes or gets rate-limited, it does not affect other storefronts.

Worker cold starts: The first MCP request to a storefront after a period of inactivity will be slower. Commerce.com mitigates this by keeping Workers warm for high-traffic merchants, but long-tail stores will see occasional 200-300ms delays.

KV consistency: Tool manifests live in eventually consistent KV storage. If a merchant updates their product catalog, there is a propagation window (typically under 60 seconds) where different edge locations might serve stale tool schemas.

Origin timeouts: If a merchant's origin server is slow or down, the MCP server will time out after 30 seconds. The agent receives a generic error response with no visibility into whether the problem is network, application, or database related.

Token revocation lag: When a merchant revokes an agent's authorization, the token remains valid until its expiration time (typically 1 hour). There is no real-time revocation mechanism because that would require a central token registry.

Commerce.com instruments each Worker with:

These metrics flow into Cloudflare Analytics, which aggregates them across all 100,000 domains. Merchants can see their own traffic patterns but cannot access other merchants' data.

The system does not log full MCP request payloads because they might contain customer PII. Instead, it logs tool names, response codes, and timing data. If a merchant needs to debug a specific agent session, they must correlate the MCP request ID with their own origin server logs.

Use this approach when:

Avoid this approach when:

The Commerce.com deployment proves that WebMCP can scale to six figures of concurrent storefronts without a central orchestration layer. The cost is operational complexity: managing 100,000 Worker instances, debugging cross-tenant issues, and accepting eventual consistency in tool manifests. For a platform that already runs on Cloudflare's edge, those trade-offs make sense. For a greenfield project, you would need strong justification to choose this over a simpler gateway model.