Multi-Tenant Deployment

Multi-tenant MCP deployment asks a fundamental question: do tenants share server instances or get dedicated ones? Shared servers are cost-efficient — one process handles requests from multiple tenants, routing by the OAuth token's tenant claim. Dedicated servers provide stronger isolation — each tenant gets its own process, container, or VM, eliminating noisy-neighbor problems and simplifying compliance. The answer depends on your threat model, compliance requirements, and cost constraints. Most production deployments use a hybrid: shared infrastructure for standard tenants, dedicated instances for enterprise customers who require isolation.

Tenant isolation in a shared deployment requires discipline at every layer. At the request layer, extract the tenant ID from the OAuth token and thread it through every function call. At the data layer, enforce tenant-scoped queries — never return data without a WHERE tenant_id = ? clause. At the resource layer, use tenant-specific connection pools or namespaced keys to prevent cross-tenant data leakage. At the logging layer, include tenant_id in every log line so you can filter audit trails per tenant.

Configuration management across tenants adds operational complexity. Each tenant may have different tool sets enabled, different rate limits, different OAuth scopes, and different resource quotas. Store tenant configuration in a centralized config service (not in environment variables or local files) and cache it with a short TTL. When a tenant's configuration changes — new tools enabled, rate limits adjusted — the change should propagate to all instances within seconds, not require a redeployment.