Best Open Source Agent Gateways for MCP and A2A in 2026

TL;DR

• MCP and A2A solve different problems: MCP connects an agent to tools and data, while A2A connects one agent to another agent.
• Bifrost is an Apache 2.0 AI gateway that governs LLM calls and MCP tool calls behind one set of virtual keys, adding 11 microseconds of overhead per request at 5,000 RPS.
• Native A2A mediation is published today by agentgateway and IBM ContextForge; Bifrost, Envoy AI Gateway, Docker MCP Gateway, and Microsoft MCP Gateway do not document A2A support.
• Kong's MCP and A2A proxy plugins ship only in its AI Gateway Enterprise offering, so Kong is excluded from this open source list.
• Choose by the hop you must govern first: model and tool traffic at enterprise scale, agent-to-agent traffic, Kubernetes-native Envoy routing, or local developer tooling.

Self-hosted AI agents generate three kinds of network traffic: calls to LLM providers, tool calls over the Model Context Protocol, and agent-to-agent calls over the A2A protocol, and support for MCP and A2A is now the main way open source gateways differ. Bifrost, the open-source AI gateway written in Go and built by Maxim AI, is the best choice for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability across LLM and MCP traffic. This guide compares six open source agent gateways on license, MCP and A2A coverage, governance, and deployment, and states plainly where each one, including Bifrost, stops.

MCP and A2A: What Each Protocol Governs in an Agent Stack

MCP and A2A are complementary open protocols. MCP standardizes how an agent discovers and calls tools, data sources, and APIs. A2A standardizes how one autonomous agent discovers another, delegates a task, and exchanges results. A production agent often uses both, so a gateway's protocol coverage decides which hops it can authenticate, scope, and log.

The Model Context Protocol specification defines JSON-RPC messages for listing and calling tools, reading resources, and fetching prompts over stdio or streamable HTTP. The Agent2Agent (A2A) Protocol defines agent cards for discovery and a task lifecycle for multi-turn collaboration between agents built on different frameworks. The A2A project's own guidance on how A2A and MCP fit together summarizes it this way: A2A connects agents to each other, and MCP connects each agent to its own tools.

An agent gateway sits between the agent and all three destinations, as Figure 1 shows. The LLM hop carries the most volume, the MCP hop the most risk, and the A2A hop matters once agents from different teams call each other. For a deeper look at the MCP side alone, see how an MCP gateway centralizes tool access and policy.

Figure 1: MCP and A2A govern different hops, so a gateway's protocol coverage decides which hops it can control.

How We Evaluated Open Source Agent Gateways

Each gateway was scored on five criteria: an OSI-approved license with MCP support in the public repository, depth of MCP governance, published A2A support, LLM routing in the same process, and self-hosted deployment options. Every claim below comes from the project's own README or documentation, and any capability a project does not document is marked "Not published."

MCP governance was weighted most heavily because tools can modify production systems. Figure 2 shows the four control points a gateway can apply to a single tool call; a gateway that skips one of them leaves that part of the path ungoverned. This framework matches the questions in the Bifrost LLM Gateway Buyer's Guide, extended to cover A2A.

Figure 2: The evaluation criteria map to these four control points; a gateway missing one leaves that hop ungoverned.

Open Source Agent Gateways Compared at a Glance

The six gateways below all publish MCP support under an OSI license. Only two of them document native A2A support today. Bifrost, agentgateway, and Envoy AI Gateway combine LLM routing and MCP governance in one process, and the Bifrost AI gateway publishes sustained-load overhead figures of 11 microseconds at 5,000 RPS.

1. Bifrost

Bifrost, the open source AI gateway, acts as both an MCP client and an MCP server, so one deployment routes model calls to 25+ providers and 10,000+ models and governs every tool call an agent makes. Bifrost adds 11 microseconds of overhead per request at 5,000 RPS with a 100% success rate in sustained benchmarks.

