Creativity · MCP — pattern

Pattern: Multi-Tenant MCP Server Deployment

When you go beyond a single-developer stdio server to a shared MCP deployment, multi-tenancy becomes a first-class concern. This pattern covers per-tenant credentials, request-scoped isolation, audit logging, and rate-limiting — the building blocks for running MCP safely for many customers behind one HTTP endpoint.

MCP facts

Kind
pattern
Ecosystem
anthropic-mcp
Transports
http

Capabilities

  • Request-scoped tenant identity extracted from bearer/JWT
  • Per-tenant credential stores — secrets never cross tenants
  • Per-tenant tool allowlists and rate limits
  • Centralized audit logs: caller, tenant, tool, arguments, outcome

Frequently asked questions

Why HTTP instead of stdio for multi-tenant?

stdio assumes one process per client. HTTP / Streamable HTTP lets many clients share a single, scalable server with bearer-token isolation.

Where do tenant credentials live?

In a secret manager (Vault, AWS Secrets Manager, GCP Secret Manager) keyed by tenant ID. The MCP server fetches them on demand and discards after the request.

How do I prevent prompt-injection cross-tenant leaks?

Never include Tenant A's resources in Tenant B's response. Use strict scoping, tenant-labeled audit logs, and deny-by-default tool exposure.

Sources

  1. MCP Architecture Overview — accessed 2026-04-20
  2. MCP Transports — accessed 2026-04-20

Related