What Is an MCP Gateway? Architecture, Security, and When to Use One

MCP gateway: the short answer

An MCP gateway is a protocol-aware intermediary between Model Context Protocol clients and one or more MCP servers. It can present one MCP endpoint to a host while routing calls to approved downstream servers, combining capability catalogs, filtering tools by identity or policy, brokering upstream credentials, enforcing quotas, recording audit events, translating between protocol revisions, or managing the lifecycle of the servers themselves.

A gateway is not a fourth core MCP role. The current MCP architecture defines hosts, clients, and servers. From the upstream client’s perspective, a gateway may behave like an MCP server. Toward downstream systems, the same implementation may behave like an MCP client, reverse proxy, API adapter, identity broker, registry consumer, workload manager, or several of those at once. “Gateway” is therefore an ecosystem and deployment term, not a wire-level role defined by the core specification. [S121] [S501]

Organizations usually consider a gateway when they have multiple servers, several host products, shared or delegated identities, private-network resources, centralized credentials, enterprise audit requirements, or a need to approve and revoke capabilities from one place. A single developer using one trusted local server often does not need one.

The 2026-07-28 MCP revision changed gateway engineering substantially. Modern Streamable HTTP requests are self-describing, do not depend on an initialization session, and carry routing metadata such as MCP-Protocol-Version, Mcp-Method, and, for named operations, Mcp-Name. Ordinary current-version requests can be distributed across stateless replicas without protocol-session affinity. This reduces the need for sticky routing and deep request-body inspection; it does not remove application state, authorization, tenant isolation, credential management, or durable workflows. [S131] [S058] [S053] [S497]

The central conclusion of this research is:

An MCP gateway can become a valuable policy and operations boundary, but it also becomes a high-value concentration of identities, credentials, capability schemas, logs, routing decisions, and administrative power. It should be adopted because a deployment needs specific gateway functions—not because “enterprise MCP” supposedly requires a gateway by definition.

Use this guide to decide whether shared mediation is justified. Use the client, server, and host guide for normative roles, the local-versus-remote guide for deployment location, and the transport guide for stdio and Streamable HTTP mechanics.

---

Gateway is an architecture pattern, not a fourth role

MCP host

The host is the application-level coordinator. It manages models, context, user interaction, permission interfaces, and one or more MCP clients. A gateway does not replace the host’s responsibility for deciding which capabilities become visible to the model, presenting meaningful user confirmation, and controlling cross-server information flow. [S121]

MCP client

A client is the protocol component that communicates with one logical server. In a gateway deployment, the host’s client may treat the gateway as that server. The gateway can then create downstream clients or proxy requests to several servers. This is why a gateway can be server-facing upstream and client-facing downstream without changing the core role definitions. [S121]

MCP server

A server exposes tools, resources, prompts, and negotiated extensions. It may execute operations itself or delegate to an API, database, CLI, local process, or SaaS service. A gateway may front a server, aggregate several servers, generate a server interface from an API, or deploy server workloads. Those are distinct functions.

MCP gateway

For this paper, an MCP gateway is:

A protocol-aware intermediary that receives MCP traffic from one or more clients and forwards, aggregates, converts, filters, secures, observes, or operationally manages access to one or more downstream MCP servers or capabilities.

This functional definition is intentionally broader than “reverse proxy” and narrower than “anything related to MCP infrastructure.”

Reverse proxy

A reverse proxy forwards network traffic to an upstream service. It may terminate TLS, authenticate users, balance traffic, or add headers. It becomes MCP-aware when it understands protocol revisions, methods, primitive names, streaming behavior, authorization metadata, or capability catalogs. A generic HTTP proxy can transport MCP without becoming a rich MCP gateway.

Aggregator or virtual MCP server

An aggregator presents one logical server to a client while combining tools, resources, or prompts from multiple downstream servers. It must address namespaces, collisions, filtered discovery, pagination, caching, partial failure, and call routing.

Portal

A portal is a curated catalog and connection surface. It can present approved servers and capabilities to users, but it may or may not mediate live traffic. A portal is therefore not automatically a gateway, although one product can combine both. Cloudflare’s documentation, for example, separates MCP server portals from Gateway routing for logging and DLP. [S512] [S513]

Registry

A registry publishes metadata used to find and distribute servers. It can feed a gateway’s catalog or approval process. It does not, by itself, authorize a live tool call, hold a user’s upstream token, or proxy traffic. [S067] [S066]

API gateway

An API gateway governs general API traffic such as REST, GraphQL, or gRPC. It can become MCP-aware or generate MCP tools, but endpoint-level API policy is not identical to capability-level MCP policy.

LLM gateway

An LLM gateway manages model-provider access, prompts, completions, token usage, model routing, and model safety. An MCP gateway governs the capability side of the agent loop. Some platforms combine both, but the planes remain conceptually separate.

Why teams add a gateway

MCP reduced the need to build every host-to-service integration separately. It did not eliminate the operational problems created when many reusable integrations exist.

A company may begin with one local filesystem server and one source-control server. That deployment can be managed in host configuration. As adoption grows, the organization may acquire dozens of servers maintained by different teams, distributed through different package ecosystems, using different authorization patterns, serving different tenants, and supporting different MCP revisions. At that point, direct host-to-server relationships produce recurring governance questions:

• Which servers are approved?
• Who owns each server?
• Which tools may each user or agent see?
• How are upstream credentials stored and refreshed?
• How quickly can a compromised server be revoked?
• How are tool schemas reviewed for changes?
• How are calls correlated across hosts, gateways, servers, and APIs?
• How are older clients connected to modern servers?
• How are private servers exposed without making them public?
• Which component preserves the end-user identity through multiple hops?

These are not all problems for the MCP core specification. They are infrastructure and governance problems around the protocol boundary. The recurring Gateway Interest Group meetings in 2026 explicitly framed the community topic as intermediary aggregation, routing, patterns, use cases, and implementation challenges rather than as a newly standardized core role. [S501] [S502] [S503]

Gateway demand has also been accelerated by the movement from local stdio integrations to remote and multi-user services. Remote operation introduces TLS, OAuth, token audience, network policy, rate limits, tenancy, observability, availability, and service ownership. A central intermediary can make those controls consistent, but it can also hide mistakes if teams assume the gateway alone is sufficient.

---

Gateway archetypes and capabilities

The term gateway is currently too broad to be useful without classification. The nine types below are analytical categories, not mutually exclusive products.

3.1 Protocol-aware reverse proxy

This is the narrowest gateway. It accepts Streamable HTTP traffic, authenticates the caller, applies transport or method-level policy, and forwards the request to one server or a pool of equivalent replicas. It may validate Mcp-Method, Mcp-Name, and protocol-version metadata; preserve SSE; apply rate limits; and record audit events. Pomerium and NetScaler illustrate identity-aware and application-delivery variants. [S517] [S519] [S528]

3.2 Virtual-server or aggregation gateway

This gateway presents one logical MCP endpoint backed by several downstream servers. It merges or searches downstream catalogs and routes calls to the correct target. AWS AgentCore, Cloudflare server portals, Docker MCP Gateway, and several open-source projects implement variations of this pattern. [S476] [S506] [S507] [S512] [S527]

Aggregation creates semantic problems absent from a transparent proxy. Two servers can publish the same tool name. Resource URIs may collide. Prompt names can require prefixes. A failure in one target must not necessarily make the whole virtual server unavailable. The gateway needs a stable provenance and namespacing strategy.