Best for: Bifrost is built for enterprises running mission-critical AI workloads that require best-in-class performance, scalability, and reliability. It serves as a centralized AI gateway to route, govern, and secure all AI traffic across models and environments with ultra low latency. Bifrost unifies LLM gateway, MCP gateway, and Agents gateway capabilities into a single platform. Designed for regulated industries and strict enterprise requirements, it supports air-gapped deployments, VPC isolation, and on-prem infrastructure. It provides full control over data, access, and execution, along with robust security, policy enforcement, and governance capabilities.

As Figure 3 shows, Bifrost exposes two front doors, an OpenAI-compatible LLM endpoint and an MCP endpoint, and both resolve to the same virtual keys. A virtual key carries a budget, rate limits, and an MCP tool allow-list, so the identity that limits a team's model spend also limits which tools that team's agents can call.

Figure 3: One identity, the virtual key, governs both the model a request can use and the tools it can call.

MCP capabilities

• MCP client and server: Bifrost connects to upstream MCP servers over STDIO, HTTP, or SSE and re-exposes the aggregated tools at a single /mcp endpoint for Claude Code, Cursor, and other MCP clients.
• Virtual MCPs: Virtual MCPs bundle a curated subset of tools from several servers behind an immutable /mcp/<slug> URL that only attached virtual keys can reach. The feature is part of open source Bifrost.
• Deny-by-default tool scoping: With MCP tool filtering, a virtual key with no MCP configuration sees no tools, and request headers can only narrow the key's allow-list, never widen it.
• Inbound and upstream auth: Clients authenticate to /mcp with header credentials or OAuth 2.1, where Bifrost acts as the authorization server with dynamic client registration and PKCE, as described in the gateway authentication docs. Upstream, Bifrost supports shared and per-user credentials, including per-user OAuth and enterprise token exchange.
• Explicit execution by default: Tool calls returned by a model are suggestions until the application executes them. Agent Mode enables auto-execution only for tools an operator marks as auto-executable.
• Code Mode: Code Mode replaces hundreds of tool definitions with four meta-tools and lets the model orchestrate tools in a sandbox. In a 508-tool, 16-server benchmark it cut input tokens by 92.8% and estimated cost by 92.2%; the Code Mode explainer walks through how.

Self-hosting and enterprise controls

Bifrost starts with npx -y @maximhq/bifrost or docker run -p 8080:8080 maximhq/bifrost, following the gateway setup guide, and documents a Kubernetes deployment.

For regulated teams, Bifrost Enterprise adds clustering with gossip-based sync, in-VPC deployments, SSO, RBAC, and HMAC-signed audit logs of administrative activity.

Where Bifrost stops: A2A

A2A is not part of Bifrost's documented feature set today. Bifrost governs the agent-to-model and agent-to-tool hops; teams that need a gateway to discover and route agent-to-agent tasks now should pair Bifrost with a gateway from this list that documents A2A, or keep A2A traffic on its existing path. The MCP gateway resource page tracks what Bifrost covers for agent traffic.

2. agentgateway

agentgateway is an Apache 2.0 proxy built around MCP and A2A, now hosted by the Linux Foundation, with contributors listed on its site including Solo.io, Microsoft, AWS, and Cisco. agentgateway documents native A2A mediation alongside MCP and LLM traffic in one data plane.

Best for: Platform teams on Kubernetes that want one proxy for LLM, MCP, and A2A traffic and are comfortable configuring policy in YAML and CEL.

• LLM gateway: An OpenAI-compatible API with budget and spend controls, load balancing, and failover across major providers.
• MCP gateway: Tool federation over stdio, HTTP, SSE, and streamable HTTP, plus OpenAPI integration and OAuth.
• A2A gateway: Agent-to-agent communication with capability discovery, modality negotiation, and task collaboration.
• Security: JWT, API key, and OAuth auth, RBAC through a CEL policy engine, rate limiting, TLS, and OpenTelemetry.
• Deployment: A standalone binary driven by flat YAML, or a Kubernetes controller using the Gateway API.

Teams comparing agentgateway with other self-hosted options can review the field of open source AI gateways for self-hosted deployment.

3. IBM ContextForge MCP Gateway

IBM ContextForge is an Apache 2.0 registry and proxy that federates MCP servers, A2A agents, and REST or gRPC APIs into one endpoint. ContextForge fits teams whose main task is exposing existing internal APIs as MCP tools while also registering external agents.

