MCP Gateway vs API Gateway: What Changes and When You Need One (2026)
Teams hear "MCP gateway" and reach for their API gateway mental model: routes, rate limits, auth plugins, done. That model gets the shape right and the job wrong. An API gateway manages access to APIs for internal or external clients. An MCP-aware gateway adds discovery and policy controls for tools, resources, and prompts. Those concerns may live in separate components or in one gateway with MCP support.
The confusion is understandable because both sit in the middle and both speak HTTP. But the questions each answers diverge fast. An API gateway asks: where does this request go, who called it, how fast may they call. An MCP gateway asks: which tools should this agent even know exist, what may each tool touch, and who approves the call before it runs. If your agent consumes tools from more than one team, you need the second set of answers, so check whether your existing gateway provides MCP-aware controls.
Different jobs: routing requests vs curating capabilities
An API gateway can manage APIs used by services, browsers, mobile apps, or other clients. Its transport functions include authentication, rate limiting, request routing, and observability. AWS’s API Gateway overview describes this broader scope; callers are not assumed trustworthy simply because they reach a gateway.
An MCP gateway manages model to tool traffic. The upstream caller is an agent interpreting natural language, and its tool calls are probabilistic choices, not deterministic code paths. The Model Context Protocol gives that agent three primitives: tools it can invoke, resources it can read, prompts it can use. The gateway decides which of those primitives each agent sees, under what permissions, with what approvals.
That shift from deterministic caller to probabilistic caller changes everything downstream. Rate limiting a service protects capacity. Scoping tool discovery for an agent protects correctness: every irrelevant tool in context is another chance for the model to pick wrong. Curation is not a nicer word for routing. It is a different function entirely.
The N×M problem and MCP-aware consolidation
Without a gateway, each agent integrates directly with each MCP server: credentials per server, discovery per server, permission logic per server, audit per server. Two agents and three servers means six integrations. Five agents and eight servers means forty. TrueFoundry's gateway writeup frames this as the N×M problem, and the math only moves one direction as adoption grows.
A transport-only proxy does not automatically understand tool discovery or per-tool policy. Some gateway products provide those functions: Kong’s AI MCP Proxy documentation describes proxying MCP servers, converting HTTP APIs into tools, and aggregating tool sets. Evaluate the deployed product and configuration rather than assuming the API gateway label rules out MCP support.
In a hub-and-spoke integration model, a gateway can reduce N×M direct connections to N+M gateway connections. This counts connection relationships, not every credential, policy, or maintenance task. Servers register once with a registry. Agents connect once to the gateway. Discovery, auth, permissions, and audit live in one place. This is the same consolidation logic that made API gateways win, applied one layer up where the units are capabilities instead of endpoints. Our from-scratch gateway build walks through that registry layer concretely: what registration stores, how discovery filters per agent, where the permission check sits in the call path.
What an MCP gateway actually does
Strip away vendor pitches and four functions remain. Everything else is packaging.
First, registry. A catalog of available MCP servers, their tools, versions, and owners. Agents query the registry instead of hardcoding server addresses. When a team ships a new tool version, registration updates once instead of every agent config updating separately. IBM's mcp-context-forge, an example of the registry-and-gateway pattern, centers the registry alongside the gateway for exactly this reason.
Second, scoped discovery. The gateway filters which tools each agent sees based on role, task, or session. A data analysis agent sees the query tool and the charting tool, not the deploy tool. This is a correctness feature disguised as a security feature: a smaller relevant tool list can reduce supplied context, but tool-selection accuracy and cost still need measurement with your model and workload.
Third, permissions and approvals. Per tool policies: this role may call freely, that role needs human approval, nobody calls delete without a ticket reference. Cordon implements human-in-the-loop approvals on tool calls as a standalone gateway concern, which shows where the boundary sits: the policy lives in the gateway, outside any single agent's ability to skip it.
Fourth, audit. Every tool call logged with agent identity, arguments, result status, and latency. When something goes wrong at 2am, one log answers what the agent did, in what order, with whose credentials. Distributed logs can also support an incident investigation if identifiers and retention are consistent.
The lethal trifecta: why tool calls need a security boundary
The sharpest argument for a gateway is a threat model with a name. The lethal trifecta for AI agents combines three individually reasonable exposures: access to untrusted content, access to private data, and the ability to communicate externally. The combination creates an exfiltration risk: injected instructions in fetched content may lead an agent to send private data externally. This threat model does not establish that any pair is harmless or that every attack succeeds.
A gateway inspecting each request in isolation may miss the risk across calls. Session-aware policy, provenance, and egress controls can help correlate the sequence. An MCP-aware gateway can provide a place to enforce those controls, but they are implementation requirements rather than guarantees supplied by the protocol.
This is also why tool result handling belongs in the gateway conversation. Marking which tool outputs came from untrusted sources, so downstream steps treat them as data rather than instructions, is a gateway grade concern. Keep enforcement outside the agent’s control and test whether the chosen boundary covers every relevant tool path.
Build vs adopt: open source options and where each fits
The space is young and crowded, which means options sort by maturity rather than features. Three patterns cover most needs.
The registry gateway pattern, exemplified by IBM mcp-context-forge, fits platform teams serving many agents across teams. Registry plus discovery plus auth in one control plane. Adopt when you own the platform and need every team's servers behind one discovery surface.
The security proxy pattern, exemplified by Cordon and the open-edison gateway, fits teams whose first problem is trust: untrusted content flowing into capable tools. Approvals, content scanning, egress control. Adopt when the threat model drives the purchase, or bolt approval gates onto your existing gateway.
The embedded pattern, a gateway library inside your agent framework rather than a standalone service, fits single team setups with a handful of servers. Our from-scratch guide shows how little code the core loop needs: register, discover, authorize, proxy, log. Build when your server count is small and your permission model is simple; migrate to a standalone gateway when either stops being true.
Avoid buying a control plane for a problem you do not have yet. One agent and two internal servers need scoped credentials and an audit log, not a registry cluster. The gateway earns its keep at the point where hand maintained agent configs start drifting, so use observed configuration drift and policy needs rather than a fixed server-count threshold.
Decision rule: when you need one, when an API gateway suffices
Use this rule and move on. Consider an MCP-aware gateway when shared discovery, consistent policy, or auditing across trust boundaries becomes difficult to maintain in existing clients and servers. The gateway's curation, permissions, and audit are load bearing from that point forward.
An API gateway may cover your transport needs for a small fixed tool set. Still enforce authorization and validate arguments at the tool boundary; assess whether discovery and approvals need additional support.
Between the two sits the most common real setup: API gateway underneath for transport concerns (TLS, rate limits, service auth), MCP gateway above for capability concerns (discovery, permissions, approvals, audit). They stack cleanly because they answer different questions. Choose separate services or an integrated gateway according to the capabilities you have verified.
