The Production Landscape of
MCP Gateways

Transport

As of spec 2025-11-25, MCP officially defines two transports. The previous HTTP+SSE transport was deprecated in 2025-03-26 and fully replaced by Streamable HTTP. WebSocket transport (SEP-1288) remains a community proposal in review — not part of the official spec.

Why the old SSE transport was deprecated

The original HTTP+SSE transport was stateful by design. It required two separate endpoints and held session state bound to a specific server instance via a live TCP socket. This made it fundamentally incompatible with multi-pod Kubernetes deployments and standard load balancers. Streamable HTTP replaces this with a single endpoint and a stateless-first model where sessions are serializable data rather than socket-bound state.

Scaling Patterns

Given a production MCP server, how do you scale horizontally without the gateway becoming the bottleneck?

The emerging industry standard: prefer stateless transport, externalize genuinely shared concerns to Redis, and accept sticky sessions only when a specific feature requirement makes them unavoidable.

Access Control

Once more than one agent or team can reach your gateway, you need authentication and authorization. The 2025-03-26 spec codified OAuth 2.1 as the standard authentication framework for MCP — a significant upgrade over ad-hoc JWT approaches that dominated early deployments.

Authentication options

Authorization models

Tool-based scoping

The scope granularity decision has significant downstream consequences for enforcement, auditability, and operational overhead. Tool-based scoping — assigning a unique, deterministic scope identifier to every individual tool — pushes authorization to the finest possible granularity.

The scope allocation problem

Whatever granularity you choose, scope strings must come from somewhere. Manually curated scopes have well-known failure modes: collisions across teams, stale strings after refactors, inconsistent naming, and cognitive overhead on every new tool added.

Multi-Tenancy

If your gateway serves a single team, skip this section. If multiple teams or product lines share it, three archetypal patterns — documented extensively in SaaS architecture literature — apply directly to MCP gateways.

For MCP gateways among internal teams, pool tenancy is the overwhelmingly common choice. Treat tenants as namespaces — logical partitions within a shared gateway — and rely on scopes to enforce isolation. The operational overhead per tenant is approximately nothing.

Reliability Patterns

Rate limiting

Three canonical algorithms dominate: token bucket (most widely deployed — tolerates bursts), leaky bucket (smooths outbound traffic to a constant rate), and sliding window (avoids boundary effects of fixed windows). All three operate at gateway granularity — per agent, per tenant, per tool, or composites. Redis is the default shared backend; in-memory counters only work for single-pod deployments.

Circuit breakers

Circuit breakers protect against repeated failures from a downstream dependency. After a threshold of consecutive errors, the breaker trips and subsequent calls fail fast without being attempted, during a cooldown period. The pattern originates in Michael Nygard's Release It! and applies naturally at per-tool granularity in MCP gateways.

Caching

Tool responses are often cacheable — status lookups, reference data reads, catalog queries. Caching at the gateway layer has significant latency and cost benefits, but several design questions need explicit answers up front.

Observability

MCP gateways benefit from the same three-pillar observability model as any service: logs, metrics, and traces.

Logging

Separate log streams by concern. A common pattern splits logs into three channels: application logs for debugging, audit logs for compliance and usage analytics, and access logs for traffic analysis. Structured JSON logging makes every stream machine-queryable by default.

Metrics

Gateway-level: requests per second, error rate, latency percentiles, active connections. Per-tool: invocation count, error rate, latency, circuit breaker state. The RED method (Rate, Errors, Duration) and USE method (Utilization, Saturation, Errors) give solid starting points for what to measure.

Distributed tracing

Agent workflows often span multiple tool calls, each of which may invoke multiple upstream APIs. OpenTelemetry has become the de facto standard for propagating trace context across the call graph. If you aren't propagating trace context today, you're flying blind during production incidents.

The Operational Stack

A production MCP gateway deployment typically combines: a container platform (Kubernetes), a load balancer with TLS termination, a shared state backend (Redis), an OAuth 2.1 identity provider, a log aggregator, a metrics backend, a tracing backend, and optionally a policy engine. None of these are MCP-specific — they are the standard cloud-native stack.

Every box except Redis is stateless. Every pod is interchangeable. Tool annotations inform middleware decisions without custom logic per tool. The Tasks primitive means long-running operations can return a task ID immediately and be polled asynchronously.

Open Problems

Takeaways

Closing

If there is a single takeaway from surveying the MCP deployment landscape in 2026, it is this: the protocol is stable, the operational patterns are borrowed almost entirely from general-purpose microservice practice, and the only genuinely novel decision most teams face is transport choice.

Get that right — bias toward statelessness, accept stickiness only when a specific feature requirement demands it — and the rest of the stack falls into place using patterns every backend engineer already knows.

The interesting problems have moved to the edges: federation, dynamic loading, delegation, and standardized observability. Those are the topics the next wave of MCP engineering writing will tackle. We are looking forward to reading them.

References & further reading

Official specs & foundational material

MCP in production — community writing

Distributed systems & scaling

Authentication & authorization

Multi-tenancy

Reliability & operations