Search for the best MCP gateways, and most page-one results are vendors ranking their own product. TrueFoundry publishes a gateway ranking, Composio publishes one, and Obot publishes one.
I built this comparison from three evidence layers. Official documentation, Reddit reports (excluding disclosed vendor accounts and my own comments), and hands-on evaluations against a reusable gateway for an API-backed multitenant B2B application.
An MCP gateway is the control point between an agent client and one or more MCP servers. It can aggregate tools, authenticate connections, enforce policy, and record traffic.
That definition covers a wide range of products, from Docker’s local container gateway to enterprise control planes and integration runtimes. Treating them as interchangeable is the first mistake most comparisons make.
Disclosure: My company, Zenith, provides content marketing services to Arcade.dev and previously worked with Composio. The testing and conclusions in this article are my own.
TL;DR: Best MCP gateways by use case
Best for custom, multi-user B2B gateways: Arcade.dev. It was the only product in my ten-product evaluation that completed the target architecture, accepted a custom MCP server, and connected successfully from Claude Code within 60 minutes.
Best-supported local option based on independent evidence: Docker MCP Gateway. Has the most user reports on local MCP management, with strengths in container isolation and multi-client convenience, and clear limits outside Docker Desktop.
Best fit for existing AWS estates: Amazon Bedrock AgentCore. It brings Lambda functions, APIs, and remote MCP servers into the same IAM, CloudTrail, and CloudWatch control plane teams already operate.
Best when source availability is mandatory for downstream OAuth: Nango. It handles provider OAuth, token refresh, and credential storage, but assumes inbound authorization and gateway policy exist elsewhere. Arcade covered the complete multitenant MCP path in the hands-on test.
Best fit for existing Kong deployments: Kong AI Gateway. Relevant when an organization already operates Kong’s licensed data plane. Too complex for a greenfield MCP-only deployment.
MCP gateway comparison: strengths, complaints, and test results
This comparison covers production-oriented, multi-user gateways that can expose custom applications and tools through MCP. I also included products built for narrower roles, like local development, downstream OAuth, integration catalogs, or security overlays, evaluating each of those against that standard rather than the full gateway job.
MCP gateway categories
These products serve different architectural roles, and lumping them together as direct competitors is misleading.
Application and authorization gateways. Arcade, Obot, IBM ContextForge, Amazon Bedrock AgentCore, TrueFoundry, MintMCP. These sit between MCP clients and servers, handling authentication, authorization, policy, and tool management.
Local MCP management. Docker MCP Gateway, Lunar MCPX. Focused on managing MCP servers on a developer workstation or local environment.
Integration and downstream-auth infrastructure. Composio, Nango, Merge. These handle connections to third-party services, OAuth token management, and integration catalogs.
Existing gateway extensions. Kong AI Gateway. MCP support added to an established enterprise API gateway platform.
How this MCP gateway comparison was researched
Corpus: Research covering more than 300 relevant Reddit posts and comments.
Period: September 2024 through July 21, 2026. Hands-on testing took place July 20 and 21, 2026.
Sources: Reddit communities focused on MCP, LLM development, self-hosting, systems administration, SaaS, AWS, and Terraform.
Searches: Each product was paired with terms covering OAuth, production use, self-hosting, pricing, outages, migration, security, policy, observability, alternatives, and reviews.
Evidence weighting: I weighted technical claims by specificity, repetition, freshness, and agreement with documentation or testing. I didn’t treat disclosed vendor accounts or my own comments as independent user evidence.
Version handling: I’ve labeled older reports as historical. Fixed vulnerabilities aren’t presented as current defects.
Hands-on testing: Each product was tested against the same target: exposing an API-backed multitenant application through a reusable MCP gateway.
Test conditions: macOS, Claude Code client, up to roughly one hour per product.
Last updated: July 21, 2026.
The hands-on evaluations measured onboarding and architectural fit. Production load, failure recovery, token lifecycle, cost at scale, and security fell outside scope. The onboarding test favored products with a managed, self-service path. Products requiring local, containerized, or cloud infrastructure deployment were not attempted. Their out-of-scope status reflects the test design, not a product limitation.
Evidence confidence levels. Each product is rated across three dimensions.
Hands-on testing (High/Medium/Low/Blocked/Out of scope) reflects the depth of the author’s own evaluation.
Documentation (High/Medium/Low) reflects how well vendor documentation supports the product’s claims.
Independent evidence volume (Deep/Moderate/Thin) measures how much verifiable, non-vendor evidence exists, not whether that evidence is favorable.
Deep means enough independent reports to assess the product clearly. Moderate means some independent data, limited in scope. Thin means the independent record is near-empty or predominantly vendor-authored.
How to evaluate an MCP gateway: 10 criteria
These criteria came from repeated Reddit themes, not vendor feature matrices.
Hands-on MCP gateway test results
A fast vendor demo isn’t the same as exposing a custom multitenant application through a reusable MCP gateway. GitHub provided a common integration baseline, but the real pass condition was whether the product could support the broader B2B architecture.
The category boundary matters. Arcade behaved like a gateway and governed runtime for this test. Composio behaved like a managed SaaS-tool connection layer. Merge delivered a fast vendor-controlled playground path.
Nango addressed downstream authentication to third-party services, but my own MCP endpoint still needed its own inbound authorization layer. Kong’s managed experience behaved first like an LLM router, and reaching the MCP path required data-plane setup in my test. Obot’s test ended at identity-provider configuration before I could evaluate its gateway.
Arcade MCP Gateway: best overall for custom multitenant B2B applications
Bottom line: Arcade produced the strongest result in my ten-product evaluation. It was the only product that completed the target architecture.
Documentation and Reddit evidence
What the company claims: Arcade combines an MCP gateway with managed tool execution, user-scoped credentials, authorization policy, audit, and an agent-oriented integration catalog. The product is built around safely letting agents act on behalf of individual users.
What the cited Reddit reports consistently praise: Arcade’s authorization controls, governance, and hook-level failure policies stand out.
A separate builder described access, pre-execution, and post-execution hooks with input modification, output filtering, dry-run testing, and per-hook fail-open or fail-closed behavior. Another commenter identified per-hook failure policy as the most useful production design choice because different tools carry different risks.
The report documents policy behavior but doesn’t include uptime, latency, high-availability, or scale data.
What Reddit users complain about: Pricing clarity and category clarity are the blockers. One buyer questioned a reported 100-fold call-price gap. An earlier evaluator struggled to distinguish Arcade from MCP plus OAuth.
The Reddit corpus doesn’t have data on uptime, latency, self-hosted operating burden, support quality, or production scale.
Hands-on evaluation
What I found when I tested it: Arcade was the only product that completed the full target architecture. Within 60 minutes, I connected GitHub, created the gateway through the web interface, added and removed tools, and attached a custom MCP server through either the web interface or command line.
The resulting URL connected successfully from Claude Code and supported MCP-native tool discovery. I also verified authentication at both boundaries, from Claude Code to the gateway and from the gateway to downstream tool calls.
Tool-level authentication worked after I hosted the tool on Arcade’s runtime. The documentation didn’t clearly state this requirement.
Recommendation
Who should choose this: Product teams building multi-user agents that take delegated actions in customer or employee accounts.
Who should avoid this: Teams that only need a protocol proxy, a local MCP catalog, or a generic API gateway they already operate.
Evidence confidence: Hands-on was high, since I completed the full target architecture in 60 minutes. Documentation was also high, covering authorization, governance, hook design, and deployment options. Independent evidence volume was thin, with no data on production adoption, reliability, self-hosted operations, or scale.
Docker MCP Gateway: best local open-source MCP setup
Bottom line: Docker is the best default for centralized local MCP servers, but it’s not a remote multi-user control plane.
Documentation and Reddit evidence
What the company claims: Docker’s Gateway and Toolkit containerize MCP servers, inject credentials, manage server lifecycle, and expose one shared catalog to compatible clients. The pitch is safer, simpler local MCP management through Docker’s existing desktop and container model.
What Reddit users consistently praise: Users value one-time configuration, catalog convenience, and container isolation. The 15 to 18 independent firsthand users make this the strongest local-use corpus in my comparison. Developers also like reusing the same managed server set across multiple desktop clients instead of maintaining separate configuration files.
What Reddit users complain about: Tool-list inflation is the most measurable complaint. One report counted 70 tools consuming about 49,351 tokens. Another measured 13.3% context usage versus 0.1%. ARM64 compatibility, secret handling, and headless deployment create additional friction.
Hands-on evaluation
What I found when I tested it: Access required filling out a sales form. I decided not to proceed, so this assessment is based on product documentation and the cited user reports.
Recommendation
Who should choose this: Developers who already use Docker Desktop and want isolated local servers shared across multiple MCP clients.
Who should avoid this: Teams that need remote multi-user identity, delegated authorization, centralized enterprise policy, or a headless fleet control plane.
Evidence confidence: Hands-on was blocked, and no self-serve tier was available. Documentation was high, with a clear product scope and well-defined feature boundaries. Independent evidence volume was moderate. The 15 to 18 independent firsthand users make this the strongest local-use corpus in this comparison, but coverage stays limited to local development, which is why it’s moderate rather than deep. No data exists on production governance, scale, or remote multi-user use.
Amazon Bedrock AgentCore Gateway: AWS-native managed MCP infrastructure
Bottom line: AgentCore fits teams already standardized on AWS that want Lambda functions, APIs, and remote MCP servers behind an AWS-managed gateway. Its Runtime has limited but real production evidence. I found no independent production validation for Gateway, Identity, or Policy.
Documentation and Reddit evidence
What the company claims: Amazon Bedrock AgentCore Gateway composes Lambda functions, APIs, remote MCP servers, agent runtimes, and model providers behind one managed MCP endpoint. AWS documents protocol translation, inbound authorization, downstream credential exchange, tool filtering, semantic tool selection, policy, interceptors, and observability.
Gateway is one service in the wider AgentCore platform, alongside Runtime, Identity, Policy, Memory, and other agent infrastructure.
What Reddit users consistently praise: The strongest evidence is broader than Gateway but includes real MCP production use. One user said their company runs AgentCore in production for MCP deployments and agent sandboxes. They liked its cold starts and cost, and still noted Amazon-specific constraints around state and MCP usage.
A separate evaluator called AgentCore the easiest way to set up an agent proof of concept (POC) on AWS.
Gateway-specific reports support the architecture more than production maturity. One commenter identified Gateway with Lambda targets as the right fit for converting an existing backend into MCP tools. Another explained that Gateway becomes useful as one intermediary for many agents and remote MCP servers because it can centralize inbound and outbound identity and observability.
But that same discussion contains the opposing boundary. Adding a single remote MCP server as a Gateway target may be unnecessary over-engineering when the agent can call it directly.
What Reddit users complain about: The most concrete operational complaints concern AgentCore Runtime and the surrounding AWS platform, not Gateway itself. One evaluator reported Runtime sessions continuing toward the eight-hour maximum after StopRuntimeSession, creating a session-lifecycle and billing risk.
That’s a Runtime issue, not a defect in AgentCore Memory or proof of a Gateway problem. Another user struggled to get container logs into CloudWatch because of execution-role permissions and unwieldy OpenTelemetry output.
A separate pricing-calculator error produced a $16 million estimate after confusing vCPU-hours with vCPU-seconds. That was a calculator defect, not an actual bill.
Infrastructure maturity and lock-in remain fit questions. A community member built a Terraform module after finding the workflow too CLI- and script-oriented.
That complaint is dated. AWS reports that its AgentCore CDK constructs became stable in May 2026. A comparative evaluator still praised Firecracker session isolation while criticizing AWS lock-in and the absence of on-premises deployment.
Hands-on evaluation
Hands-on status: Out of scope. Creating the required AWS account configuration, roles, targets, and related infrastructure was outside the timeboxed evaluation. This assessment is based on product documentation and the cited user reports.
Recommendation
Who should choose this: AWS-standardized teams already operating Lambda, API Gateway, Cognito or another compatible identity provider, IAM, CloudTrail, and CloudWatch that want MCP to live in the same control plane.
Who should avoid this: Teams that require cloud portability, on-premises deployment, a lightweight standalone gateway, simple cost attribution, or minimal AWS IAM and networking work.
Evidence confidence: Hands-on testing was out of scope, since creating the required AWS configuration fell outside the timeboxed evaluation. Documentation was high, with extensive AWS coverage across Gateway, Runtime, Identity, and Policy. Independent evidence volume was thin. One production account covers Runtime, and several implementation discussions exist, but I didn’t find any independent Gateway production report.
TrueFoundry MCP Gateway: Kubernetes-native enterprise governance
Bottom line: TrueFoundry fits regulated teams that want model, MCP, and agent governance inside their VPC. Gateway-only buyers inherit a larger platform than they need.
Documentation and Reddit evidence
What the company claims: TrueFoundry’s federated architecture provides centralized auth, role-based access, audit, budgets, and policy while keeping runtime components within the customer’s infrastructure. The MCP gateway sits inside a wider platform for governing models, agents, and AI workloads.
What Reddit users consistently praise: Governance, private deployment, RBAC, audit, and budgets drive positive evaluations. One established account called the platform excellent. A promotional-looking account reported working fallback chains, which is useful product evidence but isn’t independent validation.
What Reddit users complain about: Routing configuration is the most specific repeated criticism. Two independent evaluators described fragmented routing configuration as less flexible than Portkey, a competing LLM proxy tool. Another reported dropped Google flags and incorrect token counts for virtual models.
Hands-on evaluation
What I found when I tested it: The basic GitHub integration test completed in about 10 minutes with no friction.
Setting up a custom external identity provider didn’t work. The configuration kept returning errors when connecting the external provider. I gave up after about 30 minutes total. For a product whose positioning centers on enterprise governance, the identity layer is a core differentiator that I couldn’t validate.
Recommendation
Who should choose this: Regulated organizations already standardized on Kubernetes that want one control plane for models, MCP servers, and agents.
Who should avoid this: Teams shopping for a thin MCP proxy, a low-operations managed integration layer, or a lightweight local tool.
Evidence confidence: Hands-on testing was medium. The basic GitHub test completed in 10 minutes, but identity provider setup failed with configuration errors after 30 minutes. Documentation was medium, with federated architecture, RBAC, audit, and budget controls. Independent evidence volume was also moderate. One established account praised it, and routing complaints come from independent evaluators, but I found no production-scale validation.
IBM ContextForge: open-source MCP gateway for enterprise federation
Bottom line: ContextForge has the broadest documented open-source enterprise feature set in this comparison. Before production, test high availability, latency, restart recovery, and operating burden.
Documentation and Reddit evidence
What the company claims: ContextForge federates MCP, A2A, REST, and gRPC services behind virtual servers, plugins, policy controls, identity features, and OpenTelemetry. The pitch is an enterprise control plane for mixed protocols and upstream services.
What Reddit users consistently praise: The strongest firsthand account covers virtual servers, SSO, and encrypted downstream personal access tokens. A separate user described header rewriting for Jira Data Center. Another company self-hosted ContextForge while evaluating Kong.
The real strength is federation with identity bridging, which goes beyond simple protocol proxying.
What Reddit users complain about: Operational complexity is the recurring cost. The strongest operator still considered consolidating components, and older production warnings show why version dates matter.
The cited reports cover IAM and federation, but leave out high availability, A2A traffic, or latency under load.
Hands-on evaluation
Hands-on status: Out of scope. ContextForge required deploying and managing the service either locally or on the cloud, which I kept out of scope for this test. This assessment is based on product documentation and the cited user reports.
Recommendation
Who should choose this: Enterprises that require a fully self-hosted control plane, mixed upstream protocols, and integration with existing IAM.
Who should avoid this: Small teams without clear ownership for deployment, databases, upgrades, observability, and incident response.
Evidence confidence: Hands-on testing was out of scope, since it required deployment infrastructure. Documentation was medium, with the broadest open-source feature set in this comparison, but I couldn’t verify this myself. Independent evidence volume was thin. The strongest account covers SSO, virtual servers, and header rewriting, but there’s no HA, A2A traffic, or latency data.
Nango MCP Auth: downstream OAuth infrastructure, not an inbound MCP gateway
Bottom line: Nango is a strong supporting component when your gateway needs to connect users to third-party APIs or MCP servers without owning provider-specific OAuth maintenance. It didn’t replace the inbound authorization layer I needed to expose my own multitenant application through MCP.
Documentation and Reddit evidence
What the company claims: Nango provides managed OAuth, token refresh, credentials, and integration infrastructure, with support for exposing integrations to agents and MCP clients. It focuses on auth and integration maintenance instead of a full enterprise MCP control plane.
What Reddit users consistently praise: Independent builders often appreciate how Nango reduces provider-specific OAuth work. A QuickBooks builder recommended using Nango as the auth layer while the application requested a fresh access token per request.
A separate RAG builder used it to add Google Drive, Dropbox, and Notion, and a bootstrapped SaaS developer said Nango’s local authentication did exactly what they needed. These reports validate setup convenience and reduced OAuth work, but none covers multi-month token refresh or production tenant isolation.
What Reddit users complain about: Self-hosting, documentation, regional hosting, and product boundaries recur as blockers. One self-hoster received HTML from an API call and couldn’t progress. Another buyer wanted EU hosting and stronger token security. A bootstrapped developer liked Nango’s authentication but found the unified API cost-prohibitive.
A 2023 evaluator found pagination, documentation, and data mapping outside Nango’s useful scope at the time. That report applies to the 2023 release, so don’t treat it as current behavior.
A CRM developer used Nango to rapidly connect a fragmented set of CRMs for a partner-management product, but said they’d build that layer in-house today. That supports Nango as a way to ship faster early on. But it also shows Nango didn’t remove the custom domain logic or the eventual build-versus-buy decision.
Hands-on evaluation
What I found when I tested it: Google SSO was easy, and Nango’s Node.js and cURL examples worked without friction against GitHub. The architectural boundary became clear within 30 minutes.
Nango MCP Auth helps an application connect outward to third-party MCP servers and stores the resulting OAuth tokens. It didn’t act as the inbound OAuth authorization server in front of my own multitenant MCP endpoint.
In my architecture, the identity provider and application gateway still had to handle client registration, user login, token issuance, audience restriction, and bearer-token verification. Nango only managed the downstream credentials.
I stopped because completing the target architecture required way more infrastructure than the test justified. The getting-started success action also centered on starring Nango’s GitHub repository rather than proving the API-to-MCP path I was trying to build.
Recommendation
Who should choose this: Teams that already have an inbound gateway or authorization layer and want to own their integration logic while outsourcing downstream OAuth edge cases and ongoing provider maintenance.
Who should avoid this: Buyers expecting Nango alone to expose and authorize access to their own multitenant MCP service, normalized business objects, mature MCP policy, or a self-hosted product that requires little operational work. Teams using only client-credentials grants gain less from user-facing OAuth management. One developer described that exact architectural preference.
Evidence confidence: Hands-on testing was medium. I tested for 30 minutes, and the Node.js and cURL examples worked, but then I stopped when the architectural boundary became clear. Documentation was also medium. The OAuth setup path was clearly laid out, but self-hosting docs drew complaints. Independent evidence volume was moderate. Multiple independent builders praise OAuth abstraction, but there’s no multi-month refresh data, and self-hosting reports are mostly negative.
Kong AI Gateway: MCP support for existing Kong deployments
Bottom line: Kong is the incumbent-extension choice for organizations already governing APIs through Kong. It’s a weak greenfield recommendation for teams that only need MCP.
Documentation and Reddit evidence
What the company claims: Kong AI Gateway extends Kong’s traffic management, plugins, security, and observability model to AI and MCP traffic. The pitch is to govern MCP through the same gateway platform you already use for APIs.
What Reddit users consistently praise: Kong’s mature gateway controls carry real weight. Users respect its PII controls and semantic routing. The real positive is practical. Kong reuses infrastructure, skills, plugins, and procurement that already exist.
What Reddit users complain about: As one Redditor put it, Kong is “Powerful if you are already a Kong shop“. One team spent two weeks implementing per-agent identity in Lua before choosing Gravitee. I found almost no independent production use of Kong’s MCP and A2A-specific plugins.
Hands-on evaluation
What I found when I tested it: Google SSO was straightforward, and creating an AI Gateway was easy. Kong’s managed demo worked within five minutes, but the experience initially felt more like an LLM router than an MCP gateway.
The GitHub MCP path stopped at Kong data-plane setup. The next documented stage required a Kong data plane and applicable licensing. Because the evaluation excluded deploying an existing enterprise gateway stack, I stopped at that point. This reinforced Kong’s fit as an extension for existing Kong customers.
Recommendation
Who should choose this: Organizations with an established Kong platform team that want MCP policy and traffic to live in the same operational control plane.
Who should avoid this: Greenfield teams that would be adopting Kong solely for MCP or that need delegated integration auth out of the box.
Evidence confidence: Hands-on testing was low. In 10 minutes, I only reached a managed demo before stopping at the licensed data-plane setup requirement. Documentation was medium, since Kong is a mature platform with well-covered infrastructure. Independent evidence volume was thin. Kong is respected among existing Kong shops, but I didn’t find any MCP-specific production evidence to back it up.
Obot MCP Gateway: open-source hosting, registry, and access
Bottom line: Obot combines hosting, registry, access, and client delivery in one open-source platform. The independent evidence amounts to one Kubernetes deployment and one shorter “works well” report.
Documentation and Reddit evidence
What the company claims: Obot combines MCP hosting, a registry, OAuth, access rules, audit, and a client in one self-hostable platform. It covers the full path from server deployment to governed end-user access.
What Reddit users consistently praise: The strongest case is a six-node Kubernetes environment using Obot to organize several MCP services. Another user simply said it works well. These reports support the value of putting hosting, access, discovery, and client access in one system.
What Reddit users complain about: In the direct comparison I found, one evaluator preferred TrueFoundry for registry, RBAC, OAuth, and observability. Obot’s own DevRel acknowledged that the quick Docker examples were minimal and that production requires persistent infrastructure. Both disclosed security issues were fixed, so it’s worth verifying you’re running the patched version during deployment.
Hands-on evaluation
What I found when I tested it: Obot’s cloud signup started by provisioning an instance. I spent about 15 minutes on the test, most of it waiting for that instance to become available.
Continuing required configuring a separate supported identity provider. Because that dependency was outside my test setup, I stopped before evaluating the gateway. I didn’t reach Obot’s gateway, registry, access-control, or runtime capabilities.
Recommendation
Who should choose this: Teams that want one open-source system for MCP hosting, registry, access, and client delivery.
Who should avoid this: Buyers who require a long production track record, externally validated HA characteristics, or the deepest enterprise governance today.
Evidence confidence: Hands-on testing was low. I spent 15 minutes on the test and got blocked at OAuth-provider setup before reaching the gateway. Documentation was medium. Hosting, registry, access, and OAuth are all covered. Independent evidence volume was thin. It comes down to one Kubernetes deployment and one shorter positive report.
Composio MCP Gateway: managed toolkit integration layer
Bottom line: Composio is one of the fastest ways to give an agent access to many SaaS products, and I found its initial SaaS-tool onboarding fast in my own testing. But independent reports and a confirmed 2026 security incident raise questions that high-risk teams should investigate before production use.
Documentation and Reddit evidence
What the company claims: Composio Sessions provides per-user endpoints, managed authentication, tool allowlists, routing, and a broad integration catalog. The pitch is fast access to many SaaS tools without building each OAuth and execution layer yourself.
What Reddit users consistently praise: The cited reports like the setup speed, integration breadth, and Tool Router’s context reduction. One user said the Tool Router worked well and reduced context bloat. An n8n builder also reported getting a social automation workflow working through Composio’s MCP layer.
What Reddit users complain about: The strongest recurring negative is poor LLM-oriented tool design, including excessive parameters, thin API wrappers, missing-parameter failures, and agents that fail to complete actions. The original evaluator later said the same problem caused them to abandon Composio. A separate firsthand report said multi-tenancy “doesn’t seem to scale well” and some tools “feel like placeholders”.
Users also report a four-day outage, a GitHub connection that remained active but returned 401 Bad Credentials, opaque charges, and risk from bearer-like hosted URLs. In a separate report, another user said they couldn’t connect to MCP.
Verified incident history: Composio’s official incident report confirms unauthorized access, 5,001 compromised GitHub connections, roughly 0.3 percent of active connections leaked, and 5,241 API keys in a cache the attacker likely accessed. These are first-party confirmed incident facts, separate from the Reddit reliability reports.
Hands-on evaluation
What I found when I tested it: Signup through Google SSO was easy, and I had the starter running in roughly 15 to 20 minutes after fixing a minor missing environment-loading step.
The initial success was misleading for my target architecture. The example used my local GitHub CLI rather than Composio’s GitHub toolkit. After I explicitly instructed the agent to use Composio MCP, I had to connect GitHub to a user and discover that the request also needed that connected user’s user_id. The getting-started path didn’t explain this clearly.
Logs didn’t appear in the web console, and the terminal output was highly verbose. The getting-started success action also centered on starring Composio’s GitHub repository rather than proving the API-to-MCP path I was trying to build.
After about 70 minutes, I still hadn’t created a reusable gateway where different users could authenticate. The toolkit endpoint generated in my test was user-specific, and I couldn’t find a supported path for attaching my own remote MCP server or having Composio host it. For this test, Composio behaved more like a managed SaaS-tool connection layer than an organizational MCP gateway.
I used Claude for troubleshooting. It resolved most setup questions, but didn’t close the authentication gap.
Recommendation
Who should choose this: Teams optimizing for prototype speed and broad SaaS coverage that can independently test critical integrations.
Who should avoid this: High-risk teams should avoid Composio when failed actions, credential exposure, poor LLM-oriented tool design, or a prolonged outage could create material business or compliance impact. The most credible escape path in the Reddit evidence is direct provider APIs or small in-house integrations. That reduces middleware blast radius but transfers OAuth, API drift, and maintenance back to your team.
Evidence confidence: Hands-on testing was medium. The starter worked in 70 minutes, but I never reached the target architecture, and the getting-started path was misleading. Documentation was medium. Sessions and tool routing were documented, but getting started didn’t surface the user_id requirement. Independent evidence volume was deep, with enough independent praise, detailed criticism, outage reports, and a confirmed security incident to support clear conclusions.
Merge Agent Handler: B2B integrations for AI agents
Bottom line: Merge Unified’s track record doesn’t validate Agent Handler. I found zero independent reports of connecting an MCP client, executing a tool, or testing its DLP, audit, or observability controls.
Documentation and Reddit evidence
What the company claims: Merge offers unified APIs and agent-facing integration infrastructure intended to normalize access across many B2B systems. Agent Handler extends that integration foundation into tools that agents can discover and execute.
What Reddit users consistently praise: Merge Unified, not Agent Handler, has the positive track record. One firsthand user called an ATS deployment solid but warned against using Merge for CRM. An HRIS evaluator said Merge was worth considering for normalized access across multiple providers.
That supports standardized category coverage and maintenance reduction, not deep provider-specific behavior.
What Reddit users complain about: Deep CRM, semantic normalization, pricing, and migration are the failure boundaries. A Salesforce team burned a quarter trying to make custom objects work before switching to a CRM-specific provider. An HRIS evaluator found that Merge normalizes structure but not business meaning, leaving customers to reconcile concepts like multiple definitions of an active employee.
Another user warned that pricing can rise sharply once Merge is embedded and migration costs create sunk-cost pressure.
A customer with several hundred linked accounts said migration would require asking those customers to reauthenticate. A Merge employee responded that credentials can be exported, but OAuth tokens remain tied to the application that issued them. That’s partly an OAuth-provider constraint, not something unique to Merge, but the customer migration cost remains real.
A production Workday deployment also reported polling timeouts. The thread didn’t isolate the cause. It identified Workday API limits, request breadth, batching and pagination, and timeout configuration as contributing factors.
Hands-on evaluation
What I found when I tested it: Merge delivered the fastest guided first success. Google SSO, connecting GitHub, and executing a request in the web playground took about five minutes.
That success stayed inside Merge’s playground. The toolkit URL generated in my test was user-specific, and progressing toward my multitenant gateway required several additional components. I couldn’t find a path to one reusable endpoint where different users could authenticate and use the configured tools.
I stopped after 15 minutes because the product wasn’t converging on the gateway architecture I was testing.
Recommendation
Who should choose this: Choose Merge Unified when standardized HRIS, ATS, payroll, or similar category coverage matters more than provider-specific depth. Validate Agent Handler separately. Merge Unified’s integration record doesn’t carry over to it.
Who should avoid this: Teams that require deep provider-specific objects, semantic normalization, predictable pricing at scale, or migration without widespread customer reauthentication. Avoid treating Agent Handler as proven when independent MCP production evidence is a requirement.
Evidence confidence: Hands-on testing was low. In 15 minutes, I could only reach the playground, with no gateway-path convergence. Documentation was medium. The Unified API was well-covered, though Agent Handler’s material was thinner. Independent evidence volume was moderate, with concrete normalization, CRM-depth, pricing, and migration reports for Unified. But I didn’t find an independent Agent Handler deployment report.
Lunar MCPX: open-source MCP gateway that requires hardening
Bottom line: Lunar MCPX has the right open-source primitives for centralized MCP governance, but the available independent reports describe a product that still needs hardening.
Documentation and Reddit evidence
What the company claims: MCPX provides a registry, tool groups, access policy, audit, and a self-hosted gateway for managing multiple MCP servers through one endpoint. It focuses on centralized visibility and selective tool exposure.
What Reddit users consistently praise: The only positive production claim comes from Lunar’s co-founder. The independent reports describe setup failures, lost configuration, restarts, and migration away from MCPX.
What Reddit users complain about: The pattern from independent users is setup and stability friction. Reports describe a UI that could not connect to MCPX’s webserver, a container that required constant restarts, and one user who switched to AgentGateway after finding MCPX unstable.
Hands-on evaluation
What I found when I tested it: The identity provider was gated behind an enterprise plan and a sales call. Lunar does offer a locally deployable server that serves as a downstream auth manager, but I couldn’t evaluate the full gateway without access to the identity layer.
Recommendation
Who should choose this: Open-source teams willing to test, patch, and operate an early gateway in exchange for control over deployment and policy.
Who should avoid this: Teams that need reliable defaults, mature documentation, or proven production resilience now.
Evidence confidence: Hands-on testing was blocked, since the identity provider was gated behind the enterprise plan. Documentation was low, described as weak by independent users. Independent evidence volume was thin. The sample is small and predominantly negative, and the only positive production claim is founder-authored.
MintMCP: compliance-focused MCP gateway with limited independent evidence
Bottom line: MintMCP has strong compliance positioning and the weakest independent validation in this comparison. Don’t shortlist it without customer references and a structured proof of concept.
Documentation and Reddit evidence
What the company claims: MintMCP targets enterprise MCP hosting with SSO, RBAC, virtual servers, monitoring, policy, and audit controls. It’s aimed at organizations that need compliance and centralized administration around MCP access.
What Reddit users consistently praise: There’s no recurring independent praise pattern. The best independent signal is a sysadmin who built a Cloud Run proxy and said MintMCP would now tempt them. That’s purchase consideration, not a deployment result.
What Reddit users complain about: A smaller-team evaluator called it too complex. More important than that single criticism, at least 109 of 112 threads in our research were affiliated or company-authored. The corpus contains zero verified independent deployments, performance tests, or procurement accounts.
Hands-on evaluation
What I found when I tested it: The basic GitHub setup worked end-to-end in about 20 minutes. The onboarding path was straightforward enough to complete without friction.
I couldn’t test the identity features (SSO, RBAC, and related controls) because they’re behind the Enterprise plan. For a product whose primary positioning is compliance and centralized administration, the core differentiators weren’t accessible during evaluation.
Recommendation
Who should choose this: Compliance-focused buyers prepared to run a structured proof of concept and validate claims with customer references.
Who should avoid this: Teams that require community-proven operations, transparent independent benchmarks, or a lightweight deployment.
Evidence confidence: Hands-on testing was medium. The basic GitHub setup was completed in 20 minutes, but the Enterprise pricing tier blocked identity features. Documentation was medium. Product capabilities are covered, but core differentiators are gated by plan. Independent evidence volume was thin. 109 of 112 threads were affiliated or company-authored, with zero verified independent deployments, performance tests, or procurement accounts.
Where MCP gateway claims differ from user experience
Which MCP gateway should you choose for each failure mode?
What Reddit evidence says about MCP gateways
Reddit provides implementation reports, not a reliable measure of independent community sentiment. Disclosed founders, employees, and affiliates can be identified, but undisclosed commercial relationships can’t.
Vendor participation is common across this category. Composio has company-authored posts alongside community accusations of stealth marketing. Nango’s founder participates frequently in discussions about Nango’s product boundaries and MCP’s production readiness.
Founder participation isn’t inherently misleading, and affiliated posts can contain accurate technical information. But they don’t establish independent adoption or satisfaction.
Reports carry the most weight when they describe a concrete architecture, configuration, error, workload, or operational outcome. Repeated patterns, current versions, documentation, and hands-on results increase confidence. Unsupported recommendations and sentiment-only comments carry little weight.
Version and product boundaries change several conclusions:
First, older ContextForge warnings describing it as alpha or unsupported don’t represent the current post-1.0 project. Its documented feature set has expanded substantially. No cited report covers current high availability, performance, or operating burden.
Second, AgentCore Gateway isn’t interchangeable with AgentCore Runtime, Memory, Policy, Identity, or the older Bedrock Agents product. The reported AgentCore “memory leak” concerns Runtime session lifecycle and billing behavior, not the AgentCore Memory service. One company’s use of AgentCore for MCP deployments and agent sandboxes validates a narrow production use case, not every AgentCore service.
Third, the Obot gateway authorization bypass and OAuth metadata SSRF were fixed. Use patched versions and test API authorization and outbound network controls.
Fourth, the Composio security incident isn’t Reddit speculation. Composio confirms unauthorized access, 5,001 compromised GitHub connections, about 0.3 percent of active connections leaked, and 5,241 API keys sitting in an auxiliary cache the attacker likely accessed. These incident facts come from Composio’s official report.
Fifth, Reddit discussions frequently collapse Kong’s traditional API gateway, AI Gateway, and MCP-specific plugins into a single product reputation. The corpus contains no MCP-specific production validation.
Finally, open source doesn’t mean operationally free. ContextForge, Obot, Lunar MCPX, Docker’s headless gateway, and self-hosted Nango still require some combination of databases, Kubernetes, upgrades, monitoring, security hardening, and incident ownership. No software-license fee doesn’t mean no platform-engineering cost.
Common mistakes when choosing an MCP gateway
Choosing integration count instead of measuring whether an agent can actually use the tool schema reliably.
Treating server authentication as if it solved downstream per-user authorization.
Selecting a desktop abstraction for a remote, multi-user production topology.
Assuming open source removes database, Kubernetes, upgrade, and incident ownership.
Waiting until security review to add credential isolation, tool-level policy, and attributable audit logs.
Ignoring migration until hundreds of customers must reconnect OAuth accounts.
Accepting vendor latency, token, or detection benchmarks without reproducing the workload.
Buying an integrated agent platform when a direct MCP connection or a single-purpose gateway would solve the problem with fewer IAM, networking, observability, and billing surfaces.
Treating apparently unaffiliated Reddit comments as verified independent evidence.
MCP gateway research limitations and disclosures
Reddit overrepresents failures and underrepresents quiet enterprise deployments. Search coverage is incomplete, and names like Lunar, Merge, and ContextForge generate false positives.
The ten hands-on evaluations measured onboarding and architectural fit, not production load, failover, token expiry, revocation, cost at scale, audit completeness, or security. Of the ten, only Arcade actually connected to Claude Code. I stopped Merge, Nango, Kong, and Obot when their setup or architecture diverged from the target, while TrueFoundry’s identity provider setup failed with configuration errors after the basic test completed. Enterprise pricing tiers gated MintMCP’s and Lunar MCPX’s identity features, and Docker required a sales form to access. AgentCore and ContextForge fell outside the test’s scope, since they required setting up infrastructure on AWS and self-hosted deployments, respectively.
Commercial disclosure: My company, Zenith, provides content marketing services to Arcade and previously worked with Composio. The product testing, Reddit research, comparisons, and conclusions are my own.
I’ll update this article as products change and as more reproducible hands-on and production results become available. If you’ve run one of these gateways in production, share the topology, version, traffic level, failure mode, and migration outcome in the comments. That’s the evidence this category needs.
Frequently asked questions about MCP gateways
What is an MCP gateway?
An MCP gateway is a control layer between MCP clients and one or more MCP servers. It centralizes routing, authentication, tool permissions, credentials, observability, and audit logs.
What is the difference between an MCP gateway and an MCP server?
An MCP server exposes tools, resources, and prompts to AI applications. An MCP gateway sits between clients and servers to aggregate connections, authenticate users, enforce policy, and record activity.
Do I need an MCP gateway?
Use an MCP gateway when multiple users, agents, clients, or servers require shared authentication, permissions, and auditing. A direct MCP server connection is enough for a single-user local workflow.
What is the best MCP gateway in 2026?
Arcade is the best MCP gateway for custom, multitenant B2B applications in this comparison. Docker MCP Gateway is the best local development option, while Amazon Bedrock AgentCore fits teams already operating on AWS.
What is the best open-source MCP gateway?
Docker MCP Gateway is the best open-source option for local development and shared desktop clients. IBM ContextForge targets self-hosted enterprise federation but requires more infrastructure and platform ownership.
What is the best MCP gateway for enterprise AI agents?
Arcade is the strongest fit for delegated authentication, tool-level policy, custom MCP servers, self-hosting, and air-gapped deployment. Amazon Bedrock AgentCore fits enterprises standardized on AWS IAM, CloudTrail, CloudWatch, and Lambda.
How does an MCP gateway improve security?
An MCP gateway centralizes user authentication, credential isolation, tool permissions, rate limits, and audit logs. It limits which users and agents can call each tool, but it does not make an insecure MCP server safe.
Can an MCP gateway be self-hosted?
Yes. Arcade supports self-hosted and air-gapped deployments. IBM ContextForge, Docker MCP Gateway, Obot, and Lunar MCPX also provide self-hosted options, with different requirements for identity, policy, monitoring, and maintenance.
Disclosure up front: I build one of these things, so take this as a note on scope rather than a recommendation.
What strikes me about the list is that all twelve entries answer the same question — how does an organisation put a control plane in front of MCP servers its users share. Auth, credential isolation, tenant separation, audit: those criteria only make sense when there is more than one user and the gateway sits on a server.
The case that isn't represented is the single-user one. Someone runs Claude Desktop on their own laptop, points a filesystem MCP server at their home directory, and the entire permission model is one allowed-directory string. There is no tenant to isolate and no policy engine to configure — but the question "which of my files may this model change, and what did it actually do" is the same question, and the answers look completely different: per-file rather than per-directory, a local log rather than an observability stack, no server to operate.
Not a criticism of the comparison — the B2B multitenant frame is stated clearly. But if anyone is reading this hoping to solve the laptop case, none of the twelve will fit, and it might be worth saying so in a line.