MCP Gateway: What It Is and Why Agent Fleets Need One
An MCP server exposes tools. delete_repository, create_charge, execute_query. The agent calls whatever it decides to call, and the server runs it. Nothing sits in between.
Connect a coding agent to a GitHub MCP server and it can delete a repository as readily as it can read one. Point it at a Stripe server and create_refund is one tool call away from list_charges. The Model Context Protocol defines how tools are discovered and invoked. It does not define who is allowed to invoke what. An MCP gateway is the layer that adds that missing decision.
What is an MCP gateway
An MCP gateway is a proxy that sits between your AI clients and the MCP servers they call. Every tools/call leaves the client, reaches the gateway first, and is evaluated against policy before it is forwarded upstream. The gateway allows the call, denies it, or hides the tool from the agent, and can attach argument-level conditions and quota limits.
It is the same architectural idea as an API gateway, applied to agent tool calls. A single control point in front of many backends. The difference is what it inspects: not REST routes, but MCP method calls and their arguments, made by a non-deterministic caller that can be steered by the content it reads.
The protocol is a transport. The gateway is the control plane that the transport never shipped with.
Why MCP needs a gateway
MCP has no permission model. When you connect an agent to a server, it gets every tool that server exposes, with no scoping, no limits, and no per-person identity. Three gaps follow directly.
Unrestricted tool access. A server publishes its full toolset to any connected client. There is no native way to expose get_issue while hiding delete_repository. It is all or nothing.
Scattered, shared credentials. Each server authenticates on its own terms: a bearer token here, an API key there, an OAuth flow somewhere else. Those secrets end up copied into client config files on every developer machine. Nobody can say which person made which call, and revoking access means rotating a key everyone shares. We found exactly this pattern when we scanned open-source MCP configs.
Instructions are not a control. The common fallback is to tell the agent what not to do in a system prompt. That is not enforcement. A model can be talked out of a prompt through injection or simply ignore it, and system prompts are not transport firewalls. Prompt guardrails fail precisely because the thing you are trying to constrain is the thing doing the reasoning.
You cannot enforce policy inside servers you do not control. You enforce it at the boundary every call has to cross.
What an MCP gateway does
A gateway turns the protocol boundary into a control point. The capabilities that matter:
| Capability | What it does |
|---|---|
| Tool filtering | Expose a subset of a server’s tools; hide the rest entirely |
| Per-call policy | Evaluate each tools/call against deterministic rules on any argument |
| Scoped grant tokens | Issue scoped, revocable access per person or agent, not one shared key |
| Credential brokering | Hold upstream API keys and OAuth at the gateway, never in the client |
| Audit trail | Log every call, decision, and the policy path that fired |
| Multi-client | One enforcement layer across Claude Code, Cursor, Codex, and the rest |
Because evaluation happens before the call is forwarded, the decision is deterministic. The model can reason around a prompt. It cannot reason around an action that physically never reaches the server. That is the core of MCP policy enforcement, and the reason the control belongs at the transport layer.
Gateway vs the alternatives
| Approach | Strength | Limitation |
|---|---|---|
| Per-server config | Native to each server | No server ships scoping; nothing is consistent across servers |
| Client-side rules | Close to the agent | Trivially bypassed; every client reimplements it |
| Prompt guardrails | No infrastructure | Not enforcement; defeated by injection |
| MCP gateway | One deterministic control point across every server | You route traffic through it |
The gateway is the only option that holds regardless of which server you call, which client the agent runs in, or what the agent was prompted to do.
How it works
A normal tool call is a JSON-RPC request. The agent asks the server to run a tool with arguments:
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "create_refund",
"arguments": { "charge_id": "ch_105", "amount": 500000 }
}
}Routed through a gateway, that request is evaluated against policy first. If a rule caps refunds, the call is blocked before it reaches Stripe, and the agent receives a tool result marked isError — a failed tool call it can reason about and adapt to, not a transport crash:
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{ "type": "text", "text": "[POLICY DENIED] Refund exceeds the policy limit." }
],
"isError": true
}
}Pointing a client at the gateway is a config change, not a code change. You swap the upstream server URL for your gateway endpoint and attach a scoped token:
{
"mcpServers": {
"stripe": {
"url": "https://proxy.policylayer.com/mcp/<server-uuid>/",
"headers": { "Authorization": "Bearer <grant-token>" }
}
}
}The agent still sees an MCP server. It just sees one with a policy in front of it.
When you need one
A gateway earns its place the moment any of these is true:
- You run agents against more than one MCP server.
- More than one person uses those agents and you need to know who did what.
- Agents touch anything that costs money, deletes data, or sends messages.
- You answer to a compliance regime that expects an audit trail.
A single developer poking at one read-only server does not need a gateway. A team running production agents against Stripe, GitHub, Postgres, and a stack of third-party servers does, and the need is not optional. It is the difference between hoping the agent behaves and knowing what it is allowed to do.
Related reading
- What is MCP policy enforcement
- Runtime governance belongs at the transport layer
- MCP security beyond guardrails
- MCP authentication: securing how agents and servers connect
- MCP authorization: scoping what agents can do
- MCP OAuth: connecting agents to protected servers
Control what your agents can do through MCP.
Get started now →. The product is live.
Browse the policy library →. Pre-classified tools across thousands of MCP servers.
Read the MCP security reference →. What the boundary looks like.
Questions.
An MCP gateway is a proxy that sits between AI clients and the MCP servers they call. Every tool call is evaluated against policy before it is forwarded upstream: the gateway allows the call, denies it, or hides the tool, and can apply argument conditions and quota limits.
MCP has no built-in permission model, so a connected agent can call every tool a server exposes. A gateway adds the missing controls: it scopes which tools and arguments are allowed and enforces that regardless of what the agent is prompted to do.
Authentication proves who is calling. A gateway also handles authorization (what that caller may do on each tool), brokers upstream credentials so they never reach the client, and logs every call. Authentication is one of several capabilities a gateway provides.
A single developer using one read-only server usually does not. A gateway becomes necessary once agents reach more than one server, several people share access, or tool calls can spend money, delete data, or send messages.