As AI agents connect to more tools through the Model Context Protocol (MCP), managing each connection separately can become difficult. Different MCP servers may expose different tools, require different authentication, and introduce their own access controls and operational requirements.
An MCP gateway adds an intermediary layer between MCP clients and servers where teams can manage those connections more centrally. Depending on the product, a gateway can combine tools from multiple servers behind one endpoint, authenticate users or agents, control access to tools, apply policies, and provide visibility into tool calls.
That centralized layer becomes especially useful when agents move beyond simple implementations. Direct connections to a few MCP servers may be enough for some applications, while larger deployments may need more control over which tools users and agents can discover and invoke, how access is authorized, and how activity is monitored or audited.
There are several approaches to solving this problem. Some products are built specifically around MCP or agent traffic, while others extend API gateways, cloud platforms, or broader AI infrastructure to support MCP. Their governance models also differ, including where access policies are enforced and how precisely teams can control tool availability and invocation.
Rather than cataloging every MCP gateway available today, this guide focuses on nine platforms that represent different approaches to managing MCP connections. By the end of this roundup, you'll understand how various MCP gateways work, the architectural and governance differences between them, and which approach best fits your AI application.
What Is an MCP Gateway?
An MCP gateway is an intermediary between MCP clients and the systems they access through MCP. Instead of requiring a client to connect directly to every MCP server or backend service, the gateway provides a shared layer through which those interactions can pass.
When an agent calls a tool, the gateway can route the request to the appropriate destination and return the result to the client. Some gateways can also combine capabilities from multiple servers or services behind a single MCP endpoint, giving clients one place to discover and invoke tools that originate from different systems.
What happens between receiving and forwarding a request depends on the gateway. It may authenticate the user or agent, determine whether a particular tool can be called, apply policies to the request, or record information about the interaction. This is where governance becomes part of the architecture: controls can be applied at a shared layer rather than implemented separately for every connection.
MCP gateways also differ in what sits behind them. Some primarily proxy existing MCP servers. Others can expose APIs, functions, or other services through MCP, while broader AI and API gateways may manage MCP alongside additional types of traffic.
A gateway therefore does not replace the underlying systems that provide an agent's capabilities. Instead, it adds an intermediary layer for exposing, routing, securing, and operating access to them.
How to Evaluate MCP Gateways
The right MCP gateway depends on the systems your agents need to access, the level of control you need over those interactions, and how the gateway fits into your overall architecture.
When comparing platforms, consider the following factors:
MCP Federation and Tool Management
Start by looking at how the gateway connects to the systems your agents need. Some gateways primarily sit in front of existing MCP servers, while others can also expose APIs, functions, or other services through MCP.
If your application uses multiple servers, consider whether the gateway can combine their tools behind a shared endpoint and how those tools are organized. Teams should also verify how tools are registered, discovered, filtered, and updated as the systems behind the gateway change.
Authentication and Identity
Authentication establishes the identity associated with a request. Depending on the architecture, that identity may represent an end user, an agent, an application, or another service.
Look at which authentication methods the gateway supports and how identity information is used when access decisions are made. For applications serving multiple users or agents, verify whether the gateway can distinguish between those identities and apply the appropriate controls to each request.
Authorization and Governance
Once an identity has been established, the next question is what it is allowed to do. MCP gateways can differ substantially in both their authorization models and the granularity of the controls they provide.
Depending on the product, access may be controlled at the gateway, server, or tool level, with policies based on roles, identities, request context, or other attributes. Evaluate where authorization decisions are made, how policies are configured, and whether the available controls match the boundaries your application needs.
Governance can also include controls over which tools are exposed to particular clients, how credentials are managed, and what policies are applied before a request reaches its destination.
Observability and Auditability
Routing MCP traffic through a gateway can create a central place to collect information about those interactions, but the depth of visibility varies by product.
Evaluate what the gateway records about requests and tool calls, such as the associated identity, destination, outcome, or policy decision. For applications with compliance or internal oversight requirements, also verify which events are retained for auditing, how long records are stored, and how teams can access or export them.
Deployment and Operations
Finally, consider where the gateway runs and who is responsible for operating it. Available models include vendor-managed services, self-hosted software, and gateways integrated into broader cloud or application platforms.
The deployment model affects responsibilities such as networking, configuration, upgrades, scaling, and infrastructure management. Managed services can take on more of those operational tasks, while self-hosted deployments can give teams greater control over where and how the gateway runs. The right approach depends on your infrastructure, security requirements, and how much of the gateway lifecycle your team prefers to operate directly.
The 9 Best MCP Gateways
1. Arcade
Best for: Teams that want to federate MCP tools while centrally managing tool access and end-user authorization.
Arcade's MCP Gateways combine tools from multiple MCP servers into a single endpoint. Teams choose which tools appear in each gateway and can create different combinations for different agents, applications, or use cases. Gateways can include tools from MCP servers available within the same Arcade project, including registered remote servers.
Arcade provides several ways to authenticate the people accessing a gateway. Production applications can connect an existing OIDC identity provider through Arcade's User Sources, while Arcade Auth supports project members and Arcade Headers lets compatible clients pass an Arcade API key and end-user ID with each request. These options let teams associate gateway access with individual end users rather than treating every request as the same identity.
For tools that access third-party services on a user's behalf, Arcade can manage the OAuth authorization flow and token storage. Each tool specifies the scopes it requires, and Arcade checks whether the user has authorized those permissions when the tool runs. The resulting OAuth token is injected into the tool's execution context, so the MCP client and LLM do not receive it.
This creates governance at multiple points in the tool path. Teams can control which tools a gateway exposes, authenticate the end users accessing it, define the permissions required by individual tools, and keep third-party credentials outside the client and model.
Why You Might Choose Arcade
- Centralizes governance across MCP tools, identity, and authorization.
- Federates tools from multiple MCP servers behind a single gateway endpoint.
- Lets teams control which tools are exposed through each gateway.
- Supports end-user authentication through existing OIDC identity providers.
- Manages OAuth authorization and required scopes for tools acting on users' behalf.
- Keeps OAuth tokens out of the MCP client and LLM.
Additional Highlights
Arcade offers multiple deployment options, including Arcade Cloud, deployments in your own cloud account, and self-hosting on Kubernetes. This gives teams flexibility in where the platform runs as their infrastructure requirements evolve.
2. agentgateway
Best for: Teams that want an open-source gateway for governing MCP alongside other agent and AI traffic.
agentgateway is an open-source gateway built for agent connectivity. For MCP, it can connect to multiple tool servers and federate their tools behind a single endpoint. The same gateway also supports A2A and LLM traffic, giving teams a shared infrastructure layer for several types of agent communication.
Its governance controls extend to individual MCP capabilities. Teams can use CEL-based authorization rules to control access to tools, prompts, and resources, including policies based on JWT claims. When a capability is not authorized, agentgateway can filter it from list responses so the client does not see it.
For authentication, agentgateway supports MCP-specific OAuth 2.0 protection with JWT validation. Authentication information can then be used by authorization and other gateway policies, allowing access decisions to account for the identity associated with a request.
agentgateway also provides MCP observability through metrics, logs, and distributed traces. It can run as a standalone gateway or with Kubernetes, giving teams different ways to integrate it into their infrastructure.
Why You Might Choose agentgateway
- Provides governance controls for MCP tools, prompts, and resources.
- Federates tools from multiple MCP servers behind a single endpoint.
- Uses CEL-based policies for fine-grained authorization.
- Supports MCP authentication with OAuth 2.0 and JWT validation.
- Filters unauthorized capabilities from MCP list responses.
- Supports MCP, A2A, and LLM traffic through the same gateway.
Additional Highlights
agentgateway can run as a standalone binary or on Kubernetes. This gives teams flexibility in how they deploy and operate the gateway alongside their existing infrastructure.
3. Kong AI Gateway
Best for: Teams that want to extend API gateway-style governance and traffic management to MCP.
Kong AI Gateway extends Kong Gateway to support AI traffic, including MCP. Its AI MCP Proxy can sit in front of existing MCP servers, convert REST APIs into MCP tools, and aggregate tools behind an MCP endpoint.
For governance, Kong supports default and per-tool access control lists (ACLs). Teams can control which authenticated consumers or consumer groups can discover and invoke individual tools, and newer versions can also evaluate ACLs using claims from OAuth access tokens. Unauthorized tools can be filtered from discovery results rather than exposed to the client.
These controls work with Kong's broader authentication and traffic-management ecosystem. Authentication plugins such as Key Auth or OpenID Connect can establish consumer identity before MCP access rules are evaluated, while Kong can log both allowed and denied access attempts for auditing.
Kong also provides logging, tracing, and MCP traffic metrics through its gateway infrastructure. For teams already using Kong for APIs, this makes it possible to manage MCP traffic within the same broader gateway architecture.
Why You Might Choose Kong AI Gateway
- Applies governance controls to MCP tool discovery and invocation.
- Supports default and per-tool ACLs for fine-grained access control.
- Filters unauthorized tools from MCP discovery results.
- Proxies existing MCP servers through Kong Gateway.
- Converts REST APIs into MCP tools.
- Extends Kong's authentication, traffic management, and observability capabilities to MCP.
Additional Highlights
Kong's AI MCP Proxy supports both self-managed and Konnect deployments. This gives teams flexibility in how they add MCP support to their Kong infrastructure.
4. Amazon Bedrock AgentCore Gateway
Best for: Teams building on AWS that want a managed gateway with policy-based governance over agent tool access.
Amazon Bedrock AgentCore Gateway is a fully managed service for connecting agents to tools, other agents, HTTP services, and models. For MCP, it can aggregate capabilities from multiple MCP targets behind a single endpoint and expose APIs and Lambda functions as MCP-compatible tools.
The gateway separates inbound access from authentication to downstream targets. Teams can control who can invoke the gateway while configuring separate credentials for the services behind it, with supported methods varying by target type.
For governance, AgentCore Gateway integrates with Policy in AgentCore. Teams can write authorization rules in Cedar to control which tools a principal can invoke and apply conditions based on tool inputs. Policy enforcement happens at the gateway boundary before a tool call reaches its destination.
Policies also affect tool discovery. Callers only see tools they could be permitted to invoke, while individual calls are evaluated again using the full request context. Policy decisions are logged through Amazon CloudWatch for monitoring and auditing.
Why You Might Choose Amazon Bedrock AgentCore Gateway
- Provides policy-based governance for agent tool access.
- Uses Cedar policies for fine-grained authorization.
- Applies authorization policies to tool discovery and invocation.
- Aggregates capabilities from multiple MCP targets behind one endpoint.
- Exposes APIs and Lambda functions as MCP-compatible tools.
- Integrates with AWS identity, monitoring, and infrastructure services.
Additional Highlights
AgentCore Gateway can connect agents to both MCP tools and A2A services. This lets teams manage tool access and agent-to-agent traffic through the same gateway service.
5. Azure API Management
Best for: Teams that want to govern MCP servers using the same policy and access-management infrastructure they use for APIs.
Azure API Management can expose and govern existing remote MCP servers or expose operations from managed REST APIs as MCP tools. This lets teams make existing services available to agents while managing access through API Management.
Governance uses API Management's policy system. Teams can apply authentication and authorization controls, rate limits, quotas, and other policies to MCP servers, creating a central enforcement layer between MCP clients and the systems they access.
MCP servers can also be included in API Management products. Teams can use existing subscription, approval, policy assignment, and quota workflows to control how consumers receive and use access to MCP servers.
For existing remote MCP servers, API Management acts as a proxy between MCP clients and the external server. It currently supports tools and resources from these servers over Streamable HTTP or SSE, provided the server meets Microsoft's documented MCP compatibility requirements.
Why You Might Choose Azure API Management
- Provides centralized governance for MCP server access.
- Applies authentication, authorization, rate limits, and quotas through gateway policies.
- Exposes operations from existing REST APIs as MCP tools.
- Proxies and governs existing remote MCP servers.
- Uses API Management products for subscriptions, approvals, policies, and quotas.
- Brings MCP servers into existing API Management workflows.
Additional Highlights
Azure API Management supports programmatic MCP server management through REST APIs, ARM templates, Bicep, Azure CLI, and Terraform. This gives teams several ways to incorporate MCP configuration into infrastructure automation workflows.
6. TrueFoundry
Best for: Teams that want centralized MCP governance with fine-grained access controls, credential management, and guardrails.
TrueFoundry MCP Gateway provides a central layer for connecting AI applications to MCP servers. Teams can register public and self-hosted servers and create virtual MCP servers that combine selected tools from multiple sources into a single endpoint.
For governance, TrueFoundry supports RBAC and ABAC policies that control access to MCP servers and individual tools. Permissions can also distinguish between read and write operations, giving teams more granular control over what users and applications can do.
The gateway manages OAuth tokens for MCP servers on behalf of individual users. It securely stores and refreshes those tokens, allowing users to access authorized services without managing separate OAuth credentials for each connection.
TrueFoundry also supports guardrails before and after MCP tool calls. These can inspect tool inputs and outputs, block calls that violate configured policies, and work alongside request logging and audit trails for monitoring MCP activity.
Why You Might Choose TrueFoundry
- Centralizes governance across MCP servers and tools.
- Supports RBAC and ABAC for fine-grained access control.
- Manages user-specific OAuth tokens and automatic refreshes.
- Combines selected tools through virtual MCP servers.
- Applies guardrails before and after MCP tool calls.
- Provides request logging and audit trails for MCP activity.
Additional Highlights
TrueFoundry supports deployments in VPC, on-premises, air-gapped, and multi-cloud environments. This gives organizations flexibility in where they run the platform.
7. Traefik Hub MCP Gateway
Best for: Teams that want task-aware governance for MCP traffic within Traefik's gateway infrastructure.
Traefik Hub MCP Gateway adds a governance layer between MCP clients and servers. Currently available in Early Access, it acts as an OAuth-compliant gateway that can enforce centralized access controls over MCP tools and resources.
Governance centers on Task-Based Access Control (TBAC). Policies can account for the task being performed, the tool being called, and transaction-level details such as request parameters. This lets teams control not just whether an agent can use a tool, but what it can do with that tool.
Policies can also use JWT claims alongside MCP request data. Traefik can filter tools and resources from MCP list responses and separately evaluate requests when clients attempt to invoke or access them.
For operations, Traefik supports session affinity for stateful MCP sessions and provides MCP-specific OpenTelemetry-compatible metrics. Its broader gateway infrastructure also supports OpenTelemetry tracing.
Why You Might Choose Traefik Hub MCP Gateway
- Provides centralized governance for MCP tools and resources.
- Uses TBAC for task-, tool-, and transaction-aware authorization.
- Incorporates JWT claims and MCP request data into access policies.
- Filters MCP tools and resources based on configured policies.
- Supports session affinity for stateful MCP connections.
- Provides MCP-specific OpenTelemetry-compatible metrics.
Additional Highlights
Traefik Hub combines API Gateway, AI Gateway, and MCP Gateway capabilities within its broader gateway architecture. This gives teams multiple layers for governing application and AI traffic.
8. Docker MCP Gateway
Best for: Teams that want to run and govern MCP servers through Docker's container-based infrastructure.
Docker MCP Gateway is an open-source gateway that sits between MCP clients and servers. It manages server configuration, credentials, access control, routing, authentication, and server lifecycle through a central proxy.
The gateway runs MCP servers in isolated Docker containers with restrictions on privileges, network access, and resource usage. When a client invokes a tool, the gateway identifies the appropriate server, starts its container if needed, injects required credentials, applies security restrictions, and forwards the request.
For governance, profiles determine which MCP servers are available to different clients. Teams can also enable or disable individual tools within each profile, providing more granular control over the capabilities exposed to an AI application.
Docker MCP Gateway also includes logging and call tracing for visibility into tool activity. When used with MCP Toolkit, teams can manage servers, profiles, OAuth credentials, and client connections through Docker Desktop or the CLI.
Why You Might Choose Docker MCP Gateway
- Centralizes governance for MCP server access.
- Runs MCP servers in isolated Docker containers.
- Uses profiles to control which servers are available to clients.
- Lets teams enable or disable individual tools within profiles.
- Manages OAuth credentials through MCP Toolkit.
- Provides logging and call tracing for MCP activity.
Additional Highlights
Docker MCP Gateway can run through Docker Desktop or be installed separately for Docker Engine. This gives teams multiple ways to incorporate the gateway into Docker-based environments.
9. Solo Enterprise for kgateway
Best for: Kubernetes teams that want to manage MCP connectivity alongside application and agent traffic through a shared gateway architecture.
Solo Enterprise for kgateway is Solo.io's enterprise gateway built on the open-source kgateway project. Previously called Gloo Gateway, the product uses the Kubernetes Gateway API and can integrate with agentgateway to manage connectivity across MCP servers, A2A agents, and REST APIs.
The architecture separates the control plane from the gateway data plane. The control plane watches Kubernetes Gateway API and Solo resources, translates them into proxy configuration, and distributes that configuration to the gateways handling traffic.
For MCP and agent workloads, agentgateway provides the data plane with native support for MCP, A2A, HTTP, gRPC, and LLM traffic. MCP capabilities include proxying MCP traffic and creating virtual MCP servers that aggregate tools from multiple servers.
This architecture lets Kubernetes teams manage agent connectivity through declarative gateway resources rather than operating MCP as an entirely separate networking layer.
Why You Might Choose Solo Enterprise for kgateway
- Brings MCP connectivity into a Kubernetes-native gateway architecture.
- Integrates with agentgateway for MCP and A2A traffic.
- Uses the Kubernetes Gateway API as part of its configuration model.
- Separates gateway configuration and traffic handling across control and data planes.
- Supports virtual MCP servers that aggregate tools from multiple servers.
- Extends Kubernetes gateway infrastructure to AI and agent traffic.
Additional Highlights
Solo Enterprise for kgateway builds on the open-source kgateway project and extends it with enterprise capabilities. This lets teams use Kubernetes Gateway API resources while adding Solo's enterprise gateway functionality.
Which MCP Gateway Should You Choose?
Choose Arcade if...
You want an MCP gateway with governance centered on identity, authorization, and centralized control over how users and agents access tools.
Choose agentgateway if...
You want an agent-focused gateway for MCP, A2A, LLM, HTTP, and gRPC traffic that can run independently or within Kubernetes.
Choose Kong if...
You want to add MCP support to an existing Kong API and AI gateway architecture while applying gateway policies to MCP traffic.
Choose Amazon Bedrock AgentCore Gateway if...
You're building on AWS and want a managed gateway with policy-based governance for agent access to tools.
Choose Azure API Management if...
You want to expose and govern MCP servers using Azure API Management's existing policies, products, and access-management workflows.
Choose TrueFoundry if...
You want centralized MCP governance with fine-grained access controls, credential management, and guardrails around tool calls.
Choose Traefik Hub MCP Gateway if...
You want task-aware MCP governance that can incorporate identity, tools, and request details into authorization decisions.
Choose Docker MCP Gateway if...
You want to run MCP servers in isolated Docker containers while controlling which servers and tools are available to clients.
Choose Solo Enterprise for kgateway if...
You want to manage MCP and agent connectivity as part of a Kubernetes-native gateway architecture built around the Kubernetes Gateway API.
