What Is an MCP Gateway?

An MCP gateway is a security proxy that sits between AI agents and the MCP servers they use. Tool listings and tool calls pass through it, where tool definitions are screened, calls are evaluated against policy before they execute, outputs are scanned, and every decision is logged. One enforcement point governs every server behind it.

The Model Context Protocol standardized how agents discover and call tools, and adoption followed: a working agent deployment now touches several MCP servers, some internal, some third-party, some found on a registry. Each one extends what the agent can do, and each one extends what can go wrong. An MCP gateway exists because governing that surface server by server, agent by agent, does not scale; governing the traffic does.

What problem does an MCP gateway solve?

Three, and they compound as the number of servers grows:

• Untrusted tool definitions. Any server an agent connects to describes its tools in text the agent treats as trusted context. A poisoned description, or one that changes after review, steers the agent from inside its own toolset. The techniques are covered in MCP security: tool poisoning, rug pulls, shadowing.
• Ungoverned calls. A vetted tool can still be asked to do the wrong thing. The file tool that was fine in a scratch directory writes to a config directory; the database tool that was reading starts deleting. Vetting the catalog does not govern the calls.
• No evidence. Without a chokepoint, "what did the agent actually do through its tools last Tuesday" has no authoritative answer. Per-call records are what make an agent deployment reviewable by a security team or an auditor.

How does an MCP gateway work?

The agent is pointed at the gateway instead of at each server; the gateway holds the real server registrations and proxies the protocol. That position lets it act at the three moments that matter:

• At discovery, when a server lists its tools: each definition is screened for embedded instructions before the agent ever reads it, and compared against the definition previously seen, so a changed tool is a governed event rather than a silent one.
• At the call, when the agent invokes a tool: the arguments (the command, the query, the file path, the message) are evaluated against policy before the call is forwarded, with graduated verdicts: allow, warn, require approval, block.
• At the response, when the tool returns: output is screened for injected instructions and sensitive data before the agent reasons over it, because tool output is untrusted input wearing a trusted uniform.

Throughout, every decision is recorded: which agent, which tool, what was asked, what was decided, and why at the category level. The operator sets the policy; the gateway enforces what the operator declared.

What is the difference between an MCP server and an MCP gateway?

The names are close enough that the two are often conflated in searches and in architecture discussions. They are different layers:

An API gateway and an MCP gateway are not substitutes. The API gateway sees an authenticated HTTPS request and passes it; it does not parse a tool schema for embedded instructions or evaluate whether a SQL string in a call body should require approval. The MCP gateway is the same architectural idea applied one layer up, where the payload is agent behavior.

What should an MCP gateway check?

• Tool definitions at every connect, not once at onboarding: screening on each listing is what catches a definition that changed after review.
• Definition drift: a remembered baseline per tool, so any change to a trusted definition surfaces for re-approval instead of taking effect silently.
• Call arguments against policy: commands, queries, file operations, and messages evaluated before execution, with verdicts graduated by consequence.
• Tool outputs: screened for injected instructions and data exposure before the agent consumes them.
• Agent identity and scope: which agent is calling, and whether the call fits what that agent declared it was for. Context is what separates a database agent doing database work from an agent that has drifted.
• Evidence: a per-call record of what was attempted and decided, exportable to the systems a security team already watches.

Do you need an MCP gateway if agents call servers directly?

The gateway is the strongest deployment pattern because it does not depend on the agent cooperating: traffic that does not pass the gateway does not reach the server. But it is not the only pattern. The same checks can run as advisory calls from the agent runtime itself: scan a tool schema before registering it, scan a command before executing it. That path suits development and frameworks that resist a proxy hop. The practical difference is enforcement strength: an advisory check is a verdict the agent consults; a gateway is a boundary the traffic cannot skip. Many deployments start advisory and move to the gateway as the agent count grows. Where the enforcement boundary sits is a deployment property, covered in the agent security stack.

Related concepts

• What is MCP security? The attack techniques a gateway exists to govern.
• What is action governance? The discipline the gateway applies to each call.
• The 17 agentic attack techniques: where gateway controls sit in the published taxonomy.
• MCP server and Model Context Protocol in the glossary.
• OWASP Agentic Top 10 mapping: the risk catalog these controls map to.