The Model Context Protocol (MCP) gave the agent ecosystem something it desperately needed: a standard way for models to discover and call tools. The cost of that standard is that every agent now talks to a sprawl of MCP servers local, remote, vendor-hosted, community-built with very different trust levels.
An MCP gateway is the natural response: a single hop the agent talks to, which in turn fans out to the actual MCP servers, applying authentication, policy, and observability on the way.
What an MCP gateway actually does
- Registry & discovery. One endpoint the agent connects to; the gateway knows which downstream MCP servers exist and which tools each one exposes.
- Auth fan-out. The agent authenticates once to the gateway. The gateway handles per-server credentials such as OAuth, API keys, and mTLS, without exposing them to the model.
- Policy enforcement. Tool calls pass through a policy engine before forwarding. Block destructive verbs, gate certain tools behind approval, redact fields in arguments or responses.
- Observability. Structured logs of every tool call, with the reasoning context, latency, error, and outcome.
- Rate limiting & cost control. Per-tool, per-tenant, per-agent quotas.
How it differs from neighbors
vs. an API gateway
An API gateway speaks HTTP. An MCP gateway speaks MCP it understands tool definitions, argument schemas, and capability negotiation. You can layer an API gateway under an MCP gateway, but you can't replace one with the other.
vs. an LLM gateway
An LLM gateway sits on the model-call path (POST /chat/completions). An MCP gateway sits on the tool-call path. Most production agents need both, and the policies that live in each are different.
vs. a forward proxy
A forward proxy is protocol-agnostic and sees every outbound call the agent makes including ones that bypass MCP entirely (a stray fetch(), a vendor SDK that does its own networking). An MCP gateway only sees MCP-shaped traffic.
Where guardrails belong
The honest answer is: in both places, for different reasons.
- The MCP gateway is the right place for tool-aware policy: "this agent can call
jira.create_issuebut notjira.delete_project." - A network-level proxy is the right place for the catch-all: "no outbound traffic to
*.attacker.com, ever, regardless of which library or tool initiated it."
Relying only on the MCP gateway means anything the agent does outside MCP, such as a Python library making its own HTTP call, a browser tool, or a server-side exec, is unenforced. The network layer is the floor; the MCP gateway is the ceiling.
When to deploy an MCP gateway
If you have one agent talking to one MCP server, you don't need a gateway. If you have multiple agents, multiple servers, or a single server you don't fully trust, you do. The breakpoint is usually around the third MCP integration that's when per-server auth, observability, and policy stop fitting in your head and start needing infrastructure.
MCP gateways are not the whole story of agent security, but they're a load-bearing piece of it. Build (or buy) one as soon as your tool surface is bigger than what one engineer can keep in a mental map.