What is an MCP gateway?
The Model Context Protocol (MCP) is the spec Anthropic introduced in late 2024 for letting AI agents call external tools, data sources, and APIs through a standard interface. Since then it has crossed 97 million monthly downloads, every major AI vendor has adopted it, and at RSA Conference 2026 Cisco announced dedicated MCP security tooling. When Cisco is shipping security tools for a protocol at RSA, the "this is just a dev tool" phase is over.
An MCP gateway sits between your agents and every MCP server they might call, giving you one place to enforce which agent can use which tool, log every call, and manage the credentials each server needs, instead of every agent connecting directly to every server with its own auth and its own blind spot.
The reason this became urgent fast: once an org has more than a handful of MCP servers, an agent connecting to each one directly means credentials scattered everywhere and no single place to answer "what did this agent actually do."
Why open source matters here specifically
Unlike a lot of infrastructure categories, MCP gateways benefit from being inspectable. You're routing every tool call an agent makes through this thing, including whatever credentials get forwarded to the tool. Being able to read the code that handles that is a reasonable bar to set before trusting it with production access to your systems, which is likely why most of the serious players in this space, including the ones covered below, ship an open-source core even when the enterprise governance layer is paid.
Quick comparison
| Gateway | License | Governance model | Notable strength | Where it falls short |
|---|---|---|---|---|
| MCPX (Lunar.dev) | Open source core (MIT) / Enterprise governance layer | Tool- and intent-level RBAC | Immutable audit trails and vault-backed secrets forwarding, SOC 2 certified | Intent-based access control and the org-wide MCP catalog are Enterprise-tier, not in the OSS core |
| Docker MCP Gateway | Open source | Container isolation | Signed images and Docker's existing tooling, natural fit if you're already container-first | Access control and audit trails are largely build-it-yourself |
| Microsoft MCP Gateway (Azure APIM) | Open source core / commercial Azure tier | Inherits Azure policy model | Entra ID integration and Kubernetes routing out of the box | Governance depth depends on buying into Azure APIM, not really usable standalone |
| IBM ContextForge | MIT | Plugin-based | 40+ plugins, 100+ contributors per IBM's own numbers | Secrets management is less documented than the access-control side |
| MCPJungle | Open source | Lightweight | Simple to deploy, low operational overhead | No built-in RBAC or compliance tooling, aimed at smaller/dev setups |
MCPX (Lunar.dev)
Strengths: MCPX aggregates multiple MCP servers behind one endpoint with zero-code JSON config and dynamic tool discovery. It works with Cursor, Claude Desktop, Claude Code, VS Code, Copilot, n8n, and any MCP-compatible client, which matters if your team is not standardized on one agent yet.
The core capabilities that separate it from a router with logging:
- Tool-level access control via access-control lists, consumer tags, and Tool Groups (curated subsets of tools per team or agent so each identity sees only what it needs)
- Tool customization that lets you rewrite descriptions or lock parameters without touching the underlying server
- Vault-backed secrets that stay out of config files
- Immutable audit logs with full-chain attribution across user, agent, MCP server, and tool
- OAuth to MCP servers built in, not assembled
- Prometheus-compatible metrics for the observability stack you already run
The core is open source under MIT, so the code that handles credential forwarding is inspectable. Lunar.dev is a Gartner Representative Vendor for MCP Gateways (2025) and SOC 2 certified at the Enterprise tier.
For teams weighing how much of this to build themselves versus adopt, the tradeoffs around secret management at enterprise scale are worth reading regardless of which gateway you end up on.
Weaknesses: the parts that go beyond access-control-list basics, intent-based access, the organization-wide MCP catalog, agent inventory and risk scoring, are Enterprise-tier, not in the open-source core. If you just need to aggregate a few MCP servers behind one endpoint with basic RBAC, the open-source core covers that, but the deeper governance story requires the paid tier.
Docker MCP Gateway
Strengths: if your team already thinks in containers, this is the path of least resistance, signed images and the Docker tooling you already run day to day. Isolation is the security model, and it's a model most infra teams already understand.
Weaknesses: access control, audit logging, and secrets handling aren't really built in, they're things you assemble around it. That's fine for a container-first team with the bandwidth to build that layer, less fine for a security team that wants governance out of the box.
Microsoft MCP Gateway
Strengths: for an Azure shop, the pitch is straightforward, Entra ID for identity, Kubernetes for routing, Azure Monitor for observability, all the pieces you're likely already paying for and running.
Weaknesses: the governance story is really "buy into Azure APIM," which is a fine trade if you're Azure-native and a non-starter if you're not. It's less a standalone MCP gateway than an MCP surface on top of an existing Microsoft stack.
IBM ContextForge
Strengths: IBM cites 40+ plugins and more than 100 contributors, a genuinely active open-source community for this specific category, and the plugin model gives it real extensibility for teams willing to build against it.
Weaknesses: secrets management is thinner on documentation than the access-control side, and multi-region federation, while a real capability, adds deployment complexity that smaller teams may not need.
MCPJungle
Strengths: lightweight is the whole pitch, and it delivers on it. Low operational overhead, simple to stand up, a reasonable choice for a team running a handful of MCP servers without a compliance mandate breathing down their neck yet.
Weaknesses: no built-in RBAC or compliance tooling. It's aimed at smaller or dev-stage setups rather than the "this needs to survive a SOC 2 audit" use case.
How to evaluate an MCP gateway in 2026
The honest first question is deployment model: do you need this to run inside your own security boundary, or is a managed option acceptable. That alone eliminates half the field either direction. After that, look at what "governance" actually means for each vendor. Tool-level RBAC is the baseline every gateway on this list has to hit. The differentiator is whether access control understands intent (why is this agent calling this tool right now) versus just identity (is this agent allowed to call this tool at all).
Secrets handling is the other place vendors quietly differ a lot. "Credentials are encrypted" and "credentials are vault-backed and decrypted only in memory during an active session" are not the same claim, and it's worth asking each vendor which one they're actually making.
Final thoughts
The five gateways here split cleanly by what they're optimizing for. MCPX puts the emphasis on audit and compliance, at the cost of gating the deepest features behind a paid tier. Docker and MCPJungle keep things simple. Microsoft's option makes sense on Azure, and IBM ContextForge leans on its plugin ecosystem for extensibility. Which one's right depends less on the feature list and more on which constraint you're actually solving for.
Top comments (0)