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.
Why WebMCP Instead of REST APIs
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:
- Tool schemas are self-describing and versioned
- Authorization tokens bind to specific merchant contexts
- Agents can discover capabilities without hardcoded endpoints
- State management stays with the merchant backend
Edge Deployment Architecture
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:
- Validates the agent’s authorization token against the merchant’s identity provider
- Loads the merchant’s tool manifest from KV storage
- Routes tool invocations to the merchant’s origin server via Service Bindings
- Returns responses in MCP format
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);
}
};Authorization Boundaries
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.
Deployment Trade-offs
| Aspect | Commerce.com Approach | Alternative | Trade-off |
|---|---|---|---|
| Routing | Per-domain Workers | Central API gateway | Higher cold start cost, better isolation |
| State | Merchant KV namespaces | Shared database | More storage overhead, stronger boundaries |
| Payment | Delegate to merchant checkout | MCP-native payment tools | Less control for Commerce.com, more merchant trust |
| Tool discovery | Static manifests in KV | Dynamic schema generation | Faster response, requires manifest updates |
| Authorization | Token validation per request | Session caching | Higher latency, simpler revocation |
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.
Failure Modes
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.
Observability
Commerce.com instruments each Worker with:
- Request latency histograms per tool type
- Authorization failure rates per merchant
- Origin timeout counts
- KV cache hit rates
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.
Technical Verdict
Use this approach when:
- You need to expose agent tools across thousands of independent tenants
- Each tenant must retain full control over their backend logic and payment flows
- You want protocol-level isolation instead of application-layer access control
- Your infrastructure already runs on Cloudflare Workers or a similar edge platform
Avoid this approach when:
- You have fewer than 100 tenants (the operational overhead is not worth it)
- You need sub-100ms latency for every request (cold starts will hurt)
- Your tenants require real-time tool schema updates (KV propagation is too slow)
- You want centralized payment processing (this architecture explicitly delegates it)
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.