MCP gateways in 2026, compared: the twelve you should actually know about

The "MCP gateway" category exploded between November 2025 and March 2026. The awesome-mcp-enterprise list now tracks 30-plus tools that call themselves MCP gateways. A lot of them aren't, really. Some are registries, some are agent-side brokers, some are existing API gateways with "MCP" pasted onto the marketing page.

This post sorts the noise. Twelve tools that are actually MCP gateways by my (defended below) definition, grouped by deployment model, with the criteria that matter for picking one. Plus a short section at the end on the things people call MCP gateways that aren't.

I run authsome, which is explicitly not an MCP gateway. We sit one layer down (credential storage and injection on the agent's machine). I have no horse in the gateway race, which is the right vantage point for this kind of post.

What counts as an "MCP gateway"

A working definition: an MCP gateway is a piece of infrastructure that sits between MCP clients (Claude Code, Cursor, custom agents) and one or more MCP servers, and adds at least two of the following:

1. Unified endpoint. Clients talk to one URL, the gateway routes to many backend servers.
2. Auth and access control. OAuth, SSO, RBAC at the tool or server level.
3. Policy enforcement. Block dangerous tool calls, scope-check before forwarding, redact arguments.
4. Observability. Audit logs, traces, metrics for tool calls.
5. Tool transformation. Multiplex many servers into a virtual server, dedupe overlapping tools, semantic search across tool catalogs.

If a tool only does #1 (routing), it's a proxy. If it only does discovery, it's a registry. If it does most of these things together, it's a gateway. The line is fuzzy at the edges.

The criteria I rank on

For each gateway:

• License. Open source (MIT/Apache), source available, or proprietary.
• Deployment. Self-hosted, SaaS, both, cloud-platform-only.
• Auth model. What the gateway expects from clients, and what it forwards to backends.
• Access control granularity. Server-level, tool-level, or tool-argument-level.
• Observability. What you get in audit logs out of the box.
• Backend support. STDIO, HTTP (Streamable HTTP / SSE), or both.
• Active development signal. Recent commits, recognizable maintainer, real backers.

I will not include pricing for proprietary tools unless they publish it. Sales-gated pricing is sales-gated for a reason and I don't want to misquote.

The twelve at a glance

Tier 1: open-source self-hosted

This is where the most active development is happening. If you can self-host, start here.

Lunar.dev MCPX

Repo: github.com/TheLunarCompany/lunar. License: MIT for the core, proprietary enterprise tier on top.

MCPX is the most mature open-source MCP gateway focused on governance. The differentiator is the granularity of its access control model: ACLs at the global level, per-service level, and per-tool level. The enterprise tier adds hosted deployment, IdP integration, automated risk scoring on tool catalogs, and a pre-production sandbox for validating new server additions.

When to pick it: You want a credible commercial vendor's open-source core, with the option to upgrade to a managed enterprise tier later. You care about tool-level access control more than infrastructure simplicity.

ToolHive (Stacklok)

Repo: github.com/stacklok/toolhive. License: Apache 2.0. Maintained by Stacklok and Red Hat.

ToolHive runs every MCP server in an isolated container with minimal permissions and no local credentials. It ships three runtime shapes: a desktop UI for local use, a CLI for terminal workflows, and a Kubernetes Operator for shared multi-user environments. The standout feature is the MCP Optimizer in the vMCP component which uses hybrid semantic + keyword search to surface only the tools relevant to a given request, reducing token usage by 60-85% per call.

When to pick it: You want Apache 2.0 (some teams insist on it over MIT), you run Kubernetes, and you want one of the only gateways that has demonstrated real production deployments at Global 2000 scale.

agentgateway

Repo: github.com/agentgateway/agentgateway. License: open source. Originally from Solo.io, now a Linux Foundation project since August 2025. Hit v1.0 in March 2026.

The most architecturally ambitious option. Written in Rust, designed as an AI-native data plane from scratch rather than an HTTP gateway with MCP support bolted on. Supports both MCP and A2A (Agent-to-Agent) protocols. Contributors include AWS, Cisco, Huawei, IBM, Microsoft, Red Hat, Shell, and Zayo.

When to pick it: You are building infrastructure that needs to last and you want the option that has the broadest neutral-foundation backing. Less appropriate if you need batteries-included tooling around the gateway; the project is still building out its higher-level UX.

Docker MCP Gateway

Repo: github.com/docker/mcp-gateway. License: open source.

Docker's official take. Each MCP server runs in an isolated container with defined resource limits, pulled from an OCI-based catalog with cryptographically signed images. The "interceptor" pattern lets you inject middleware between client and server.

When to pick it: You already run Docker. The security model (container isolation, signed images) matches what your platform team already enforces. You do not need built-in access control or audit trails out of the box; you'll add them.

Microsoft MCP Gateway

Repo: github.com/microsoft/mcp-gateway. License: open source.

A reverse proxy with session-aware routing via Kubernetes StatefulSets, with optional Azure API Management integration. Native Entra ID authentication is the headline feature.

When to pick it: You are on Azure, you already use Entra for identity, and AKS is your default runtime. Less appropriate elsewhere because the governance depth is essentially "whatever Azure APIM gives you."

IBM MCP ContextForge

Repo: github.com/IBM/mcp-context-forge. License: MIT.

A multi-protocol federation framework supporting MCP, A2A, REST-to-MCP translation, and gRPC across multi-cluster Kubernetes environments. Built on FastAPI.

When to pick it: You have a heterogeneous protocol environment and want one control plane that speaks all of them. The trade-off is real deployment complexity. The governance story is less developed than the federation story.

Obot

Repo: github.com/obot-platform/obot. License: MIT.

Open-source MCP gateway providing a control plane to catalog, proxy, and manage MCP servers. Curated catalog, composite servers (combine multiple backends into one), multi-role RBAC, IdP integration, GitOps-style admin.

When to pick it: You want a self-hosted option with a managed-feeling UI and don't want to assemble the catalog/RBAC/IdP integration pieces yourself.

MCPJungle

Repo: github.com/mcpjungle/MCPJungle. License: open source.

Lightweight gateway plus built-in registry. Deploys as a single binary or via Docker Compose.

When to pick it: Small team or single-tenant deployment where you want one process to run, not a Kubernetes cluster to stand up.

Tier 2: hosted / SaaS

For teams that don't want to operate a gateway and are willing to trust a vendor with the routing layer (though, importantly, not necessarily with the credentials, which can still live elsewhere).

Composio

Where: composio.dev. License: proprietary. Deployment: managed SaaS (BYOC available for enterprise).

The largest pre-built catalog. 500+ managed MCP server integrations for SaaS tools like Slack, GitHub, Jira, and Salesforce, with SDKs for LangChain and CrewAI and unified OAuth across all backends. Composio is more "MCP-as-a-service" than "MCP gateway in the routing sense" but it counts because it sits between clients and many backends.

When to pick it: You want to skip the build-and-maintain-50-integrations problem and pay someone else to keep the SaaS connectors current.

Glama

Where: glama.ai. License: proprietary. Deployment: hosted.

Glama hosts and runs MCP servers so you don't run them locally. You connect through Glama's gateway and access servers via API. Bundles directory, hosted runtime, AI gateway, agents, and logging.

When to pick it: Your application is web-based, running MCP servers as local subprocesses isn't practical for your deployment, and you accept the vendor dependency.

MintMCP

Where: mintmcp.com. License: proprietary. Deployment: managed SaaS (on-prem on request).

The headline feature is STDIO-to-remote transformation: take a stdio-only MCP server and expose it as a remote HTTP endpoint that clients can hit from anywhere. The catalog claims 10,000+ servers. Partnership with Cursor.

When to pick it: You have a stdio-only MCP server you want to expose to remote clients without rewriting the server's transport.

Tier 3: cloud-platform managed

If you're already deep in a cloud platform, the platform's own gateway is sometimes the right answer despite the lock-in.

AWS Bedrock AgentCore Gateway

Where: AWS docs. License: proprietary. Deployment: AWS-only.

Semantic search across tool definitions, federated gateway model, consumption-based pricing at $0.000025 per authorization request plus token-volume pricing.

When to pick it: You are all-in on Bedrock and want the gateway to be one more line item on the AWS bill. Skip if you have any portability requirement.

Kong AI Gateway

Where: konghq.com. License: open-source gateway core, MCP Registry in Technical Preview. Deployment: managed, hybrid, self-hosted.

If you already run Kong for API governance, the MCP Registry slots into the same Konnect control plane. Unified REST + gRPC + Kafka + LLM + MCP + A2A governance under one roof. Plus tier pricing is $200 per additional million requests/month over a 1M baseline.

When to pick it: You already use Kong. The MCP add-on is incremental cost and incremental admin surface, not a separate system.

What people call "MCP gateways" but aren't

Three categories worth separating out, because they show up in every "best MCP gateway" listicle and they don't actually compete with the twelve above.

Registries (Smithery, parts of Glama)

Smithery hosts 2,500+ MCP server definitions and lets you discover and install them. It is a registry, not a gateway. The Obot writeup is explicit about this: Smithery itself is "not a managed, enterprise-grade gateway." Useful as a search-and-install index, not as a runtime control plane.

Glama is both a registry and a gateway (above); the registry parts are the parts that look like Smithery.

Agent-side credential brokers (Authsome, Agent Vault, Clawvisor, OneCLI)

These sit on the agent's machine and inject credentials at the outbound HTTPS boundary. They're not in the MCP request path; they're in the underlying-API request path. An MCP server can run behind a credential broker, and an MCP gateway can sit in front of the broker, but they're orthogonal layers. See the dedicated agent credential brokers comparison for that category.

IDE-level MCP managers (Claude Code's built-in mcp commands, Cursor's MCP UI)

These are clients, not gateways. They route the user's local IDE to MCP servers. They don't add cross-server policy enforcement, multi-tenant auth, or audit at the gateway layer.

A decision tree

Three questions get most teams to a defensible pick.

Q1: Are you self-hosting or paying a vendor to host?

• Self-host. Go to Q2.
• Hosted. Composio (most pre-built integrations), MintMCP (STDIO-to-remote), or Glama (hosted runtime + directory). Pick by which is closest to your actual workflow.

Q2: Are you in a Kubernetes shop?

• Yes. ToolHive (production-tested at Global 2000), Obot (most batteries-included), Microsoft MCP Gateway (if Azure), IBM ContextForge (if multi-protocol federation), agentgateway (if you want the LF-backed long-term bet).
• No. MCPJungle (single binary), Docker MCP Gateway (if Docker Desktop / Engine is your runtime), Lunar.dev MCPX (works either way).

Q3: How much do you care about access control granularity?

• Tool-level ACLs. Lunar.dev MCPX or ToolHive.
• Server-level only is fine. Almost any of them.
• Tool-argument-level (block any call with delete: true). This is still rare; Lunar.dev's intent-aware controls and ToolHive's vMCP optimizer are the closest.

A note on what gateways don't solve

An MCP gateway handles the routing, auth, and policy between MCP clients and MCP servers. It doesn't handle the auth between MCP servers and their underlying APIs (GitHub, Stripe, your database). That's a separate problem and most gateways don't address it, by design. If the underlying server still holds a long-lived PAT in its environment, the gateway in front of it doesn't change that. This is the credential-boundary question I covered last week.

For that downstream-auth problem, the answers are:

• Build OAuth into the MCP server itself (the Cloudflare-style approach).
• Use a credential broker on the machine where the server runs to inject credentials at the outbound boundary.
• Use a unified-OAuth-per-user platform like Composio that handles it as part of its hosted integration.

Different parts of the same problem. A real production setup ends up using two or three of these together: a gateway for routing-and-policy, a broker or unified-OAuth layer for credential injection, and a registry for discovery.

The shorter version

The MCP gateway category went from "doesn't exist" to "30 vendors compete for it" in nine months. Twelve are actually credible. Pick by deployment model first (self-host vs hosted), then by access-control granularity, then by whether you're already on a cloud platform whose gateway you can ride.

Three things to remember:

• Smithery is a registry, not a gateway. Don't compare them.
• Agent-side credential brokers (Authsome and peers) are a different layer. Use both, not either-or.
• The gateway only governs MCP traffic. The MCP server's own outbound auth to GitHub/Stripe/your-DB is a separate problem with separate solutions.

Priyansh Khodiyar

Maintainer

Works on authsome and the agentr.dev tooling.