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.

推荐订阅源

DEV Community