3.3 API-to-MCP conversion gateway

This pattern turns selected API operations into MCP tools. The gateway may import OpenAPI, create schemas, publish a capability list, transform arguments into API requests, and translate responses into MCP content. Apigee, WSO2, Zuplo, Tyk, and other API-management systems use this pattern. [S515] [S524] [S525] [S526] [S529] [S541]

Automatic conversion lowers integration cost, but generated tools are not automatically good tools. An OpenAPI operation can be too broad, ambiguously described, unsafe for model selection, or dependent on business rules not present in its schema.

3.4 Identity and credential gateway

This gateway authenticates users, agents, services, or host applications and obtains the credentials needed downstream. It can perform OAuth discovery, PKCE, token exchange, client credentials, upstream OAuth, service-account mapping, or managed enterprise authorization. Pomerium’s upstream OAuth bridge is a clear example: external clients receive a Pomerium token while upstream provider tokens remain at the intermediary. [S133] [S499] [S500] [S517] [S518] [S520]

3.5 Control-plane and lifecycle gateway

This pattern registers, deploys, updates, scales, health-checks, and removes MCP server workloads. Microsoft’s project includes management APIs, adapters, Kubernetes resources, portal operations, and dynamic tool registration. The control plane is distinct from the data plane that carries calls. [S504] [S505]

3.6 Portal and catalog gateway

A portal curates approved servers and presents them through a consistent connection surface. It may supply search, owner metadata, connection status, and one endpoint. Cloudflare’s portals and IBM ContextForge illustrate catalog-oriented patterns. [S512] [S537]

3.7 Multi-protocol agent gateway

This pattern governs MCP alongside model APIs, A2A, or other agent protocols. Solo’s agentgateway and IBM ContextForge are examples. The benefit is consistent identity, policy, and observability across agent and capability traffic. The risk is collapsing distinct authority models into one generic “AI request.” [S522] [S523] [S339] [S536] [S537]

3.8 Local-to-remote bridge or transport-normalization gateway

A bridge exposes a local stdio or localhost server to a remote host, or translates between stdio, legacy HTTP+SSE, and Streamable HTTP. Development tunnels are one form. This can be useful for testing with cloud hosts, but it changes the threat model by turning a local capability into a network-reachable one. [S520]

3.9 Observability and debugging gateway

This intermediary captures methods, schemas, latency, errors, streams, and traces for testing or operations. Fiberplane’s repository represents this category. Such gateways can improve diagnosis but may also record tokens, prompts, resources, and tool results. [S532] [S544]

---

Data plane, control plane, and trust boundaries

A production gateway usually has at least two very different surfaces. The data plane handles latency-sensitive MCP traffic; the control plane registers servers, authors policy, manages credentials, and changes the fleet. Separating them is not cosmetic: an overloaded data plane interrupts calls, while a compromised control plane can rewrite every route and permission.

Table 1: Data plane, control plane, and trust boundaries

Plane	Function	Examples	Failure impact	Sources
Data plane	Route requests	Mcp-Method/Mcp-Name routing, target selection	Live calls fail	[S121] [S131] [S504] [S476] [S534]
Data plane	Enforce call policy	Tool allowlists, arguments, rate limits	Unsafe allow or excessive deny	[S121] [S131] [S504] [S476] [S534]
Data plane	Broker credentials	Token exchange, API-key injection	Credential leak or downstream failure	[S121] [S131] [S504] [S476] [S534]
Data plane	Aggregate capabilities	Merge tools/resources/prompts	Stale or incorrect catalog	[S121] [S131] [S504] [S476] [S534]
Data plane	Observe traffic	Trace, metrics, audit, redaction	Blindness or privacy leak	[S121] [S131] [S504] [S476] [S534]
Control plane	Register servers	Ownership, publisher, endpoint, package	Malicious target enters fleet	[S121] [S131] [S504] [S476] [S534]
Control plane	Deploy and lifecycle-manage	Kubernetes, health, update, removal	Fleet outage or compromise	[S121] [S131] [S504] [S476] [S534]
Control plane	Author policy	RBAC, ABAC, environment rules	Systematic policy error	[S121] [S131] [S504] [S476] [S534]
Control plane	Manage secrets	Vault references and OAuth credentials	Fleet-wide credential compromise	[S121] [S131] [S504] [S476] [S534]
Control plane	Approve schema changes	Descriptions, JSON Schema, annotations	Rug pull or semantic drift	[S121] [S131] [S504] [S476] [S534]

The gateway does not erase downstream systems. A tool can still reach a database, SaaS API, repository, or local process with its own identity and business rules. Keep those resource boundaries visible in diagrams, policy, and incident records. [S121] [S131] [S133] [S533] [S534]

---

What MCP 2026-07-28 changes for gateways

The current revision created an architectural era boundary.

No modern initialization session

A current request includes the protocol version, client information, and client capabilities in _meta. server/discover is an optional ordinary request that reports supported revisions and server capabilities. There is no modern initialize/initialized exchange and no modern Mcp-Session-Id. [S127] [S058]

HTTP routing metadata

Streamable HTTP requires Mcp-Method and, for requests that name a tool, resource, or prompt, Mcp-Name. The server validates those headers against the JSON-RPC body. A gateway can use them for routing, rate limits, policy, and telemetry without parsing the entire request before making a decision. Header/body mismatch must be rejected rather than trusted as a routing hint. [S131] [S497]

Cacheable discovery and catalogs

Complete list and resource-read results carry ttlMs and cacheScope. These fields let clients and intermediaries know how long a result may remain fresh and whether it is safe to share across authorization contexts. A gateway must include user, tenant, scope, and downstream target in an appropriate cache key; a time-to-live alone does not make cross-user reuse safe. [S128] [S498]

Multi Round-Trip Requests

Modern server-to-client interaction uses explicit input_required results and request retries rather than assuming a persistent bidirectional session. The retry carries requestState and responses. A gateway that terminates or transforms these flows must preserve integrity, ownership, expiry, and routing of explicit state. [S058] [S053]

Trace context

Current documentation standardizes W3C Trace Context keys in request metadata. A gateway can correlate a call across host, client, gateway, server, and downstream API. Trace propagation should not become unrestricted baggage propagation; sensitive or untrusted values must be controlled. [S053] [S532]

What did not disappear

The stateless core did not eliminate:

• OAuth state;
• user sessions in the host;
• long-running Tasks;
• database state;
• explicit server handles;
• durable jobs;
• gateway caches;
• gateway control-plane databases;
• tenant identity;
• downstream service sessions.

The precise statement is: modern MCP ordinary requests do not rely on hidden protocol-session state.

Revision implications at a glance

Table 2: Revision implications at a glance

Revision	Era	Gateway implications	Current status	Main risk	Sources
2024-11-05	Handshake	Initialization forwarding, HTTP+SSE/stdio conversion, stream association	Historical; HTTP+SSE deprecated	Legacy two-endpoint behavior	[S131] [S127] [S058] [S053] [S055]
2025-03-26	Handshake	Streamable HTTP, initialize, optional sessions, OAuth framework	Historical	Session affinity and batching-era behavior	[S131] [S127] [S058] [S053] [S055]
2025-06-18	Handshake	Structured output, PRM, Resource Indicators	Historical	Auth and result-shape differences	[S131] [S127] [S058] [S053] [S055]
2025-11-25	Handshake	OIDC/CIMD, richer elicitation, experimental Tasks	Historical but common	Legacy session and callback model	[S131] [S127] [S058] [S053] [S055]
2026-07-28	Modern stateless core	server/discover, self-describing requests, routing headers, MRTR, cache scope	Current	Metadata/body validation and explicit state ownership	[S131] [S127] [S058] [S053] [S055]

