What is MCP Gateway?
MCP Gateway is an optional, MCP-aware proxy or aggregation layer that routes Client requests to Servers and applies shared traffic policy without replacing Host consent or Server authorization.
Quick Facts
| Specification | Official Specification |
|---|
How It Works
An MCP Gateway is a deployment pattern around the Model Context Protocol, not a fourth protocol participant. The official architecture defines Host, Client, and Server. A Gateway sits on a network path when shared routing, policy, fleet inventory, credential mediation, or observability justifies another hop. A direct Client-to-Server connection remains valid, and adding a Gateway does not make an integration trusted or production-ready by itself.
Two designs have different responsibilities. A transparent Gateway preserves the configured Server endpoint and forwards one protocol relationship while applying transport controls. An aggregating Gateway presents one MCP endpoint to Clients, combines capabilities from several upstream Servers, and therefore behaves as a Server downstream and as one or more Clients upstream. Aggregation is not transparent: it needs a stable Server identity, explicit version policy, collision-free namespaces, deterministic discovery, bounded fan-out, error mapping, and a documented authorization model.
MCP 2026-07-28 removes the protocol-level Initialize Handshake, Session ID, GET Stream, and Stream Resumption from the modern path. Every Request carries its Protocol Version and relevant Client Capabilities in _meta; server/discover is available for version and capability discovery. A Stateless Gateway can route each Streamable HTTP POST to any compatible instance. Sticky routing and a shared Protocol Session Store belong only to isolated Legacy 2025 paths or to explicit application state identified by a business handle, not to the modern protocol by default.
Streamable HTTP exposes routing metadata without making Headers the source of truth. MCP-Protocol-Version and Mcp-Method are required for Requests, while Mcp-Name is required for tools/call, resources/read, and prompts/get. The Gateway can route, meter, and apply coarse policy from these fields, but the JSON-RPC Body remains authoritative. A terminating Gateway must reject Header / Body mismatches and unsafe encodings before routing. Mcp-Param-* exists only for statically reachable primitive Tool properties explicitly marked with x-mcp-header; it must not be treated as a general argument mirror or a place for secrets.
Capability aggregation creates a semantic control plane. The Gateway discovers each configured Server, validates and hashes Tool, Resource, and Prompt descriptors, assigns a namespace tied to immutable Server identity, and exposes only the permitted subset. It must not merge colliding names silently or trust self-reported serverInfo, descriptions, icons, and annotations as identity or safety evidence. List and Resource results may carry ttlMs and cacheScope; private results require cache keys bound to the Principal, Tenant, upstream Server, protocol version, policy revision, and authorization context. A change notification invalidates a cache but does not authorize a new capability.
Authentication and authorization span separate hops. If the Gateway terminates an inbound protected endpoint, it acts as an OAuth Resource Server to the downstream Client. When it calls a protected upstream MCP Server, it acts as an OAuth Client for that Server. Keep inbound and upstream tokens separate, validate issuer and Audience, use RFC 8707 Resource Indicators, request least-privilege Scope, and never pass an inbound token through merely because both hops use OAuth. Gateway policy can deny a request, but every upstream Server still validates the effective Principal, Tenant, object, arguments, purpose, and side effect.
High-throughput design begins with measured work, not a connection-count claim. Bound admission by Principal, Tenant, Server, capability, and cost class; use short queues with deadlines, per-upstream concurrency limits, and bulkheads so one slow Server cannot consume the whole fleet. Propagate cancellation and distinguish queue time, Gateway service time, upstream time, and response-stream duration. The modern Response may be JSON or Request-scoped SSE, while long-lived change notifications use subscriptions/listen; proxies must avoid buffering SSE and must re-subscribe after disconnect because Last-Event-ID resumption is not supported.
Retries follow operation semantics rather than HTTP method alone because MCP operations use POST. Discovery and read operations can be retried within a deadline when their consistency contract permits it. A tools/call with side effects must not be retried unless the Server enforces an idempotency key or transactional deduplication and the previous effect status is known. Timeout, transport loss, cancellation, or an open Circuit Breaker does not prove that a downstream write failed. Never fabricate a successful Tool result from a stale cache; return a bounded error or an explicitly labeled read-only fallback.
MRTR preserves interaction without restoring a transport Session. An eligible operation can return resultType: "input_required"; the Host obtains supported Elicitation or deprecated input and retries with a new Request ID, inputResponses, and opaque requestState. A Gateway forwards that State without interpreting it, preserves Principal and upstream binding, and does not treat it as authorization. Modern Gateways also keep subscriptions/listen streams separate from ordinary Requests and propagate cancellation to the selected upstream.
The Gateway is a high-value attack surface. Tool Poisoning and Rug Pulls can enter through aggregated descriptors; Resource or Tool output can carry Prompt Injection; authorization discovery can trigger SSRF; weak token handling creates Confused Deputy and Mix-up failures. Pin upstream provenance, restrict egress, verify descriptor changes, isolate credentials, limit body and stream sizes, and keep policy fail-closed when its decision inputs are unavailable. Control-plane changes need authenticated authorship, review, rollout, rollback, and immutable audit records.
Production telemetry should connect Gateway build and policy revision, downstream Principal and Tenant, inbound and upstream Request IDs, protocol version, route and upstream Server identity, capability and descriptor hash, authorization decision, redacted argument digest, queue time, attempts, cache result, circuit state, response type, bytes, latency, cancellation, idempotency decision, and final effect status. Do not record access tokens, raw secrets, unrestricted conversation text, or complete sensitive Tool and Resource payloads. A Gateway is useful only when this shared control outweighs its latency, blast radius, operational cost, and new single-point-of-failure risk.
Key Characteristics
- Optional deployment layer: adds shared routing and governance without becoming an official MCP participant or replacing direct connections
- Dual-role aggregator: when terminating MCP, presents a Server contract downstream and separate Client contracts to upstream Servers
- Stateless modern data plane: routes self-describing Requests by validated version, method, name, identity, and policy rather than Protocol Session affinity
- Capability control plane: namespaces, filters, hashes, caches, and re-reviews aggregated Tool, Resource, and Prompt descriptors
- Credential boundary: separates inbound Resource Server authorization from per-upstream OAuth Client credentials and forbids Token Passthrough
- Reliability boundary: applies bounded queues, bulkheads, backpressure, safe retry rules, cancellation, circuit breaking, and redacted telemetry
Common Use Cases
- Expose an approved, namespaced subset of many internal MCP Servers through one endpoint while preserving each Server's authorization
- Route high-volume 2026-07-28 Requests across stateless Gateway and Server replicas using validated MCP Headers
- Isolate Tenant quotas and per-Server concurrency so a slow or expensive capability cannot exhaust unrelated traffic
- Mediate separate inbound and upstream OAuth relationships without forwarding bearer tokens across Resource boundaries
- Audit capability revisions and consequential Tool effects across several Hosts while keeping sensitive arguments and outputs redacted
Example
Loading code...Frequently Asked Questions
Is an MCP Gateway part of the official MCP protocol?
No. The official architecture defines Host, Client, and Server. Gateway is an optional deployment pattern for shared routing, aggregation, policy, or observability. A transparent Gateway forwards one Server relationship; an aggregating Gateway must implement explicit downstream Server and upstream Client contracts.
How is an MCP Gateway different from an API Gateway?
Both can terminate TLS, authenticate callers, route HTTP, rate-limit, and emit telemetry. An MCP-aware Gateway additionally validates MCP versions and Headers, understands JSON-RPC methods, capability discovery, Tool or Resource names, result envelopes, MRTR, and subscription streams. An existing API Gateway may be sufficient if these protocol-aware controls are unnecessary.
Does MCP 2026-07-28 require sticky sessions or a shared Session store?
No. The modern Core has no protocol Session, Initialize Handshake, GET Stream, or stream resumption. Each Request is self-describing and can reach any compatible instance. Affinity or shared state is needed only for an isolated Legacy path or explicit application state, and that state should use a scoped handle rather than connection identity.
Can an MCP Gateway authorize Tool calls for every backend?
It can enforce a coarse or contextual deny policy, but it cannot replace Server authorization. Each Server still validates the effective Principal, Tenant, object, arguments, purpose, and side effect. Inbound tokens must not be passed through to another Resource; upstream credentials require their own Audience and least-privilege Scope.
How should an MCP Gateway scale safely under high request volume?
Use stateless replicas for the modern path, route on validated `Mcp-Method` and `Mcp-Name`, bound queues and per-upstream concurrency, isolate failures with bulkheads and circuit breakers, and propagate deadlines and cancellation. Retry reads only within their consistency contract, and retry writes only when backend idempotency or deduplication makes duplicate effects safe.