Best for: Teams with many internal REST or gRPC services that need to be exposed to agents as MCP tools, with a registry and admin UI on top.

• Federation and virtual servers: Tools from several MCP servers and REST services can be bundled into a virtual server with its own endpoint.
• Protocol translation: REST-to-MCP adapters and gRPC-to-MCP translation through server reflection.
• A2A integration: External agents (OpenAI, Anthropic, or custom) can be registered and routed through the gateway.
• Transports: HTTP, JSON-RPC, WebSocket, SSE, and streamable HTTP, with stdio for server-side use.
• Extensibility and observability: More than 40 plugins, plus OpenTelemetry tracing to Phoenix, Jaeger, Zipkin, and other OTLP backends.

ContextForge is written in Python (3.11 or later) and deploys from PyPI, Docker, or Helm, with PostgreSQL and Redis for multi-replica, multi-cluster setups. The IBM MCP gateway requires JWT_SECRET_KEY and AUTH_ENCRYPTION_SECRET in every environment, including local development. For context on where a registry-style gateway differs from a plain MCP proxy, see MCP proxy vs MCP gateway.

4. Envoy AI Gateway

Envoy AI Gateway is an Apache 2.0 control plane for AI traffic built on Envoy Proxy and Envoy Gateway. The project has been renamed Agent Router and moved to the Agentic AI Foundation, but its CRDs, Helm charts, and container images keep their original names. It fits teams already running Envoy on Kubernetes.

Best for: Kubernetes platform teams that already operate Envoy Gateway and want LLM and MCP routing expressed as Gateway API resources.

• MCPRoute API: Aggregates multiple MCP servers behind one endpoint, with tool names prefixed by backend (for example github__issue_read).
• Authorization: OAuth flows plus fine-grained access control using JWT claims, scopes, and CEL expressions.
• Upstream auth and filtering: API key and header injection to external MCP servers, and tool filtering per route.
• Spec coverage: Streamable HTTP and the June 2025 MCP specification, including notifications, prompts, resources, and server-to-client requests.

The project does not document A2A support. Teams weighing Envoy AI Gateway against a lighter single-binary option can compare Envoy AI Gateway alternatives.

5. Docker MCP Gateway

Docker MCP Gateway is an MIT-licensed Docker CLI plugin (docker mcp) that runs each MCP server in an isolated container and exposes them through one gateway. Docker MCP Gateway powers the MCP Toolkit in Docker Desktop and also runs independently on Docker CE.

Best for: Developers who want to run many MCP servers on one machine with container isolation and shared configuration across VS Code, Cursor, and Claude Desktop.

• Container isolation: Each catalog server runs in its own container, and npx and uvx servers get minimal host privileges.
• Secrets and OAuth: Credentials stay in Docker Desktop's secrets store instead of environment variables, with built-in OAuth flows.
• Catalogs and profiles: Servers are grouped into profiles that can be connected to clients and shared through OCI registries.
• Discovery and tracing: Dynamic tool discovery, plus logging and call tracing.

The Docker MCP Gateway documents no A2A support and no LLM routing, and it has no per-team budgets or virtual keys. It is a developer-workstation tool; see the open source MCP gateways for self-hosted AI infrastructure roundup for server-side options.

6. Microsoft MCP Gateway

Microsoft MCP Gateway is an MIT-licensed reverse proxy and management layer for MCP servers running in Kubernetes. The Microsoft MCP gateway separates a data plane that routes MCP traffic with session affinity from a control plane that deploys, updates, and deletes MCP servers.

Best for: Azure and Kubernetes teams that want a control plane API for the MCP server lifecycle, not only a proxy in front of servers they already run.

• Session-aware routing: Requests carrying the same session_id always reach the same MCP server instance.
• Adapter and tool APIs: REST endpoints to deploy, inspect, log, update, and remove MCP servers and registered tools.
• Tool gateway router: An MCP server that routes tool execution to the right registered tool server.
• Access control: Bearer token and RBAC on both the data plane and the control plane.
• Agents preview: Optional, opt-in agent and session resources that run LLM-driven agents over registered tools.

