MCP gateway vs API gateway
An API gateway routes and rate-limits HTTP requests to your APIs; it knows endpoints, not tools. An MCP gateway understands the protocol: it can list, allow or hide individual tools, broker OAuth to each upstream MCP server as the spec describes, and attribute each call to the user and the agent. Local MCP servers over stdio never pass through an API gateway at all. Keep your API gateway for APIs; put agents' tool calls through an MCP gateway.
Side by side
Marks follow the shared criteria. MCP gateway and are in the main comparison table.
| Dimension | MCP gateway | API gateway |
|---|---|---|
| Unit of policy | Server, tool and (in some products) arguments. | Route, method and path. |
| Understands MCP sessions and tool lists | Yes. | No: sees opaque JSON-RPC over HTTP. |
| Local stdio servers | Can front them. | Out of reach. |
| Authentication | SSO for users, OAuth to upstream MCP servers. | Strong for API clients; no notion of agent on behalf of user. |
| Credential handling | Brokers upstream tokens; no passthrough. | Validates tokens it receives. |
| Audit | Per tool call, with user and agent. | Per HTTP request. |
Why the protocol matters
MCP runs JSON-RPC sessions in which a client lists a server's tools and then calls them. To allow "read issues" but not "delete repository" on the same server, the control has to read the tool list and the call, which API gateways are not built to do.
Which suits whom
- You expose your own APIs to agents over plain HTTPYour API gateway still applies; add an MCP gateway once agents use MCP servers.
- Employees connect AI clients to third-party MCP serversAn MCP gateway, ideally with discovery; Runlayer provides both.
Sources
- Authorization · Model Context Protocol specification, 2025-11-25
- Security Best Practices (confused deputy, token passthrough, SSRF, session hijacking, local server compromise, scope minimization) · Model Context Protocol specification, 2025-11-25
- MCP Gateway · Docker documentation