Capability discovery remains optional in MCP. A gateway must preserve discovery behavior when the connected peers use it; it must not imply that every server implements a separate discovery operation.

Supporting modern and legacy clients

A production gateway may need to support current and handshake-era clients at the same endpoint.

A modern client can attempt server/discover. If the endpoint does not support the method, the client may fall back to initialize and negotiate an older revision. Official SDK documentation describes this modern-probe/legacy-fallback pattern. [S127]

A dual-era gateway therefore needs two distinct paths:

Modern client
  server/discover → self-describing requests → stateless routing

Legacy client
  initialize → selected revision/capabilities → optional session affinity

The gateway should expose the selected or observed protocol revision in logs and diagnostics. “Connection succeeded” is not enough: a connection can succeed through a legacy fallback while operators believe they are testing current behavior.

AWS AgentCore Gateway currently provides unusually explicit documentation for this distinction, listing 2026-07-28 alongside several older revisions and showing separate request forms for prompts and resources. Tyk’s current public documentation, by contrast, identifies 2025-11-25 as its supported revision. Solo’s current compatibility documentation describes automatic coexistence of modern and legacy clients and servers. These differences should be represented as a dated compatibility matrix, not flattened into “supports MCP.” [S476] [S506] [S507] [S508] [S515] [S522]

For complete breaking changes and migration behavior, use the protocol versions matrix and stateful-to-stateless migration guide.

---

Aggregation, partial failure, and cache scope

Aggregation is one of the most attractive gateway functions and one of the easiest to implement incorrectly.

Merging tool catalogs

A gateway can query or cache each downstream tools/list result and publish a combined list. It must decide:

• how tools are named;
• whether the original name is preserved;
• how the publisher and target remain visible;
• what happens when two tools collide;
• how filtering affects pagination and ordering;
• how changes invalidate caches;
• whether schemas are transformed;
• how a call maps back to the correct target.

AWS prefixes tool and prompt names with a target identifier. Cloudflare’s portal concept and Docker’s gateway also create one access surface across several servers. Prefixing is practical but not cost-free: it changes names exposed to models, can consume context, and may break clients or prompts expecting the original name. [S506] [S512] [S527]

Merging resources

Resources are identified by URIs, not tool names. A gateway must decide whether to preserve, namespace, rewrite, or prioritize colliding URIs. AWS documents returning original resource URIs and using target priority when multiple targets expose the same URI. It also warns that resource URIs are supplied by downstream servers and are not sanitized automatically. [S507] [S508]

URI preservation aids interoperability but creates routing ambiguity. URI rewriting solves collisions but changes identity and may break embedded references. There is no universally correct choice; the gateway must document its rule.

Merging prompts

Prompt names can collide like tools. Prefixing is common. A gateway also needs to preserve prompt arguments, messages, embedded resources, icons, and current cache semantics.

Partial failure

If one target is unavailable, should tools/list fail, return a partial list, or return a stale cached list? The answer affects model behavior and user trust. A strong gateway marks provenance and availability explicitly rather than silently dropping tools.

Dynamic filtering

The published catalog may differ by user, group, tenant, environment, device, agent identity, or approval state. Catalog filtering improves least privilege and reduces model-context cost. It is not sufficient authorization: the gateway must repeat the decision when tools/call, resources/read, or another operation occurs.

Discovery is not authorization

Three operations are often confused.

Discovery

Discovery answers what a server or gateway says it supports. server/discover reports protocol versions and high-level capabilities. Primitive-list methods report tools, resources, and prompts. [S127]

Filtering

Filtering answers what the gateway chooses to reveal to this caller. A gateway may hide destructive tools, unapproved servers, or tenant-inappropriate resources.

Authorization

Authorization answers whether the caller may perform this specific operation on this target object now.

A user can be allowed to see delete_issue while lacking permission to delete a protected repository’s issue. Conversely, a tool may be omitted from the model catalog but callable by an approved MCP App. A correct gateway treats filtered discovery as user-experience and least-privilege input—not as a durable authorization grant.

Every call should be checked using current identity, tenant, policy, arguments, resource, server provenance, and upstream authorization. Tool annotations such as read-only or destructive are hints and must not be accepted as proof from an untrusted server. [S123] [S134] [S108]

Names, provenance, and collisions

A virtual MCP server needs a name-resolution policy.

Prefixing

A gateway can publish github___create_issue and gitlab___create_issue. This is explicit and easy to route. It lengthens names and couples clients to gateway conventions.

Namespaced metadata

The gateway can preserve the original tool name while attaching target metadata. This keeps schemas compact but depends on clients preserving and displaying the metadata.

Per-server views

The gateway can expose separate logical endpoints or groups. This avoids collisions but reduces the convenience of one endpoint.

Semantic selection

A gateway can keep a large private catalog and publish only the tools selected by search. AWS documents semantic tool search; Cloudflare’s Code Mode similarly addresses large catalogs through programmatic discovery and execution. [S510] [S514]

Search-based discovery improves scale but creates ranking and omission risk. The search layer becomes part of the security and correctness boundary. Operators need evaluation data for false negatives, false positives, malicious descriptions, and language variation.

Regardless of naming strategy, audit records should preserve:

• original publisher;
• original server identifier;
• original tool name;
• gateway-visible name;
• schema hash or version;
• route and target selected;
• policy decision;
• acting user and agent.

Without provenance, an aggregated result can appear to come from “the gateway,” obscuring the component that actually executed it.

The tools, resources, and prompts comparison explains the primitives themselves. A gateway’s job is to preserve their semantics and origin—not flatten them into anonymous endpoints.

---

Identity is a chain, not one token

Enterprise gateway diagrams often show one Authorization header and label the problem solved. Real systems have several identities:

1. End user
2. Host application
3. MCP client
4. Acting agent or service
5. Gateway
6. Downstream MCP server
7. Upstream API or database
8. Tenant, resource, and purpose

The authorization question is not merely “is this token valid?” It is:

Who is acting, on whose behalf, through which host and agent, for what purpose, against which downstream resource, with which policy and approval?

A gateway should preserve enough of that chain to make downstream authorization and audit meaningful. Reducing every request to one powerful gateway service account destroys user attribution and can create a confused deputy.

Table 3: Identity is a chain, not one token

Identity or fact	Preserve as	Why	Failure mode	Sources
End user	Subject, groups and tenant	Object-level and delegated authorization	Shared service identity hides accountability	[S133] [S531] [S005] [S192] [S006] [S533]
Host/client	Client ID and product/version	Client policy and incident response	Unknown caller surface	[S133] [S531] [S005] [S192] [S006] [S533]
Acting agent	Agent/service identity	Delegation and non-human policy	Agent authority conflated with user	[S133] [S531] [S005] [S192] [S006] [S533]
Gateway	Intermediary service identity	Downstream trust and audit	Gateway impersonates every caller	[S133] [S531] [S005] [S192] [S006] [S533]
Downstream server	Publisher, server ID, endpoint	Routing, provenance, revocation	Tool origin ambiguous	[S133] [S531] [S005] [S192] [S006] [S533]
Underlying resource	OAuth audience and tenant	Token targeting	Token reused at wrong service	[S133] [S531] [S005] [S192] [S006] [S533]
Purpose/intent	Approved operation/context label	Semantic authorization and DLP	Broad token used for unrelated work	[S133] [S531] [S005] [S192] [S006] [S533]
Policy version	Decision ID/hash	Reproducible audit	Cannot explain allow decision	[S133] [S531] [S005] [S192] [S006] [S533]
Trace correlation	Trace ID and request ID	End-to-end diagnosis	Fragmented logs	[S133] [S531] [S005] [S192] [S006] [S533]

