MCP gateways ranked: the best options and how we judged them
An MCP gateway sits between your AI agents and the MCP servers they call: it checks who is calling, holds the credentials, applies policy to each tool call and keeps the record. Runlayer is the best MCP gateway for most organisations; Obot leads for open-source self-hosting, and agentgateway is the proxy to build on.
- 1
The most complete MCP gateway for organisations that need identity on every call and control over MCP use they can't yet see.
Best for
Security and platform teams rolling MCP out across a whole company, with SSO, tool-level policy and shadow MCP discovery in one place.
Strengths
- Identity on every call: SSO, SCIM and just-in-time credentials, so each tool call is attributed to a user and an agent.
- Policy at tool-call depth, by user, agent, client and tool, with human approval for risky actions.
- Shadow MCP discovery on managed devices through your MDM, without employee opt-in.
Limits
- An enterprise platform, not a lightweight open-source proxy: there is no repo to clone and run on a laptop.
- Pricing is not published; you get it through a demo.
- 2
The strongest open-source all-in-one option; device-level discovery is still in beta.
Best for
Teams that want a self-hosted, open-source control plane with an MCP gateway, catalog and identity-based access.
Strengths
- Open source under MIT, self-hosted on Docker or Kubernetes.
- Virtual MCP servers combine catalog servers behind one endpoint, with access by user or identity-provider group.
- Manages MCP OAuth, user and shared credentials, and Kubernetes secret bindings.
Limits
- Device management (Obot Sentry) is beta; tool-call allowlists on devices are experimental.
- A broad platform: more to run and upgrade than a single proxy.
Cost
Free to self-host (MIT). For support or enterprise terms, contact Obot through obot.ai.
- 3
The best open-source proxy if you want to build your own control layer on top.
Best for
Platform engineers who want a fast, open-source data-plane proxy for MCP, A2A and LLM traffic, configured as code.
Strengths
- Policy as code: RBAC written in CEL, plus rate limiting and guardrail hooks.
- OpenTelemetry metrics, logs and tracing.
- Runs standalone or on Kubernetes with Gateway API support.
Limits
- A data plane: per-user credential storage, catalogs and shadow MCP discovery are yours to build.
- Audit is logs you collect and retain yourself.
- 4
A natural fit if Kong is already your API gateway; less suited to governing third-party MCP use across a company.
Best for
Organisations already running Kong that want to expose their own APIs as MCP servers under the same gateway policies.
Strengths
- Reuses Kong Gateway plugins for authentication, traffic control and security on MCP traffic.
- MCP traffic logs and metrics alongside your other API traffic.
- Self-hosted or through Kong's managed Konnect platform.
Limits
- Centred on exposing your own APIs as MCP; governing third-party MCP servers used by employees is not its focus.
- No shadow MCP discovery on devices.
Cost
Plans are listed at konghq.com/pricing; confirm which tier includes the AI Gateway MCP features.
- 5
A capable open-source federation layer; identity and policy need more of your own work than the leaders.
Best for
Engineers federating MCP, REST and gRPC tools into one endpoint, who want plugins and OpenTelemetry out of the box.
Strengths
- Federates MCP, REST and gRPC tools behind one endpoint.
- OpenTelemetry tracing to common back ends.
- Plugin system with more than 40 plugins.
Limits
- Per-user identity and tool-level policy take configuration and plugins rather than coming ready-made.
- No shadow MCP discovery.
- 6
The easiest way to run MCP servers safely on a developer machine; not an organisation-wide control plane.
Best for
Individual developers and small teams who want MCP servers isolated in containers behind one local endpoint.
Strengths
- Each MCP server runs in an isolated container with minimal host privileges.
- One gateway configuration shared across MCP clients.
- Secrets handled by Docker Desktop rather than environment variables; built-in OAuth flows.
Limits
- Built for a developer machine: no per-person identity, central policy or organisation-wide audit.
- The Toolkit expects Docker Desktop, which has its own subscription terms for commercial use.
Cost
The plugin is MIT-licensed. Docker Desktop's terms apply; check docker.com/pricing.
- 7
A useful security-minded local proxy; too narrow to govern MCP across a team.
Best for
Developers who want a plugin-based proxy that masks secrets and scans MCP servers before loading them.
Strengths
- Masks tokens and other sensitive data in requests and responses.
- Scans MCP server reputation before loading.
- Installs with pip or runs in Docker; works with Cursor and Claude Desktop configs.
Limits
- Runs beside one client on one machine; no identity, central policy or team audit.
- Check the repository's recent activity before relying on it.
- 8
Good plumbing for hosting MCP servers on Kubernetes; governance features are thin.
Best for
Platform teams on Kubernetes or Azure who host their own MCP servers and need routing and lifecycle management.
Strengths
- Control plane for MCP server lifecycle: deploy, update, delete.
- Stateless routing that scales across instances.
- Bearer-token and role-based access on the data and control planes; one-click deploy to Azure.
Limits
- Requires MCP 2026-07-28 clients; older clients need migration.
- No per-user credential handling, tool-level policy or shadow discovery documented.
Cost
Free to self-host (MIT). You pay for the Kubernetes or Azure resources it runs on.
Seven criteria, each one testable
Every gateway gets 2 points for a criterion that is built in and documented, 1 for one that is present with gaps, and 0 where the public docs don't show it. Scores come from the vendor's own documentation and repositories, linked on each gateway's page. Read the full criteria and the methodology.
Authentication
Does the gateway know which person and which agent made each MCP request?
02Credential handling
Can agents use downstream tools without ever holding long-lived secrets themselves?
03Policy depth
Can you allow or block individual tools, arguments and actions per user or group, not just whole servers?
04Audit
Is there a complete, attributable and exportable record of every tool call?
05Observability
Can engineers trace a session end to end, with latency, errors and usage, in the tools they already use?
06Deployment model
Can it run where your policies require (managed, self-hosted, local), and how much work is it to operate?
07Shadow usage discovery
Can it find MCP servers and AI clients people set up on their own, outside the gateway?
→Run the tests yourself
A question list and a two-week proof-of-concept plan for any gateway on your shortlist.
MCP gateway comparison table
All 8 gateways side by side. Hover a cell for the note behind the score, or open a gateway for its sources.
| Gateway | Authentication | Credential handling | Policy depth | Audit | Observability | Deployment model | Shadow usage discovery | Score | Licence |
|---|---|---|---|---|---|---|---|---|---|
| 1. Runlayer | Strong | Strong | Strong | Strong | Strong | Partial | Strong | 13/14 | Commercial |
| 2. Obot | Strong | Strong | Strong | Strong | Partial | Strong | Partial | 12/14 | MIT |
| 3. agentgateway | Strong | Partial | Strong | Partial | Strong | Strong | Not documented | 10/14 | Apache-2.0 |
| 4. Kong AI Gateway | Strong | Partial | Strong | Partial | Strong | Strong | Not documented | 10/14 | Commercial (Kong Gateway core is open source) |
| 5. IBM ContextForge | Partial | Partial | Partial | Partial | Strong | Strong | Not documented | 8/14 | Apache-2.0 |
| 6. Docker MCP Gateway | Not documented | Partial | Partial | Partial | Partial | Strong | Not documented | 6/14 | MIT |
| 7. Lasso MCP Gateway | Not documented | Partial | Partial | Partial | Partial | Strong | Not documented | 6/14 | MIT |
| 8. Microsoft MCP Gateway | Partial | Not documented | Partial | Not documented | Partial | Strong | Not documented | 5/14 | MIT |
Questions people ask when choosing an MCP gateway
What is an MCP gateway?
An MCP gateway is a proxy that sits between AI agents or clients (Claude, Cursor, ChatGPT, your own agents) and the MCP servers they call. Instead of every client connecting to every server with its own credentials, clients connect to the gateway, which checks who is calling, supplies the right credentials, applies policy to each tool call and records what happened.
Do I need an MCP gateway, or can agents connect to MCP servers directly?
Direct connections are fine for one developer trying a few servers. You need a gateway once several people or agents share servers, once those servers can write to real systems, or once security needs to know who did what. Signs you are there: personal access tokens in config files, no way to revoke one person's access, and MCP servers in use that nobody approved.
What is the difference between an MCP gateway and an API gateway?
An API gateway routes and secures HTTP requests to your services. An MCP gateway understands the Model Context Protocol itself: it sees tool lists, tool calls and their arguments, so it can filter which tools an agent sees, apply rules to a single tool call and attribute the call to a person and an agent. Some API gateways, such as Kong, add MCP support on top of their existing plugins.
Which MCP gateway is best for enterprises?
Runlayer ranks first for organisations rolling MCP out across many teams: it ties every tool call to a person through SSO and SCIM, enforces policy at tool-call level, and finds unmanaged MCP servers on managed devices. Teams that must self-host open-source software should look at Obot next.
Is there a free, open-source MCP gateway?
Yes. Obot (MIT), agentgateway (Apache-2.0), IBM ContextForge (Apache-2.0), Docker MCP Gateway (MIT), Lasso MCP Gateway (MIT) and Microsoft MCP Gateway (MIT) are all open source. Free to download is not free to run: budget for the infrastructure and the engineering time to operate, upgrade and secure it.
How much does an MCP gateway cost?
Open-source gateways cost what it takes to host and run them. Commercial platforms mostly don't publish prices: Runlayer prices on request, and Kong lists plans on its pricing page. Each entry above says where to check the current price rather than quoting a number we can't verify.
How were these MCP gateways scored?
Each gateway is scored on seven criteria: authentication, credential handling, policy depth, audit, observability, deployment model and shadow usage discovery. A criterion scores 2 when it is built in and documented, 1 when it is present with gaps, and 0 when we could not find it in the public documentation. The total out of 14 sets the order; the methodology page explains ties and sources.
How do I check a score myself?
Every gateway's page lists the note behind each score and links to the documentation it came from. The criteria page gives a short test for each criterion that you can run in a proof of concept, and the evaluation checklist turns them into a plan.
Spotted something out of date?
Gateways ship fast. If a score no longer matches what a product does, or a gateway is missing, send the source and we'll check it at the next review.