Compare MCP gateways

The MCP-gateway space is crowded and growing fast — the e2b-dev/awesome-mcp-gateways catalog alone lists 21 open-source and 23 commercial entries as of April 2026, and that list isn’t exhaustive. The pages below are fact-checked side-by-sides against the closest neighbors, so you can spot the actual trade-offs and pick what fits your team.

Each page is fact-checked against the competitor’s current public docs. When the other tool is better at something, we say so. When we’re better, we say that too, with sources. The pages are dated so you can tell whether they’re stale.

All four side by side

A compact overview of the four neighbours we’ve compared in detail. For nuance, the full comparison page is one click away.

mcpgate Obot Docker MCPG IBM ContextForge MintMCP
Strongest at All-in-one for SMB — PII + per-user hooks built-in Bundled chat UI + agent platform Workstation-native (Docker Desktop, CLI) Multi-cluster federation Fully-managed cloud, SOC 2 Type II
License BSL 1.1 (converts to Apache 2.0 after 3 years) MIT MIT Apache 2.0 Proprietary
Stage of life Early stage — public since March 2026 Established OSS Established (Docker-org maintained) Established (IBM-backed) Proprietary platform
Self-host default from free tier default CLI plugin, local-first default Enterprise tier only
Managed cloud trial available default model
PII pseudonymization with rehydration built-in build it on top out of scope build it on top “detection” only (per marketing)
User-level policy hooks YAML, hot-reloaded operator RBAC only profile allowlists, no per-user JWT scopes (operator) RBAC (granularity not public)
Built for SMB teams Agent-building dev teams Developer workstations Enterprise multi-cluster Enterprise SaaS buyers
Import path for everything else OpenAPI Import, MCP Import, YAML extensions YAML extensions Docker Hub catalog Federation (MCP, A2A, REST, gRPC) Managed MCP wrap
OIDC SSO Any OIDC provider — Google, Microsoft Entra, Okta, Keycloak, Auth0, … Google + GitHub (free); Microsoft Entra + Okta (Enterprise) No multi-user SSO model JWT-based OAuth/SSO (providers not public)
Deployment surface Docker Compose Docker + Helm Docker CLI / Docker Desktop Docker, Helm, multi-cloud Cloud + self-host (top tier)
Pricing Freemium free OSS; Enterprise custom free (open source) free (open source) sales-conversation gated

Figures verified 2026-05-17. Star counts via api.github.com; feature claims sourced from each project’s public docs / README / marketing site. The ❌-shaped cells under PII / hooks are about what each project ships out of the box, not architectural ceiling — the OSS projects can be extended to reach the same surface with engineering investment. The individual pages spell out what that means in practice for each one.

To match this stack on another base, you’d add:

Obot + DIY

PII pseudonymization with on-prem rehydration, per-user YAML hook engine, 22 deep service integrations, ongoing MCP-spec keep-up. You keep an OSI-OSS license; you pay engineering hours.

Docker MCPG + a team gateway

Different paradigm — Docker MCPG is a developer-workstation CLI plugin. You’d add a production gateway under OIDC SSO with PII + hooks on top. Most teams end up running both side by side, not picking one.

IBM ContextForge + integration layer

Different shape — ContextForge handles multi-cluster federation; mcpgate-equivalent would sit inside each cluster as the privacy + deep-integration layer. Realistic to run both together.

MintMCP — not in scope

Proprietary platform; you can’t extend the gateway. The question becomes accept the managed model and the vendor lock-in, or migrate to one of the self-hosted options above.

Each stack reaches a similar surface. The differences are who does the engineering, how visible the code stays, and what license terms govern the final product.

Read the deep dives

Coming next

These are on the work-list. Want one prioritized? Tell us.

How we write these

  1. Sources before claims. Every line in the comparison tables references either the competitor’s public docs, their GitHub repo, or a feature we built and can demonstrate. If we can’t source it, we leave it out.
  2. Equal weight, both directions. “Where they’re better” gets the same length as “where we’re better”. If one of those sections feels suspiciously short, we go back and look harder.
  3. Tradeoffs named explicitly. Each page has a “Tradeoffs” section calling out where mcpgate is structurally weaker — license model (BSL 1.1 vs. OSI-OSS), stage-of-life vs. older projects, RBAC shape, missing Helm chart, etc. No marketing copy.
  4. Last-reviewed date prominent. Comparisons go stale; we date them so you can tell.