MCP Gateway vs MCP Server: What Each One Controls, and When You Need Both

An MCP server exposes tools and resources to an AI agent over the Model Context Protocol. An MCP gateway is a proxy you run in front of many servers that decides which agents may reach them, which tools each agent may call, and whether the content moving in both directions is safe to read. The server provides capability. The gateway provides control. They are not alternatives, and a team running several servers with no gateway has capability with no control.

The confusion is understandable, because both terms describe something an agent connects to over the same protocol, and some gateway projects describe themselves as servers because that is exactly how the agent sees them. But the question that actually matters when you are choosing what to build or buy is which of the two decides whether a call happens. Only one of them does.

What an MCP server does

An MCP server is the component that publishes tools. A GitHub server publishes tools for reading issues and opening pull requests. A database server publishes query tools. A filesystem server publishes read and write tools. When an agent starts a session, it asks each connected server what it offers, and the server answers with a manifest: tool names, parameters, and a natural-language description of what each tool is for.

That description is the part people underestimate. It goes into the model's context, and it is written by whoever operates the server. If you did not build the server, you have delegated part of your agent's instructions to a third party. The model reads the description to decide when to use the tool, which means the description influences behavior, not just documentation.

Most useful MCP servers are wrappers around a system that already existed. A server that gives an agent access to a shared support inbox is doing roughly what any tool that lets you connect every IMAP mailbox in one place does, except the consumer is a model rather than a person. The server did not create the risk, it exposed an existing system to a new kind of caller, and that caller decides for itself which calls to make.

What an MCP gateway does

A gateway sits between the agents and those servers so that connection policy lives in one place. Instead of each agent holding its own server list and its own credentials, agents point at the gateway, and the gateway decides what happens next.

Concretely, it does five things a direct connection cannot. It allowlists which servers an agent may reach at all. It fetches and inspects each tool manifest before the description reaches model context. It records a hash of approved definitions so a later change is a detectable event rather than a silent one. It scopes which specific tools each agent may call, so being connected to a server is not the same permission as being allowed to use everything on it. And it writes one audit record per call across every agent, which is the only way to answer what a given server was asked last week.

This is not a niche opinion. The Cloud Security Alliance research note on MCP tool poisoning, published July 2, 2026, lists gateway or proxy deployment for manifest inspection among its recommended controls, alongside tool definition hash pinning and explicit server allowlisting. We cover the full control set on our MCP gateway page.

Side by side

Why the distinction matters more than it sounds

Without a gateway, your MCP policy is a set of JSON config files. That has three specific failure modes, and they compound.

The first is that approval happens once. Someone reviews a server, adds it to a config, and the review is never repeated. CVE-2025-54136, rated CVSS 8.8 and disclosed in July 2025, established the consequence: approving a tool definition does not survive later server-side changes. A server can serve a benign definition at review time and a different one afterward. Nothing in a config file notices.

The second is that config files get copied. The list that one team reviewed for one project ends up in four other repos, carrying its assumptions with it, and now the blast radius of a bad entry is organization-wide with no single place to revoke it.

The third is that connection is treated as authorization. If an agent is connected to a server, it can call everything that server exposes. A research agent that needs to read issues typically also holds the write tools on the same server, because nobody separated them. That is not a policy decision anyone made, it is what happens by default.

The scale of the exposure is measurable. The same CSA note reports benchmarking across more than 45 real-world MCP servers with attack success rates above 60 percent, reaching 72.8 percent against the strongest agent model tested. Those attacks work through the tool description and the tool result, which is exactly the content a gateway is positioned to inspect and a config file is not. The mechanics are in MCP tool poisoning.

Do I need an MCP gateway?

A reasonable threshold: if your agents connect to more than two MCP servers, or to any server your team did not build, you need one. Below that, per-agent config is genuinely manageable and a gateway is overhead. Above it, you lose the ability to answer basic operational questions, and those questions are the ones that arrive during an incident or an audit rather than on a calm afternoon.

The signal to watch for is not a number of servers, it is whether anyone can answer these without opening a repo. Which agents can reach the production database server? Has any approved tool definition changed since we approved it? Which agent called the delete tool at 3am? If those need an investigation rather than a query, the control layer is missing.

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

An API gateway fronts conventional services and handles auth, routing, and quotas for requests generated by code. Because code decides which calls happen, the set of possible requests is fixed and reviewable in advance. An MCP gateway fronts servers whose tool descriptions influence what a model decides to call next, so it has to inspect content rather than only route it. That is a genuinely different job, and it is why an existing API gateway does not cover MCP. The broader comparison is in AI gateway vs API gateway.

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

A registry is a catalog of servers and their metadata. It records that a server was approved, by whom, and when. That is useful inventory, and it is not enforcement. A registry does not sit in the request path, so it cannot refuse a call, and it does not re-check what a server publishes today. If your MCP governance plan is a catalog, you have a list of what should be true rather than a control that makes it true.

Can an MCP gateway secure a malicious server?

Partly, and the honest boundary is worth stating. A gateway is strong against poisoned tool descriptions, definitions that change after approval, poisoned tool results, and server-side redirect attacks during discovery, because all of those pass through it. It is weak against flaws inside the server's own authorization flow. If a server implements OAuth consent incorrectly, no proxy in front of it retrofits a correct consent implementation. And a gateway governs exactly the traffic routed through it, so an agent that connects directly is simply outside its scope. Securing servers you operate yourself is a different job, covered on MCP server security.

The takeaway

An MCP server answers what an agent can do. An MCP gateway answers what it is allowed to do, with which tools, on whose behalf, and with a record afterward. Teams reach for the first because it unblocks a demo, and reach for the second after they count how many servers ended up in production and realize nobody owns the list. Doing it in that order is normal. Doing it before the count gets large is cheaper.

Agentshield is the enforcement point: MCP traffic routes through it, manifests and results are inspected as untrusted input, each agent gets a scope rather than a connection, and every call lands in one append-only trail. Start with the MCP gateway page, or see how the same control applies across the rest of the agent path in AI runtime security.