Why Everyone Suddenly Wants an MCP Gateway

At a Glance

---

Why This Matters

When a category forms fast, the category name becomes the answer before the question is fully asked. That is where MCP gateways are right now. Products are appearing, blog posts are announcing, and procurement conversations are starting, all before the field has agreed on what a gateway centralizes, what it cannot centralize, and whether it sits in the right place for a given organization's control surface.

If you are designing agent infrastructure today, the question is not "do we need an MCP gateway." The question is "what functions need centralizing, and where do those functions already live."

---

What Happened

Two notable vendor announcements landed in mid-2025.

Docker published the Docker MCP Gateway on 2025-07-09, open-sourcing it as an enforcement point between agents and MCP servers. The stated features include signature verification, secret blocking, and call logging. It aggregates multiple MCP servers behind a single interface and is available in Docker Desktop as well as open source.[4]

Cloudflare announced MCP Server Portals, entering Open Beta on 2025-08-26 as part of Cloudflare One. The product centralizes MCP connections for policy enforcement, logging, and a single portal endpoint. Cloudflare calls its product a "Portal," not a "Gateway," which is a small naming signal worth noting: the category label is not yet stable.[5]

These are dated vendor announcements, not a frozen category definition. They represent two companies placing a bet on where the control point should live, not an industry consensus that it belongs there.

---

What Changed Technically

The Model Context Protocol specifies a JSON-RPC exchange between hosts, clients, and servers. It is a protocol for tool invocation and context sharing, not an agent architecture and not a harness.[1]

What the protocol does not define is enforcement. MCP security guidance names real risks: token passthrough and confused deputy problems.[2] Before MCP, tool-calling security lived inside each integration. Composability is the feature. It is also why the security surface expands: any client that speaks MCP can reach any server that speaks MCP, within whatever trust controls you have in place.

A gateway's appeal is direct: one enforcement point for signature verification, secret scrubbing, call logging, and access control. That logic is sound as far as it goes.

---

What a Gateway Actually Centralizes, and What It Cannot

A gateway positioned between agents and MCP servers can enforce:

• Authentication and authorization at the connection boundary
• Transport-layer policies (allowed servers, blocked endpoints)
• Secrets detection in outbound calls
• Audit logging of invocations

What a gateway sitting at that boundary cannot see or enforce:

• The semantic content of what an agent decides to request before it sends the call
• Prompt injection that arrives through a tool response payload
• Agent reasoning that routes around the gateway by calling servers directly
• Trust decisions inside the host or harness layer

The confused deputy problem named in the MCP security documentation is a useful illustration. If a malicious tool response instructs an agent to forward a credential it received from a different context, the gateway may log the outbound call but cannot necessarily distinguish it from a legitimate one. The attack vector is inside the protocol exchange, not at the transport boundary.[2]

This is not an argument against gateways. It is an argument for knowing what boundary you are defending and what boundaries a gateway cannot reach.

---

The Control Points You Already Have

Here is the reader problem that needs naming: MCP gateway is being treated as a category you must buy, not as a set of functions that may already live in the harness or the mesh.

The Kubernetes Gateway API is an existing, separate control point for L4 and L7 service networking. It is not an MCP product. It models ingress, load balancing, and mesh traffic. Some API gateways can be programmed using it. If your MCP servers are running in a cluster, network-layer policy for who can reach them can be expressed through controls you already operate, without purchasing a dedicated MCP gateway.[3]

Your service mesh, if you have one, handles mTLS, observability, and traffic policy. Your secrets manager handles credential lifecycle. Your identity provider handles principal verification. The question is whether those controls are being applied at the MCP boundary, not whether you need a new product category to apply them.

The new MCP-specific functions, the ones that justify a dedicated product, are the ones that require understanding MCP semantics: call-level logging in terms of tool names and arguments, MCP-aware signature verification, server aggregation behind a stable endpoint. Those are genuinely new functions. They are also the functions most likely to be absorbed into harness frameworks and service meshes as MCP matures.

---

Who Should Care

Platform engineers deciding whether to route MCP traffic through a dedicated gateway, a service mesh, or an existing API gateway. The control surface question belongs to you now, before the architecture is locked.

Staff engineers building or evaluating agent frameworks. The harness layer already makes decisions about which servers an agent can call. Understanding what a gateway adds versus what the harness already enforces matters before you add a proxy layer.

Security engineers responsible for defining the threat model. Token passthrough and confused deputy risks live at the protocol and application layer, not just the transport layer. A gateway addresses part of the surface.

---

What We Are Watching Next

Three things worth tracking:

Harness-native enforcement. If major agent frameworks build MCP-aware policy controls into the harness itself, the case for a separate gateway weakens. Watch the roadmaps of frameworks that already manage tool registration and server selection.

Mesh and Gateway API integration. If MCP traffic becomes first-class in service mesh policy, the enforcement point moves to infrastructure you already operate. The Kubernetes Gateway API is not an MCP product today. That boundary could move.

Protocol evolution. The MCP specification is at version 2025-06-18. Authorization and trust primitives are early. If the protocol itself gains stronger principal binding or delegation controls, some of what gateways currently enforce in front of the protocol may shift into the protocol itself.[1]

---

Platform Signal recommendation

Use an MCP gateway when you need MCP-semantic logging, server aggregation behind a stable endpoint, or call-level enforcement that your existing mesh and API gateway cannot express without significant custom work.

Wait when your MCP server footprint is small, your existing service mesh and identity controls can be applied to MCP traffic with configuration rather than a new product, or the harness layer you are already running handles server selection and access control. Buying a gateway before the threat model is defined adds a proxy layer without a clear problem statement.

The demand for MCP gateways is a real signal: the protocol's security surface is new, the composability is real, and centralized enforcement is a reasonable instinct. The instinct is worth interrogating before it becomes a purchase order.