Authentication and delegated credentials

Public unauthenticated endpoint

A public read-only server may allow anonymous calls. A gateway can still apply quotas and abuse controls. This pattern should not be used merely to avoid implementing identity for sensitive data.

Static API key or bearer token

This works for narrow machine-to-machine access but has weak user attribution and rotation challenges. The gateway should not pass one inbound token unchanged to unrelated downstream resources.

OAuth authorization code with PKCE

This is appropriate for interactive user delegation. The gateway can act as a protected resource, an OAuth client toward an upstream authorization server, or both. Correct deployment involves protected-resource metadata, resource indicators, issuer validation, redirect validation, and token audience. [S133] [S531] [S005] [S192] [S006] [S004] [S003]

Client credentials

The OAuth Client Credentials extension supports non-user actors. It should represent a constrained machine identity rather than a shared universal credential. [S500]

Token exchange and on-behalf-of

OAuth token exchange can transform an inbound identity into a token targeted to the downstream resource. AWS documents an on-behalf-of pattern for AgentCore Gateway. Token exchange must preserve actor, subject, audience, and scope instead of silently escalating privilege. [S509] [S531]

Enterprise-managed authorization

The stable Enterprise-Managed Authorization extension lets managed environments centralize authorization relationships. A gateway can participate, but the extension is not synonymous with a gateway and should not be projected into products that do not document support. [S499] [S063]

Upstream OAuth brokering

Pomerium documents a two-leg design in which clients hold a Pomerium-issued token while Pomerium obtains, caches, refreshes, and injects an upstream provider token. This reduces credential exposure to the external client and centralizes policy; it also makes the gateway a sensitive token custodian. [S517] [S518] [S520] [S521]

MCP 2026-07-28 also changes gateway authorization compatibility: client-credentials tokens are bound to the authorization issuer, and Dynamic Client Registration is deprecated in favor of Client ID Metadata Documents. Treat both as versioned client/server behavior, not generic OAuth plumbing. S133 S053 S500

The August 22 official roadmap lists standardized agent identity, broader DPoP adoption, Workload Identity Federation, ID-JAG delegation, token exchange, and progressive discovery as ongoing work—not guarantees shipped by the July specification. Version and test interim gateway designs. [S064]

Authorization at every meaningful level

Gateway policy can operate at several layers.

Server-level access

May this identity connect to this logical or downstream server?

Primitive-level access

May this caller list or use tools, prompts, resources, Tasks, or Apps?

Tool-level access

May this caller see and invoke send_email, execute_query, or delete_file?

Argument-level access

May this caller use environment=production, a path under /finance, an external recipient, or an amount above a threshold?

Object-level access

Does the caller own or have access to the specific repository, customer record, issue, database row, cloud account, or document?

Result-flow access

May the result enter this host, model, conversation, external App, or downstream agent?

The gateway can enforce the first four and sometimes inspect the fifth and sixth. It should not replace authorization in the underlying system. Database row-level security, cloud IAM, repository permissions, SaaS object ownership, transaction safeguards, and approval workflows remain essential. [S533]

Tool policy cannot replace business authorization

Tool-name allowlists are useful but insufficient. Consider:

execute_query(database, query)

A rule allowing execute_query does not determine whether the query is read-only, which database is allowed, whether production data may be returned, or whether the result can leave the organization.

A gateway can improve semantic policy through:

• narrow tool design rather than generic execution tools;
• argument constraints and allowlists;
• typed validation against an approved schema;
• dry-run and preview modes;
• risk classifications maintained outside the server;
• external policy engines such as OPA;
• native downstream IAM;
• explicit human approval for high-impact operations. [S535]

Server-published annotations and descriptions can help. They must be treated as untrusted metadata unless the publisher and release are trusted. Tool poisoning research showed that descriptions themselves can become model-facing attack input. A malicious server can label a destructive tool read-only. [S108]

Schema changes also require policy attention. If a previously approved tool adds a new destination parameter or changes the meaning of an enum, the gateway should detect the schema hash change and trigger review instead of applying an old allow decision indefinitely.

Credential custody and rotation

Gateways often centralize secrets because downstream systems use incompatible authentication patterns. Common credential classes include:

• user-delegated OAuth tokens;
• service-account credentials;
• API keys;
• cloud workload identities;
• database credentials;
• client secrets;
• private keys;
• short-lived token-exchange results;
• upstream session cookies.

A mature gateway should:

• store references rather than secrets in ordinary configuration;
• use a dedicated secret manager;
• isolate token encryption keys;
• rotate credentials;
• minimize token audience and scope;
• separate user and service identities;
• avoid writing secrets to logs;
• revoke on user, server, or policy removal;
• record which downstream credential was selected without recording its value;
• handle refresh failure without silently switching to an overpowered fallback.

Centralization can reduce credential sprawl on developer machines. It also increases blast radius. The gateway database, control plane, backup system, and operators become part of the credential threat model.

---

The gateway security model

18.1 Gateway compromise

A compromised gateway may observe or alter every capability and result passing through it. It can route calls to malicious servers, replace schemas, steal tokens, or falsify audit. The data plane should run with minimal privileges, immutable deployment, strong code provenance, and limited control-plane access.

18.2 Management-plane compromise

An administrator can register a malicious target, change policy, inject secrets, or approve a schema. Strong controls include separate admin identities, multi-party approval for sensitive changes, signed releases, immutable audit, and network separation.

18.3 Token passthrough

Forwarding an inbound token to the downstream server without checking audience allows a token intended for the gateway to be accepted elsewhere. The current MCP security guidance explicitly rejects token passthrough as a safe general pattern. Use resource-specific tokens, exchange, or separately obtained upstream credentials. [S133] [S134]

18.4 Confused deputy and authorization-server mix-up

A gateway that supports many protected resources can send a token request to the wrong authorization server or use a token for the wrong resource. Protected-resource metadata, Resource Indicators, and issuer identification address parts of this problem. [S005] [S192] [S006]

18.5 Catalog poisoning and tool shadowing

A malicious server can publish a misleading name or description resembling a trusted tool. Aggregation can amplify the attack by placing unrelated publishers in one catalog. Namespaces, publisher provenance, schema review, and host filtering are essential. [S108]

18.6 Header/body mismatch

Modern routing headers are useful only if the gateway or downstream server validates that they match the JSON-RPC body. Otherwise an attacker can label a call as a safe tool in the header while naming a destructive tool in the body. [S131] [S497]

18.7 Resource URI attacks

An aggregated resource list can contain internal HTTP URLs, cloud metadata endpoints, or file: URIs. AWS’s gateway documentation explicitly warns that downstream resource URIs are not sanitized automatically. Gateways and clients should restrict schemes and origins and should not automatically follow untrusted URIs. [S507] [S508]

18.8 Cache leakage

