MCP Gateway Comparison 2026: Open-Source, AWS, Azure, Docker and Kong Options

MCP gateway vs MCP server: what each layer does

The Model Context Protocol connects AI clients to tools through servers. Each server wraps one system, so twenty systems mean twenty servers, each with its own credentials and its own idea of who may call it. A gateway puts one policy point in front of all of them. Our explainer on how MCP works covers the protocol itself; this page compares the layer in front of it.

A tool call through a gateway usually follows five steps:

1. The agent’s MCP client connects to the gateway endpoint and presents a token from your identity provider.
2. The gateway validates the token and maps the caller to a user, team, role or group.
3. On tools/list, it returns only the tools that identity may use, often merged from several upstream servers.
4. On tools/call, it checks policy for that tool and its arguments, applies rate limits, then calls the upstream server with a credential meant for that server.
5. It records the caller, the tool, the arguments and the outcome, and returns the result.

What the MCP specification expects from a gateway

The current protocol revision, 2026-07-28, sets rules that decide how a gateway must behave (verified October 2026):

• Authorization covers HTTP transports. Servers on stdio read credentials from their environment instead, so a gateway that fronts local stdio servers owns authentication for them.
• Protected servers are OAuth resource servers. The model builds on OAuth 2.1, and servers must publish Protected Resource Metadata (RFC 9728) so clients can find the authorization server; a gateway facing clients takes on that role.
• No token passthrough. Servers must validate that a token was issued for them as the intended audience, and must not accept or transit any other token.
• Consent before proxying. The security best-practices page requires MCP proxy servers that use a static client ID with a third-party authorization server to implement per-client consent, which blocks confused-deputy attacks.
• No protocol-level sessions. The revision describes MCP as stateless, with explicit state handles that must never count as authentication, so ask any gateway built around session affinity which protocol versions it supports.
• Client registration is changing. Dynamic client registration is deprecated in favour of OAuth Client ID Metadata Documents and kept only for backwards compatibility.

These rules shape the criteria in the tables below: hosting, authentication in both directions, tool-level allowlists, logging and rate limits.

MCP gateways compared at a glance

Every row comes from the vendor’s documentation or repository, checked in October 2026. A dash marks a feature those pages did not document, which is not proof that it is missing.

Hosting, licence and authentication

Tool control, audit and rate limits

Open-source MCP gateways you can self-host

Docker MCP Gateway

Docker describes its gateway as an open-source proxy between clients and servers that manages configuration, credentials and access control. Every server runs in its own container with restricted privileges, network access and resource usage. It starts automatically with Docker Desktop’s MCP Toolkit and can be installed separately on Docker Engine. Profiles decide which servers a gateway exposes, and single tools can be switched on or off per profile. The repository is MIT licensed, and Docker’s documentation adds that running the gateway as part of Docker AI Governance is an invite-only feature.

IBM ContextForge

ContextForge, from IBM, is a registry and proxy that federates MCP, A2A and REST or gRPC APIs behind one endpoint. Virtual servers let an administrator bundle a curated set of tools from several upstream sources, and the gateway adds RBAC, teams, rate limiting at gateway and tool level, OpenTelemetry tracing and an admin UI. Its configuration reference covers SSO with GitHub, Google, IBM Security Verify, Entra ID, Okta, Keycloak and generic OIDC. It installs from PyPI, as containers or with Helm under Apache 2.0, and release v1.0.11 shipped on 28 September 2026.

Microsoft MCP Gateway

Microsoft’s open-source MCP Gateway, MIT licensed, is a reverse proxy and management layer for MCP servers running in Kubernetes. A control plane deploys, updates and removes server instances, a data plane routes requests to them with session-aware routing, and a tool router sends tool calls to the right server based on registered definitions. Callers present Entra ID bearer tokens, and roles such as mcp.admin and mcp.engineer decide who may manage or read resources. Telemetry goes to Application Insights, and the repository labels its sessions and agents subsystem preview and single-replica.

agentgateway

agentgateway is a Rust proxy for MCP, agent-to-agent and model traffic that Solo.io donated to the Linux Foundation, licensed Apache 2.0. On the MCP side it federates several servers, speaks stdio, SSE and Streamable HTTP, turns OpenAPI services into tools, and decides through CEL policies which tools on which targets each caller may reach. JWT, API key and OAuth authentication, local and global rate limits and OpenTelemetry output are built in, and it runs as a single binary or on Kubernetes with its own controller.

Obot

Obot, MIT licensed, now presents itself as an AI governance platform: an MCP gateway, MCP server hosting, a registry of approved servers and skills, and an LLM gateway. Administrators set server and tool access per user or identity-provider group, manage MCP OAuth and shared credentials, and inspect, reject or modify traffic with MCP or webhook filters, with requests and responses recorded for audit. The default edition allows up to 100 users and devices with local, GitHub and Google sign-in. Entra, Okta, JumpCloud and Auth0 need a free Community registration or an Enterprise licence, and Enterprise lifts the user cap.

Lasso MCP Gateway

Lasso Security’s gateway is a smaller, plugin-based proxy under MIT that starts the servers listed in an mcp.json file and inspects their traffic. A basic plugin masks secrets such as GitHub and AWS tokens, a Presidio plugin anonymises personal data, and a security scanner rates server reputation and tool descriptions and can block risky servers automatically. A Lasso plugin adds prompt-injection detection. The README does not document how callers authenticate, so treat it as a guardrail layer for developer setups rather than an identity-aware enterprise gateway.

Managed MCP gateways on AWS, Azure, Cloudflare and Kong

Amazon Bedrock AgentCore Gateway

