Both sit in front of a backend and enforce policy before a request reaches it — that’s where the similarity ends. An API gateway fronts HTTP endpoints called by code you wrote, on a path you can predict. An MCP gateway fronts tools called by a model deciding, at runtime, whether and how to call them. That difference in who’s doing the calling is why the two solve overlapping problems with mostly different machinery.
What a traditional API gateway does
An API gateway (Kong, Apigee, AWS API Gateway, NGINX and a dozen others fill this role) sits in front of a set of REST, GraphQL, or gRPC services and handles the concerns every one of them would otherwise duplicate: routing a request to the right backend, checking an API key or OAuth token, rate-limiting by client or endpoint, transforming a request or response shape, caching, and emitting metrics and traces. The caller is almost always a piece of software with a fixed call pattern — a frontend hitting GET /orders/123, a service hitting POST /invoices. The gateway doesn’t need to guess why the call happened; the client code already decided that before it opened the connection.
What an MCP gateway does differently
An MCP server doesn’t expose REST endpoints. It exposes tools (plus, less commonly, resources and prompts), each with a name, a description, and a JSON Schema, speaking JSON-RPC 2.0 instead of a REST verb-and-path convention. An MCP gateway sits in front of a set of these servers and does some of the same jobs — one URL instead of many, a single OAuth flow instead of a grant per server, logging every call — but the caller on the other end is an AI client, and the actual decision to invoke a given tool, with a given set of arguments, is made by a model reading a description and a conversation, not by a line of code you reviewed at build time.
That one fact changes what “policy” has to mean. Rate limits and auth still matter, but they don’t address the question an API gateway never had to ask: is this tool’s own description trying to manipulate the model into calling it, or calling something else? That’s the premise behind tool poisoning — an attack that has no equivalent in a world where the caller is your own, fixed client code.
Deterministic callers vs. agent-initiated calls
A few consequences fall out of that one difference:
- Granularity. An API gateway mostly governs at the endpoint or service level. An MCP gateway has to govern at the individual tool level — allow this one, ask before that one, block a third — because a single server can mix a harmless read with a destructive write behind the same connection.
- What gets scanned. An API gateway doesn’t read your OpenAPI descriptions looking for an attack; the client code ignores prose anyway. An MCP gateway has reason to scan a tool’s description text itself, before anything connects, the way a security scanner for MCP servers does.
- Credential model. OAuth on an API gateway usually means one grant per integration. MCP’s authorization model (see MCP OAuth scopes explained) is built around per-server, per-client grants that a gateway can centralize — sign in once, every client pointed at the gateway inherits the connection.
- What the log needs to say. An API gateway log is read by an engineer debugging a request. An MCP gateway log is read by someone trying to answer “why did the AI do that” — which means plain-language entries matter more than a status code and a latency number.
Can you just put MCP behind your existing API gateway?
Partially. Most API gateways can proxy or terminate TLS for an MCP server’s HTTP endpoint well enough — it’s still HTTP underneath. What they don’t do out of the box is anything specific to the protocol riding on top of it: they won’t parse a JSON-RPC payload to tell tools/call for a read-only tool apart from tools/call for a destructive one, they won’t scan a tool description for injected instructions, and they generally have no concept of an MCP OAuth grant versus a plain API key. Some products marketed as “MCP gateway” are, honestly, exactly this — protocol translation bolted onto a generic reverse proxy, with none of the tool-level governance. Our checklist for evaluating an MCP gateway goes through how to tell the difference before you commit to one.
When each one is the right tool
If the caller is your own backend code hitting your own (or a partner’s) services, you want an API gateway — that problem hasn’t changed, and MCP has nothing to add to it. If the caller is an AI client — Claude, ChatGPT, Cursor, an internal agent — deciding which tool to invoke based on a conversation, you want an MCP gateway, because the risks worth governing (a manipulated tool description, an over-broad grant, an agent calling something it technically could but shouldn’t) live at that layer, not at the HTTP layer underneath it. Most teams running both AI agents and traditional services end up running both gateways, each in front of the layer it actually understands.
The bottom line
An API gateway and an MCP gateway both centralize policy in front of a backend, and that surface-level similarity is why the names get used almost interchangeably. But the thing being governed is different in a way that matters: fixed code calling a known endpoint versus a model calling a tool it chose on its own. Don’t expect one to quietly cover the other’s job.