A tools/list or resources/read result can depend on user identity, tenant, scopes, policy, or upstream connection status. Reusing a private result in a public cache leaks capabilities or data. Honor cacheScope and include the full authorization context in cache keys. [S128] [S498]

18.9 Prompt injection and cross-tool authority

A gateway can filter tools and inspect some content, but it cannot prove that retrieved documents are safe instructions. Prompt injection may cause a model to request a high-authority tool through the same gateway. Hosts must retain cross-server isolation and meaningful confirmation, and servers must enforce native authorization. [S534] [S108]

18.10 Denial of service

Large catalogs, huge JSON Schemas, long streams, expensive tools, recursive calls, and many downstream targets can exhaust a gateway. Defenses include body and schema limits, pagination, quotas, concurrency limits, circuit breakers, timeouts, and per-tool cost classes.

18.11 Logging and privacy

Gateway logs can contain tool arguments, resources, prompts, user identity, model output, tokens, and business records. “Full visibility” is not always a security benefit. Use structured field allowlists, redaction, encryption, access controls, retention limits, and separate security/audit from debugging payloads.

18.12 Implementation vulnerabilities

Gateway code has its own vulnerabilities independent of MCP semantics. AWS disclosed CVE-2026-14471 in the mcp-gateway-registry metrics-retention subsystem: an authenticated caller could inject SQL, read or alter stored data including API-key material, and affected versions required upgrade to 1.0.13 or later. This was a product implementation flaw, not a universal protocol flaw, but it demonstrates the value concentrated in gateway management and metrics databases. [S511]

Ten risks to test first

Table 4: Ten risks to test first

Threat	Layer	Impact	Core mitigations	Sources
Gateway data-plane compromise	Data plane	Credential/data theft and false results	Minimal privileges, immutable deploy, isolation, signing	[S134] [S534]
Control-plane compromise	Control plane	Fleet-wide compromise	Separate admins, MFA, approvals, immutable audit	[S504] [S511]
Token passthrough	Authorization	Audience confusion and token theft	Validate audience; exchange/separate credential	[S133] [S134]
Tool poisoning	Catalog/model	Bad selection or exfiltration	Publisher trust, schema review, filtering	[S108]
Header/body mismatch	Transport/routing	Policy bypass	Validate header against body	[S131] [S497]
Cross-tenant cache leakage	Caching	Capability/data disclosure	Honor cacheScope and auth context	[S128] [S498]
Catalog collision/shadowing	Aggregation	Wrong target invoked	Namespaces, provenance, collision rules	[S476] [S512]
Over-logging	Observability	Credential/data exposure	Redaction, encryption, retention limits	[S532] [S534]
Policy fail-open	Policy	Unauthorized call	Fail closed for high-risk operations	[S535]
Gateway sole authorization layer	Architecture	Bug bypasses native controls	Keep native IAM and object authorization	[S533] [S534]

Product documentation proves only product-specific boundaries. Docker documents its own controls for transports, catalogs, URLs, images, containers, secrets, logs, routing, and policy, and maintains a separate advisory index. Check affected versions; neither source is a security endorsement or a protocol-wide vulnerability claim. [S550] [S551]

The downloadable 25-row gateway threat register preserves the complete research matrix. This page covers gateway-specific concentration and enforcement boundaries; the broader MCP security guide owns OAuth threats, prompt injection, tool poisoning, implementation vulnerabilities, supply-chain risk, and server hardening.

Zero trust still applies downstream

Zero trust does not mean “put every MCP call through one gateway.” NIST’s zero-trust model emphasizes explicit verification, least privilege, resource-centric policy, and the assumption that network location alone is not trustworthy. [S533]

Applied to MCP:

• authenticate users and services;
• authorize each request and target resource;
• minimize downstream credentials;
• preserve identity across hops;
• treat local and private-network servers as untrusted until verified;
• continuously evaluate policy and device context where relevant;
• record decisions and provenance;
• do not assume one gateway decision authorizes every downstream action.

The gateway can be a policy-enforcement point. It should not be the sole source of truth for every resource. Defense in depth requires the server and underlying system to enforce their own constraints.

---

Observability without indiscriminate logging

A useful gateway audit model separates events rather than storing one undifferentiated request log.

Connection and discovery events

• caller identity;
• host/client identity;
• gateway endpoint;
• requested and selected protocol revision;
• authorization result;
• downstream server set;
• catalog version and filter policy.

Invocation events

• MCP method;
• original and gateway-visible primitive name;
• downstream server and publisher;
• schema version/hash;
• argument classification or redacted digest;
• policy decision and reason;
• approval state;
• downstream credential class;
• latency and result status.

Lifecycle events

• server registration;
• deployment and update;
• schema change;
• secret rotation;
• health status;
• deprecation;
• revocation and removal.

Security events

• denied calls;
• header/body mismatch;
• invalid resource URI;
• token audience failure;
• catalog collision;
• anomalous rate or cost;
• policy-engine failure;
• sensitive-data detection.

W3C Trace Context provides correlation keys for distributed tracing, but trace data should not carry raw secrets or arbitrary untrusted baggage. [S532]

Performance and reliability

A gateway adds at least one component and often one network hop. Its performance impact depends on architecture.

Potential costs include:

• TLS termination;
• token verification or exchange;
• policy evaluation;
• catalog merge and filtering;
• JSON parsing;
• schema transformation;
• DLP or content inspection;
• logging and trace export;
• regional distance;
• queueing at a centralized bottleneck.

Potential benefits include:

• connection reuse;
• cached catalogs;
• semantic search instead of exposing every tool;
• centralized retry and circuit breaking;
• locality to downstream APIs;
• pooled credentials;
• elimination of repeated host-specific integrations.

Do not use a vendor benchmark as a universal MCP gateway number. Measure the actual path: client-to-gateway, gateway processing, downstream server, underlying API, and model loop. A 20-millisecond proxy overhead may be irrelevant to a ten-second workflow and unacceptable to a high-frequency tool.

Reliability design

A production gateway should consider:

• multiple data-plane replicas;
• no single regional endpoint where availability requires more;
• bounded retries;
• idempotency classification;
• circuit breakers per target;
• stale catalog behavior;
• downstream health isolation;
• graceful degradation;
• backup and restore of control-plane state;
• safe rollback of policy and schema changes.

Modern 2026-07-28 traffic can use round-robin routing for ordinary requests. Legacy clients may still require session affinity, so the gateway must not remove stateful support while claiming compatibility with handshake-era revisions. [S053]

The noindex observability schema is a privacy-aware starting point, not a command to log every field. Measure gateway latency separately from downstream execution, and define whether retries are safe before automating them.

---

Gateway versus adjacent infrastructure

“Gateway” names a function, not one product shape. A reverse proxy can carry MCP without parsing it, a Registry can supply an approved catalog without mediating calls, and an LLM gateway controls the model side rather than the capability side.

Table 5: Gateway versus adjacent infrastructure