AWS positions AgentCore Gateway as a fully managed entry point for agent traffic. It converts APIs, Lambda functions and services into MCP tools from OpenAPI, Smithy or Lambda definitions, fronts other agents through passthrough targets, and also routes inference across model providers. It manages inbound authentication through OAuth or IAM and outbound credentials per tool, and semantic tool search lets an agent pick from thousands of tools without listing them all. Interceptors give control at gateway, tool, operation and parameter level, and Policy in AgentCore checks each tool call against Cedar policies, which can be drafted in plain English, logging every decision in CloudWatch.

Azure API Management

For Azure estates the MCP gateway is API Management. Microsoft Learn, updated 11 September 2026, documents two routes: expose a REST API managed in API Management as an MCP server, or put an existing remote MCP server behind it. Governance uses ordinary policies, such as JWT validation against Entra ID or another identity provider, rate limits, quotas and IP filtering, with monitoring through Azure Monitor and Application Insights. It is available on the classic and v2 tiers, and the self-hosted gateway can manage MCP servers inside your own infrastructure. Note the limits: tools are supported but resources and prompts are not, workspaces are excluded, and a policy covers every tool on a server.

Cloudflare MCP server portals

Cloudflare’s MCP server portals, part of Cloudflare One, put several MCP servers behind one HTTP endpoint. Users sign in through Cloudflare Access with your identity provider and authenticate separately to each upstream server that requires OAuth. Administrators choose which tools and prompt templates each portal exposes, including an allowlist mode in which everything stays hidden until switched on. Access logs individual tool requests, portal traffic can flow through Gateway HTTP logs, and a DLP policy can stop a tool call that matches a sensitive-data profile (documentation updated 24 September 2026).

Kong AI Gateway

Kong handles MCP through two plugins that need Kong Gateway 3.12 or later and belong to the AI Gateway Enterprise offering. AI MCP Proxy bridges MCP and HTTP in four modes, from plain passthrough to converting REST endpoints into MCP tools, with ACLs that decide which consumers can discover and call each tool. AI MCP OAuth2 validates MCP access tokens by introspection or JWKS and, by default, does not forward them to upstream services. Rate limiting, logging and tracing reuse Kong’s standard plugins.

Registries are not gateways

Searches for an “MCP gateway registry” usually mix two components. The official MCP Registry, still in preview in October 2026, stores metadata about publicly accessible servers, verifies namespaces through GitHub or DNS and HTTP challenges, and leaves security scanning to package registries and downstream aggregators. It does not accept private servers: its documentation recommends hosting your own private registry for those, and says the official codebase is not designed for self-hosting.

Private registries decide what people can find and install. Azure API Center plays that role for Azure estates, and GitHub lets enterprises set a “Registry only” policy for Copilot clients. GitHub’s own documentation states that this enforcement relies on server name or ID matching that can be bypassed by editing configuration files, that the feature is in public preview, and that it is not the recommended way to restrict MCP access.

So a registry publishes the approved list and a gateway enforces it on every call. What deserves approval in the first place is covered in our vetted list of enterprise MCP servers.

How to choose an MCP gateway

1. Decide where tool servers must run. If tools reach systems that may not be exposed to a vendor network, rule out managed portals. Inside an air-gapped estate a self-hosted gateway is the only option.
2. Trace the identity path. Check how callers authenticate to the gateway, how the gateway authenticates to each server, and that user tokens are never passed through.
3. Insist on tool-level allowlists. Approving a server should not approve every tool on it.
4. Treat writes differently from reads. A tool that writes, deletes or sends should be able to require approval.
5. Read a sample audit record. It should name the caller, agent, tool, arguments and outcome, and export to your SIEM.
6. Limit rates per caller. A runaway agent loop should hit the gateway’s limit before it reaches your ticketing system.
7. Confirm protocol coverage. Ask which MCP versions are supported, and whether resources and prompts pass through or only tools.
8. Read the edition labels. Several open-source projects keep identity providers, MCP plugins or user counts in paid tiers.
9. Control outbound traffic. Pair the gateway with egress controls so tool servers cannot reach arbitrary hosts.

Proxies for model traffic, several of which also add MCP features, are covered in our AI gateway comparison.

How VDF AI fits

VDF AI’s MCP gateway is part of the platform rather than a standalone proxy. It holds an administrator-governed tool registry in which tools are granted per role, so an agent can call only what its role holds and revoking a grant is a single registry change. Role-based access control, including per-role tool grants, is part of every plan.

The MCP server layer runs inside your perimeter, on-premises, in a private cloud or air-gapped, and exposes systems such as Jira, GitHub, GitBook, Slack and your own APIs as tools. Internal services become MCP endpoints through an approval step. Each invocation is recorded with the agent, the role, the tool and its parameters, next to the model decision that led to it, and actions that write can require approval.

The registry governs what VDF AI Agents may call. Connections your teams make from other MCP clients to vendor-hosted servers sit outside it, so one of the gateways above may still be needed for those. The hands-on MCP lesson walks through connecting an agent to tools.

Sources

• MCP authorization, 2026-07-28
• MCP security best practices, 2026-07-28
• About the MCP Registry
• MCP Registry repository
• Docker MCP Gateway documentation
• Docker MCP Gateway repository
• ContextForge repository
• ContextForge documentation
• ContextForge configuration reference
• ContextForge releases
• Microsoft MCP Gateway repository
• agentgateway repository
• agentgateway project site
• Obot repository
• Obot documentation
• Obot editions
• Lasso MCP Gateway repository
• Amazon Bedrock AgentCore Gateway
• AgentCore Gateway features
• AgentCore Gateway fine-grained access control
• Policy in Amazon Bedrock AgentCore
• MCP servers in Azure API Management
• Cloudflare MCP server portals
• Kong AI MCP Proxy plugin
• Kong AI MCP OAuth2 plugin
• GitHub MCP allowlist enforcement