Microsoft MCP Gateway documents no A2A support. It offers one-click deployment to Azure alongside local Kubernetes deployment. Teams that need to compare how gateways handle MCP authentication for enterprise deployments should weigh its bearer-token model against OAuth-based designs.

How to Choose an Agent Gateway for MCP and A2A

Choose by the hop you must govern first. If model spend and tool access are the immediate risk, pick a gateway that governs LLM and MCP traffic under one identity. If agents from different teams already call each other, pick one that documents A2A. If Envoy or a developer laptop defines your platform, choose the tool built for it.

Figure 4 maps these needs to the gateways in this list.

Figure 4: Start from the traffic you must govern this quarter, then check which gateway covers that hop natively.

For most teams, governance of model and tool traffic, including budgets and rate limits, delivers value before A2A mediation does. Running two gateways is also a valid design: Bifrost for LLM and MCP governance, with an A2A-capable gateway on the agent-to-agent path, keeps each tool on the hop it documents. The Bifrost governance overview covers how keys, teams, and customers nest.

Why Kong Gateway OSS is not on this list

Kong offers an AI MCP Proxy plugin and an AI A2A Proxy plugin, but Kong's documentation lists both as available only in its AI Gateway Enterprise offering. Teams evaluating Kong for these protocols should budget for that tier, or compare Bifrost against other gateway alternatives that ship MCP governance in open source.

Frequently Asked Questions

What is A2A?

A2A, the Agent2Agent protocol, is an open standard for communication between AI agents built on different frameworks and by different vendors. An agent publishes an agent card describing its skills, and other agents use it to discover the agent, send tasks, and receive streamed or asynchronous results. The A2A project has joined the Agentic AI Foundation, which also hosts other open agent infrastructure projects.

What is the difference between MCP and A2A?

MCP connects an agent to tools, data sources, and APIs with structured inputs and outputs. A2A connects an agent to other autonomous agents that plan, hold state, and run multi-turn tasks. The two are complementary: an agent can receive a task over A2A and complete it by calling tools over MCP, and a gateway may govern either hop, both, or neither.

Does Bifrost support A2A?

A2A is not part of Bifrost's documented feature set today. Bifrost governs LLM traffic to 25+ providers and MCP traffic as both an MCP client and server, with virtual MCP endpoints and per-key tool scoping. Teams that need A2A mediation now can run an A2A-capable gateway such as agentgateway on the agent-to-agent path alongside Bifrost.

Which open source agent gateways support both MCP and A2A?

Among the gateways reviewed here, agentgateway and IBM ContextForge document native support for both MCP and A2A. agentgateway also includes an LLM gateway, while ContextForge adds REST and gRPC translation. Envoy AI Gateway, Docker MCP Gateway, Microsoft MCP Gateway, and Bifrost document MCP support without A2A.

Is agentgateway open source?

Yes. agentgateway is released under the Apache 2.0 license and is hosted by the Linux Foundation. It runs as a standalone binary configured with YAML or as a Kubernetes controller using the Gateway API, and it covers LLM, MCP, and A2A traffic in one proxy.

Can I self-host an MCP gateway on Kubernetes?

Yes. Bifrost, agentgateway, IBM ContextForge, Envoy AI Gateway, and Microsoft MCP Gateway all document Kubernetes deployment. Bifrost provides a Kubernetes guide plus enterprise clustering and in-VPC options, and it also runs as a single Docker container or npx binary for smaller setups.

Try Bifrost for Governed Agent Traffic

Governing MCP and A2A traffic starts with the hops agents use most: model calls and tool calls. Bifrost governs both behind one set of virtual keys, with 11 microseconds of overhead at 5,000 RPS, virtual MCP endpoints, Code Mode, and OAuth 2.1 for MCP clients, and it deploys inside your own network. For a closer look at MCP access control and token savings, read the Bifrost MCP gateway benchmark writeup or the guide to how an MCP gateway works. To see Bifrost run as the open source AI gateway for your agents, book a demo with the Bifrost team.