Component	Primary responsibility	Protocol awareness	Not equivalent to	Sources
MCP gateway	Live mediation, aggregation, routing, identity, policy and operations	MCP methods, primitives, versions and streams	Core protocol role	[S121] [S501] [S504] [S476]
MCP server	Expose capabilities and execute/delegate operations	Native server side	Fleet-wide policy layer	[S121] [S123] [S124]
API gateway	Govern REST, GraphQL, gRPC and HTTP APIs	HTTP/API; MCP optional	MCP capability governance by default	[S515] [S524] [S525] [S529]
LLM gateway	Govern model-provider calls, prompts, tokens and cost	Model APIs	Tool execution governance	[S536] [S537] [S542]
Reverse proxy	Forward network traffic	Usually transport only	Catalog and MCP policy	[S517] [S519] [S528]
MCP Registry	Publish server metadata and distribution references	Metadata, packages, endpoints	Runtime authorization	[S067] [S066]
MCP host	Coordinate model, user, permissions and clients	Client side and product behavior	Central intermediary	[S121]
Identity provider	Authenticate users/services and issue identity	OAuth/OIDC	MCP router	[S531] [S005] [S192] [S006] [S003]

Use the focused MCP gateway vs API gateway decision guide to choose an HTTP edge, MCP-aware mediation, or both. Use MCP vs APIs for the protocol/API boundary, MCP vs function calling for model selection, and MCP vs A2A for agent delegation. Products may combine planes; policy and identity must remain explicit.

---

A dated gateway landscape—not a ranking

The category spans architectures that cannot share one feature score. This dated table summarizes first-party documentation from August 26, 2026; it does not prove interoperability, security, value, or a universal winner. Revision caveats require direct testing.

Table 6: A dated gateway landscape—not a ranking

Product or project	Documented pattern	Documented aggregation	Revision caveat	Sources
Microsoft MCP Gateway	Reverse proxy + lifecycle/control plane + tool router	Tools and adapters	Session-oriented docs; verify current revision	[S504] [S505]
AgentCore Gateway	Managed aggregation + connectors + policy	Tools, prompts, resources, MCP targets	2026-07-28 plus 2025 revisions	[S476] [S506] [S507] [S508] [S509] [S510]
MCP Server Portals	Portal/catalog + aggregation	Servers, tools, prompts; Code Mode	Transport strategies documented; exact protocol revision live-check	[S512] [S513] [S514]
Pomerium MCP Gateway	Identity-aware proxy + OAuth bridge	Route/server discovery, not primarily one merged catalog	Current docs; live-check exact wire revisions	[S517] [S518] [S519] [S520] [S521]
agentgateway	Multi-protocol agent data plane	MCP virtualization/federation	2026-07-28 plus legacy coexistence	[S522] [S523] [S536]
API Hub and Apigee MCP proxies	API catalog + API-to-MCP conversion	Selected API operations	Product-specific; live-check	[S524] [S525] [S526]
Docker MCP Gateway	Local container aggregation gateway	Tools, resources, prompts across catalog servers	Live-check	[S527]
MCP Context Forge	Federated registry/gateway + multi-protocol	Virtual servers and federation	Live-check	[S537]

Other projects remain source material, not an indexable “best gateways” list. Any future buyer’s guide requires repeatable tests, maintenance and security checks, and transparent commercial disclosures.

---

Maturity, centralization, and federation

The maturity model is diagnostic, not a standards ladder. More features mean more evidence requirements and concentrated risk—not necessarily a better fit.

Table 7: Maturity, centralization, and federation

Level	Capabilities	Evidence required	Characteristic risk	Sources
0 Generic proxy	HTTP forwarding/TLS	Transport tests	False assumption of MCP awareness	[S121] [S504] [S476] [S512] [S533]
1 MCP-aware proxy	Version/method/stream handling, MCP OAuth	Protocol test matrix	Limited catalog/policy	[S121] [S504] [S476] [S512] [S533]
2 Policy gateway	Filtered discovery, per-tool policy, audit	Bypass and fail-closed tests	Policy centralization	[S121] [S504] [S476] [S512] [S533]
3 Aggregation/credential gateway	Multiple targets, namespaces, token brokering	Collision, cache and identity tests	Credential/catalog blast radius	[S121] [S504] [S476] [S512] [S533]
4 Enterprise platform	Data/control planes, lifecycle, multi-region, revocation	Operational and security controls	High cost and admin authority	[S121] [S504] [S476] [S512] [S533]
5 Federated/multi-protocol	Domain gateways, MCP/A2A/model traffic	Cross-domain identity and audit	Semantic and governance complexity	[S121] [S504] [S476] [S512] [S533]

Table 8: Maturity, centralization, and federation

Dimension	Centralized	Federated	Sources
Policy consistency	Strong	Requires shared standards	[S533] [S534]
Blast radius	Large	Smaller per domain	[S533] [S534]
Domain ownership	Can bottleneck	Strong	[S533] [S534]
Cross-domain discovery	Easy	Needs catalog/federation	[S533] [S534]
Regional latency	Potentially high	Can be local	[S533] [S534]
Credential concentration	High	Distributed	[S533] [S534]
Audit	Unified	Needs correlation	[S533] [S534]
Operations	One platform	More duplicated work	[S533] [S534]

---

Build, adopt, or stay direct

Build when

• the gateway is a narrow internal proxy;
• existing identity and API infrastructure can supply most functions;
• protocol requirements are well understood;
• custom business policy is the core differentiator;
• the team can maintain modern and legacy compatibility;
• the organization can operate security-critical infrastructure.

Buy or adopt an existing project when

• broad OAuth and client compatibility is required;
• multi-region reliability matters;
• many servers and teams need lifecycle management;
• support and compliance requirements are substantial;
• protocol updates must be absorbed quickly;
• the organization lacks gateway engineering expertise.

Evaluate both with the same evidence

• exact MCP revisions;
• supported primitives and extensions;
• session and modern routing behavior;
• identity and token model;
• catalog collision policy;
• authorization granularity;
• audit and redaction;
• security history;
• deployment ownership;
• exit and migration path.

Signals that justify a gateway

A gateway is strongly justified when several of these are present:

• many downstream servers;
• multiple host products;
• centralized user and agent identity;
• upstream OAuth or service credentials;
• private network resources;
• per-tool or argument-level policy;
• regulatory audit;
• rapid revocation;
• controlled catalogs;
• current/legacy version translation;
• multi-tenant remote service;
• shared rate limits and quotas;
• regional routing and availability;
• schema-change governance.

When the direct architecture is better

A gateway may be unnecessary when:

• one trusted user runs one local server;
• the host already provides adequate approval and configuration;
• the server uses native OAuth directly;
• no shared credential or private-network boundary exists;
• a conventional API gateway already performs the exact needed controls;
• the added operational burden exceeds the security or management value;
• the deployment cannot adequately secure the gateway control plane.

A direct host-to-server relationship is the protocol’s native architecture and remains the simplest correct solution for many deployments.

Questions to answer before choosing

Before selecting a product or writing code, answer five groups of questions.

A. Topology

• How many hosts, gateways, servers, users, agents, and tenants exist?
• Are servers local, remote, private, public, or mixed?
• Is one virtual endpoint required, or would separate endpoints be clearer?
• Must the gateway convert existing APIs into MCP?
• Will A2A or model-provider traffic use the same infrastructure?

B. Identity

• Is the caller a user, service, autonomous agent, or combination?
• Must the end-user identity reach the underlying API?
• Which component obtains and refreshes upstream tokens?
• Are service accounts allowed?
• Can credentials be scoped by server, tool, tenant, and resource?
• How are deprovisioning and revocation propagated?

C. Policy

• Is access controlled by server, primitive, tool, arguments, object, or result flow?
• Which actions need user confirmation?
• Are schemas and descriptions reviewed before publication?
• What happens when a schema changes?
• Does policy fail closed when the policy engine is unavailable?
• Is native downstream authorization preserved?

