An MCP gateway is the enforcement point between your AI agents and the MCP servers they call — the place where authentication, tool scoping, rate limits, logging, and content policy can be applied once instead of per server. As the MCP ecosystem has grown, so has the gateway market, and by 2026 the options fall into three distinct architectural families with different assumptions about what problem you are solving.

Two disclosures before the list. First, Praesidia — this site — is one of the entries; we include it because leaving it out would be stranger than disclosing it, and we hold it to the same standard as every other entry: public, verifiable claims only. Second, this space moves quickly — as of July 2026 the descriptions below reflect vendors' own public documentation and announcements, and you should verify current capabilities and pricing against their sites before shortlisting. For the capability checklist behind the comparison, see MCP Gateway: What to Look For.

The evaluation axes

Five questions separate the options more than any feature list:

  1. Authentication depth. Does it implement the November 2025 MCP authorization spec — OAuth 2.1 with PKCE, RFC 8707 resource-bound tokens, protected-resource metadata — or proxy simpler credentials? (Background: MCP OAuth 2.1 and PKCE explained.)
  2. Tool-level scoping. Can you allow-list which tools each caller may invoke on each server, or is access all-or-nothing per server?
  3. Content inspection. Are requests and responses inspected in-band (injection patterns, PII, exfiltration shapes), or does traffic pass through opaque?
  4. Audit quality. Are tool calls logged with caller identity, in a record you could hand an auditor — or application logs?
  5. Operational model. Self-hosted data plane, managed service, or both? Who patches it, and does it fit your residency requirements?

The options

Praesidia (disclosed: our product)

Praesidia is an AI agent governance control plane in which MCP gateway functionality is one layer: MCP servers register as first-class entities with their own credentials, connections carry per-caller tool scoping, guardrails inspect content bidirectionally in-band, budgets and rate limits apply per principal, and every tool call lands in an append-only, hash-chained audit log. The distinguishing choices: an open-source core under the Apache license, EU data residency, and a $0 free tier. The trade-off to weigh is scope: Praesidia assumes you want agent governance (identity, policy, audit, cost) as a whole, not a network proxy alone — if a standalone proxy is genuinely all you need, a full control plane is more platform than the problem requires. See registering and governing MCP servers for how the MCP layer works.

Docker MCP Toolkit and Catalog

Docker's MCP offering pairs a curated catalog of containerized MCP servers with a toolkit/gateway for running them locally under Docker's isolation model, per Docker's public documentation. Its center of gravity is the developer workstation: containerized servers, catalog-based discovery, and credential handling integrated with the Docker ecosystem. Teams already standardized on Docker tooling get a low-friction path to running vetted servers; organization-wide policy, cross-vendor identity, and compliance-grade audit are not its stated problem.

IBM ContextForge MCP Gateway

ContextForge is an open-source MCP gateway project originating at IBM that federates multiple MCP servers behind a single endpoint, with an admin surface for managing servers and tools, per its public repository. It is a fit for teams that want a self-hosted, code-first federation layer and are prepared to operate and extend an open-source project themselves — with the usual open-source trade: you own hardening, policy design, and the operational lifecycle.

Lasso Security MCP Gateway

Lasso Security, a GenAI-security vendor, publishes an open-source MCP gateway with a plugin architecture oriented toward security controls — its public repository describes sanitization plugins for secrets and sensitive data on MCP traffic. It is a natural evaluation candidate when your primary concern is content-level risk on the MCP path specifically; broader agent governance (identity, budgets, audit posture) sits outside the project's stated scope.

Kong AI Gateway

Kong extends its API-gateway platform with AI-specific capabilities, and its public documentation covers MCP traffic handling alongside LLM routing, credential management, and its established plugin ecosystem. The argument for it is consolidation: if Kong already fronts your APIs, extending existing operational muscle to MCP traffic is cheaper than adding a new system. Kong's documented approach to these concerns is plugin-based: per its public documentation, agent-specific constructs — per-agent identity, tool-level authorization, agent trust — are composed from plugins and adjacent tooling rather than shipping as single built-in primitives. Whether that composition model suits you is an architecture preference; the general pattern is discussed in AI control plane vs API gateway.

Solo.io agentgateway

Solo.io announced agentgateway as an open-source data plane purpose-built for agent connectivity, with public materials describing support for agent-to-agent and agent-to-MCP traffic. It comes from the service-mesh school: a high-performance proxy layer designed for platform teams building agent infrastructure on cloud-native primitives. As a data plane, it pairs naturally with — rather than replaces — a governance layer that decides the policy the data plane enforces.

LiteLLM

LiteLLM is a widely used open-source LLM gateway (unified API across model providers, keys, quotas) whose public documentation also covers MCP integration. Teams already running LiteLLM as their model gateway get MCP reach in tooling they know. Its public documentation centers on the model-call path — provider abstraction, key management, spend tracking per key; agent-level governance and audit are not its stated focus.

Cloudflare

Cloudflare's public platform documentation covers building and deploying remote MCP servers on Workers, plus an AI Gateway for model traffic. It is less a packaged "MCP gateway" than infrastructure primitives — attractive if you are building MCP services on Cloudflare's edge already, with governance semantics left to what you construct.

How to shortlist

Match the family to your primary problem:

  • "Developers keep wiring up random MCP servers" → start with the developer-tooling family (Docker) plus a vetting workflow — the risk is adoption hygiene before it is traffic policy.
  • "We have a gateway team and want one data plane" → evaluate Kong, Solo.io agentgateway, or LiteLLM depending on whether your center of gravity is APIs, cloud-native infrastructure, or model routing.
  • "We need MCP governed as part of agent governance overall — identity, policy, audit, cost" → evaluate control planes; that is the category Praesidia is in, and the honest comparison there is against building the governance layer yourself (see build vs buy).

Whatever the family, hold every candidate to the five axes above — and to the November 2025 authorization spec in particular, because auth built before it tends to need rework.

Common questions

What is an MCP gateway? An enforcement point between AI agents (and other MCP clients) and MCP servers, applying authentication, tool scoping, rate limits, logging, and content policy centrally instead of per server. Architecturally the options range from standalone proxies to layers within full agent-governance control planes.

Do I need an MCP gateway if my servers already implement OAuth? Spec-compliant auth on each server (OAuth 2.1, PKCE, resource-bound tokens) solves identity per server — it does not give you cross-server policy, per-caller tool allow-lists, unified audit, or one place to revoke a compromised agent's access everywhere. The gateway question is really the governance question: how many places do you want policy to live?

Are open-source options production-ready? Several projects above are used in production per their own communities, and open source has real advantages here (auditability of the enforcement path, no vendor lock on a security chokepoint). The honest trade is operational: you own hardening, upgrades, and incident response for the gateway itself. That calculus is the standard one, not MCP-specific.

Why is Praesidia in its own comparison list? Because publishing a category comparison and silently omitting ourselves would be less honest than disclosure. We flag the entry, keep its claims to what our public docs state, and note the genuine trade-off (control-plane scope versus standalone proxy). Verify us against our documentation exactly as you would any other entry.

How should we run the evaluation? Proof-of-concept against your own failure modes, not vendor demos: one agent, two MCP servers, and tests that should trip policy — an unapproved tool call, a response containing seeded sensitive data, a rate burst, a revoked credential. The RFP checklist has the fuller question set.