D. Compatibility

• Which MCP revisions must be accepted upstream?
• Which revisions do downstream servers implement?
• Does the gateway translate or simply proxy?
• Are tools, resources, prompts, elicitation, Tasks, Apps, and subscriptions supported?
• How does it handle modern routing headers, cache scope, and MRTR?
• What diagnostics show the actual selected revision?

E. Operations

• Where does the data plane run?
• Where does the control plane and secret store run?
• What is the expected failure domain?
• Can catalog or policy changes be rolled back?
• How are traces and audit records redacted?
• What is the patch and vulnerability-disclosure process?
• Can the organization export configuration and migrate away?

A gateway is a good fit when the answers reveal shared infrastructure problems. It is a poor fit when the organization cannot articulate the required function beyond “we need an MCP gateway.”

Do you need an MCP gateway?

Use the assessment below to turn the preceding questions into a bounded architecture recommendation. It is a transparent heuristic, not a product recommendation or security certification. The useful output is the unmet requirement and risk flag—not the numeric score.

Interactive architecture check

Gateway fit assessment

Choose only requirements you can defend. Choices stay in your browser. If privacy-safe analytics are configured, only a coarse result, score, and selected-count metric are sent—never the individual conditions.

Which conditions are true?

Shared estate. Several teams, hosts, or servers need one governed access boundary.Aggregation. Clients need one curated catalog or endpoint across several downstream servers.Identity chain. User, agent, tenant, or on-behalf-of identity must survive multiple hops.Credential brokering. The boundary must obtain, isolate, rotate, or exchange downstream credentials.Governance. Central allowlists, rapid revocation, audit, schema approval, or quotas are required.Compatibility. Measured demand requires modern and legacy MCP behavior or transport normalization.Private access. Supported hosts must reach services across a controlled network boundary.Operational readiness. A named team can secure, patch, monitor, test, recover, and eventually replace the gateway.

How the score works

Identity-chain and credential-brokering requirements add 3 points each; the other architecture requirements add 2; readiness adds no points. Scores 0–2 stay direct, 3–6 suggest a narrow proxy, 7–11 suggest a bounded gateway, and 12+ suggest an enterprise or federated evaluation. Any score of 7+ without operational readiness produces a stop-and-prepare result.

Show recommendationReset

Start with requirementsDirect host-to-server is the default.

Select the conditions that create a real shared-infrastructure problem. A gateway is not a maturity badge.

Copy result

---

Implementation checklist

Protocol handling

• ☐ Record and validate the MCP protocol revision on every request.
• ☐ Support server/discover or clearly document that it is not supported.
• ☐ Validate Mcp-Method and Mcp-Name against the JSON-RPC body.
• ☐ Preserve request-scoped SSE and subscription streams.
• ☐ Apply size, time, and concurrency limits.
• ☐ Preserve JSON-RPC IDs and error semantics.
• ☐ Define modern and legacy lifecycle behavior separately.
• ☐ Test MRTR retries and explicit requestState ownership.

Aggregation

• ☐ Define collision behavior for tools, prompts, and resource URIs.
• ☐ Preserve original server and publisher provenance.
• ☐ Use deterministic ordering.
• ☐ Handle partial target failure explicitly.
• ☐ Avoid exposing every catalog item when search or grouping is safer.
• ☐ Invalidate caches on policy, identity, target, and schema changes.

Identity and authorization

• ☐ Validate token audience and issuer.
• ☐ Avoid general token passthrough.
• ☐ Preserve end user, acting agent, tenant, and purpose where required.
• ☐ Reauthorize every call, not only discovery.
• ☐ Keep downstream native authorization.
• ☐ Separate user-delegated and service credentials.
• ☐ Provide revocation and token-rotation procedures.

Security

• ☐ Isolate data and control planes.
• ☐ Use least-privileged workload identity.
• ☐ Protect management APIs with stronger controls than ordinary calls.
• ☐ Review and pin downstream publisher identity and schema.
• ☐ Restrict resource URI schemes and origins.
• ☐ Redact secrets and sensitive payloads from logs.
• ☐ Fail safely when policy, identity, or secret services are unavailable.
• ☐ Publish a vulnerability-reporting process and patch policy.

Operations

• ☐ Export OpenTelemetry-compatible traces with MCP attributes.
• ☐ Monitor per-target health and circuit state.
• ☐ Measure catalog size, discovery latency, call latency, and errors.
• ☐ Test rolling upgrades with current and legacy clients.
• ☐ Back up control-plane configuration without exposing secrets.
• ☐ Support configuration export and rollback.

A 24-test gateway evaluation plan

“Supports MCP” should mean more than one successful tool call. The original research plan below covers version behavior, routing metadata, primitive collisions, cache isolation, authorization bypass, token audience, malicious descriptions, redaction, partial failure, instance loss, policy rollback, and stale catalogs.

These are test specifications, not claimed execution results. Record the client, server, gateway build, topology, protocol revision, configuration, expected result, observed result, logs, and evidence for every run.

Table 9: A 24-test gateway evaluation plan

ID	Category	Test	Expected evidence	Sources
T001	Version	server/discover against current endpoint	Supported versions and capabilities without session	[S127]
T002	Version	Modern request metadata validation	Header and _meta version agree	[S131]
T003	Version	Modern client to legacy server fallback	Initialize path succeeds or documented failure	[S053]
T004	Version	Legacy client through gateway	Selected revision and session behavior visible	[S055]
T005	Routing	Mcp-Method mismatch	Gateway/server rejects request	[S131] [S497]
T006	Routing	Mcp-Name mismatch	Gateway/server rejects named request	[S131] [S497]
T007	Tools	List and call each target	Correct provenance and routing	[S123]
T008	Prompts	List/get with colliding names	Documented namespace behavior	[S506]
T009	Resources	Colliding resource URI	Priority or explicit collision error	[S507] [S508]
T010	Caching	Cross-user tools/list attempt	Private scope prevents reuse	[S128]
T011	Policy	Call hidden tool directly	Denied at runtime	[S134]
T012	Policy	Argument constraint bypass	Denied after schema validation	[S535]
T013	Authorization	Wrong token audience	Rejected	[S133] [S005]
T014	Authorization	User deprovisioning	Access revoked promptly	[S499]
T015	Security	Malicious tool description	Quarantined/reviewed or safely represented	[S108]
T016	Security	Untrusted internal resource URI	Not automatically followed	[S508]
T017	Security	Oversized schema/catalog	Bounded failure, no gateway exhaustion	[S131]
T018	Security	Log redaction	No raw token/secret in logs	[S534]
T019	Apps	App-only tool	Not exposed to model/cross-server view	[S136]
T020	Tasks	Task ID from other user	Denied	[S137]
T021	Reliability	One target unavailable during list	Documented partial/stale/fail behavior	[S128]
T022	Reliability	Data-plane instance loss during stream	Defined recovery/no silent duplicate effect	[S131]
T023	Control plane	Bad policy rollout	Rollback restores known policy	[S535]
T024	Control plane	Revoked server with cached list	Invocation denied despite stale catalog	[S128]

Download the plan as JSON or CSV. The machine-readable endpoints are deliberately noindex; their job is reuse, not page-count growth.

---

Governance needs versioned evidence

Gateway policy should be versioned like code. Each decision should be attributable to a policy revision, identity inputs, server provenance, and capability schema.

A disciplined lifecycle includes:

1. Proposal: define the server, tool, identity population, allowed environments, and downstream resource.
2. Review: security, data, business, and server owners examine schemas, credentials, and failure modes.
3. Test: run compatibility, policy-bypass, cross-tenant, and rollback tests.
4. Deploy: stage the rule, observe denials, then enforce.
5. Monitor: measure use, failures, schema changes, anomalies, and unused authority.
6. Revalidate: review after protocol, server, credential, or business changes.
7. Retire: revoke access, rotate credentials, remove caches, and preserve audit.

A policy decision record should contain the caller and agent identities, tenant, gateway, downstream server, original and gateway-visible primitive name, schema hash, arguments or safe digest, policy ID, decision, reason, approval state, credential class, trace ID, and result status.

This evidence supports incident response and also prevents governance from becoming untestable prose. An auditor should be able to reconstruct why a call was allowed under the policy and protocol behavior in effect at that time. Because current MCP places version and capability metadata on requests, the selected revision can be part of the record rather than inferred later. [S131] [S058] [S532]

---

Frequently asked questions

These ten concise answers cover the questions that most often change an architecture or procurement decision.

---

Conclusion

MCP gateways emerged because protocol interoperability does not, by itself, solve enterprise identity, credentials, catalogs, version compatibility, audit, routing, deployment, or lifecycle. A well-designed gateway can make those concerns coherent. The same centralization can magnify mistakes and compromise.

The most defensible view is not that a gateway is the mandatory next layer of MCP. It is that MCP created a reusable capability boundary, and organizations are deciding where to place policy and operational responsibility around that boundary. Revision 2026-07-28 made modern remote traffic substantially more HTTP-native and intermediary-friendly. It reduced session-management complexity and introduced explicit routing and caching semantics. It did not absolve gateways, servers, hosts, or underlying systems of security responsibility.

A gateway is justified when it provides clear value: identity propagation, resource-specific tokens, call-time policy, curated aggregation, private access, multi-version support, centralized revocation, and trustworthy audit. It is unjustified when it merely adds another proxy, credential store, and failure domain.

The practical test is simple:

Can the organization name the gateway functions it needs, the risks those functions introduce, the identities and authority that must survive each hop, and the evidence that the implementation supports the required MCP revisions and capabilities?

Where the answer is yes, an MCP gateway can become durable infrastructure. Where it is no, the simpler host-to-server architecture remains the better design.

Methodology, integrity, and update policy

The gateway categories and maturity model are this guide's analysis, not classifications defined by MCP. Product comparisons are dated documentation reviews. The compatibility test plan describes checks to run; those tests have not been executed here.

Sources and downloadable tables follow. The editorial policy explains review dates, and the source library contains the references.

Download the six selected gateway datasets

• MCP Gateway Architecture Taxonomy JSON · CSV
• MCP Gateway, Server, Registry, API Gateway, LLM Gateway, and Proxy Comparison JSON · CSV
• MCP Gateway Security Threat Register JSON · CSV
• MCP Gateway Compatibility and Security Test Plan JSON · CSV
• MCP Gateway Identity, Credential, and Authorization Framework JSON · CSV
• MCP Gateway Observability Event Schema JSON · CSV

Package integration manifest · Unified content roadmap

Show the complete 81-record canonical source register

1. S121 — Architecture 2026-07-28
2. S131 — Streamable HTTP
3. S133 — Authorization
4. S127 — MCP Server Discovery
5. S128 — Caching
6. S058 — The 2026-07-28 Specification
7. S053 — The 2026-07-28 specification release candidate
8. S055 — Key changes 2026-07-28
9. S123 — Tools
10. S497 — SEP-2243: HTTP Standardization
11. S498 — SEP-2549: TTL for List Results
12. S124 — Resources
13. S134 — Security Best Practices
14. S499 — Enterprise-Managed Authorization
15. S063 — Enterprise-Managed Authorization: Zero-touch OAuth for MCP
16. S500 — OAuth Client Credentials
17. S501 — Gateways Interest Group Meeting — March 4
18. S502 — Gateways Interest Group Meeting — June 3
19. S503 — SEP-1302: Working Groups and Interest Groups
20. S067 — The MCP Registry: About
21. S066 — Introducing the MCP Registry
22. S504 — MCP Gateway Documentation
23. S505 — microsoft/mcp-gateway
24. S476 — Use an MCP server with Amazon Bedrock AgentCore Gateway
25. S506 — Get a prompt from an AgentCore gateway
26. S507 — List resources in an AgentCore gateway
27. S508 — Read a resource from an AgentCore gateway
28. S509 — AgentCore Gateway On-Behalf-Of Token Exchange
29. S510 — Semantic Tool Search
30. S511 — CVE-2026-14471: mcp-gateway-registry SQL Injection
31. S512 — MCP Server Portals
32. S513 — Route MCP Portal Traffic Through Gateway
33. S514 — Code Mode for MCP Server Portals
34. S515 — MCP Gateway
35. S516 — Tyk 5.13 Release Notes
36. S517 — MCP Support
37. S518 — MCP + Upstream OAuth
38. S519 — Protect an MCP Server
39. S520 — Delegate MCP Access to an LLM
40. S521 — MCP OAuth Compatibility & Hardening
41. S522 — MCP Spec Compatibility
42. S523 — Solo Enterprise for agentgateway
43. S524 — API Hub Release Notes
44. S525 — Register MCP APIs
45. S526 — API Hub MCP Reference
46. S527 — docker/mcp-gateway
47. S528 — NetScaler MCP Gateway Capabilities
48. S529 — MCP Hub and Gateway
49. S530 — Identity for MCP and AI Agents
50. S531 — RFC 8693: OAuth 2.0 Token Exchange
51. S005 — RFC 8707: Resource Indicators for OAuth 2.0
52. S192 — OAuth 2.0 Authorization Server Issuer Identification
53. S006 — RFC 9728: OAuth 2.0 Protected Resource Metadata
54. S004 — RFC 7636: Proof Key for Code Exchange by OAuth Public Clients
55. S003 — RFC 6749: The OAuth 2.0 Authorization Framework
56. S532 — Trace Context
57. S533 — SP 800-207: Zero Trust Architecture
58. S534 — Security Design Considerations for AI-Driven Automation Leveraging MCP
59. S108 — MCP Security Notification: Tool Poisoning Attacks
60. S190 — OWASP MCP Top 10
61. S535 — OPA Documentation
62. S339 — A2A Protocol Specification — stable 1.0 line
63. S136 — MCP Apps
64. S137 — Tasks
65. S536 — agentgateway repository
66. S537 — MCP Context Forge
67. S538 — MCP Authentication and Authorization
68. S539 — openziti/mcp-gateway
69. S540 — MCP Gateway
70. S541 — MCP Gateway
71. S542 — MCP and AI Gateway
72. S543 — Kuadrant MCP Gateway
73. S544 — fiberplane/mcp-gateway
74. S545 — Fides: Information-Flow Control for MCP Gateways
75. S546 — Enterprise Authentication for MCP Gateways
76. S547 — Code Mode: Give Agents an Entire API in 1,000 Tokens
77. S548 — mcp-gateway-registry
78. S549 — TypeScript SDK — supporting protocol revision 2026-07-28
79. S064 — The New MCP Roadmap
80. S550 — Docker MCP Gateway security model
81. S551 — Docker MCP Gateway security advisories