Best MCP Gateways (2026): Enterprise Comparison of Security, Tool Access and Scale

Tyk 5.16 arrived on October 27 with support for a newer MCP revision. The best MCP gateway depends on your architecture: AWS AgentCore fits AWS-managed deployments, Obot and IBM ContextForge fit self-hosting, and TrueFoundry combines enterprise model and tool governance. Requesty combines managed MCP access with model routing. We make Requesty, one of the products compared here.

The enterprise MCP gateway comparison

As of October 2026, enterprise teams can choose from managed platforms, cloud services and self-operated gateways. We reviewed the vendor documentation on October 30. Tyk's release illustrates why version numbers belong in the buying decision: it also includes a REST-to-MCP header fix.

The first table separates caller authentication from upstream authentication: the credential the client presents to the gateway and the credential the gateway presents to a server. The second covers records and hosting. Read the same product across both tables.

Identity and tool access

Activity and hosting

Start with the architecture you need

Pick AWS AgentCore when the tool layer belongs in AWS and you want a managed service that connects MCP targets or exposes existing APIs as tools. Pick TrueFoundry when a common platform for model and tool governance is the larger requirement.

For self-hosting, pick Obot for server hosting and a curated registry, ContextForge for federation, or Bifrost for a combined model and MCP gateway. Your team operates these deployments. Docker MCP Gateway is a better starting point for local containerized servers than a hosted HTTP-only gateway.

If Kong, Tyk or Cloudflare is already part of your access path, use its MCP controls with your existing identity and logging setup. Pick Requesty when you want managed registration of remote MCP servers alongside model routing.

Other self-managed options include ToolHive, for container workloads and a Kubernetes operator, and agentgateway, for a protocol-aware proxy with policy-as-code. Lunar MCPX aggregates MCP servers and runs locally or in Docker; its consumer and tool-group policies provide another way to manage access. Tie consumer tags to a trusted identity and test direct invocation; a client-supplied tag alone does not authenticate the caller. Pick Composio when connected SaaS accounts are the main requirement.

What an MCP gateway does

The Model Context Protocol (MCP) is a standard for connecting AI applications to tools and data sources. An MCP server supplies tools, resources or prompts to a client. An MCP gateway sits in front of one or more servers and gives the client a managed path to them. Depending on the product, it authenticates the caller, filters available tools, supplies upstream credentials and records activity. The protocol defines hosts, clients and servers; it does not require a gateway.

A model gateway handles a different path: requests to model providers. An MCP gateway handles access to tools and their servers. A platform can contain both, but a model spend limit does not automatically govern the cost of a separate database, SaaS tool or hosted MCP server. Our agent harness guide covers the model traffic side.

An API gateway can authenticate HTTP requests and enforce traffic policy. An MCP-aware gateway can also inspect protocol operations, including named tool calls, when its policy supports them. For one developer experimenting with a local server, a direct connection is simpler. A gateway becomes useful when several clients need the same server configuration, or a security team needs to change credentials and tool access in one place. For the protocol itself, see our MCP server guide.

Compare identity at both ends

Take an agent acting for Alice. Alice authenticates to the gateway, which allows a read tool. The gateway then needs a credential for the destination. If that is Alice's personal credential, the destination can evaluate her own permissions. If it is a shared service account, the destination sees the service account. The gateway record can still identify Alice, but the downstream service has a different view.

TrueFoundry's authentication guide describes both shared and individual credentials. Shared credentials are useful for an organization-owned integration, but scope them to the resources that integration needs. Our guide to shared API keys and agent identity covers the same attribution problem on the model request path.

A gateway credential also has an intended recipient. The MCP security guidance requires a server to accept only tokens issued for that server. For delegated access, check the token audience and use a supported upstream authorization or token exchange flow. A token accepted by the gateway is not automatically valid for every server behind it.

OAuth, API keys and shared credentials

MCP authorization is optional in the protocol. Where an implementation supports HTTP authorization, the MCP authorization specification describes an OAuth-based framework. A gateway's inbound login and its upstream credential flow remain separate configuration choices.

• TrueFoundry, Bifrost, Obot and Cloudflare document per-user OAuth for supported upstream services. Each target has its own flow and scopes.
• Requesty Enterprise lets an admin enable personal server keys. Users add personal keys in the dashboard, and Requesty uses them to authenticate to the server. See user key management.
• Shared credentials authenticate the gateway to the upstream service as an organization-owned identity. Review the account's permissions and rotation procedure.

AWS makes another distinction in its inbound authorization options: AUTHENTICATE_ONLY validates SigV4 without making an authorization decision, while NONE does neither. For AUTHENTICATE_ONLY, enforce authorization in a policy, interceptor or downstream service. For NONE, authenticate callers in a trusted interceptor or downstream service before authorizing access. If the downstream service makes that decision, give it a validated caller credential or another trustworthy caller identity; a shared gateway credential alone identifies the gateway.

Test tool access, audit and scale

A feature list will tell you that a product has tool filtering. It will not tell you whether your intended policy survives a guessed tool name, an expired credential or a second gateway replica. Run the same tests on each shortlisted product.

Discovery is not execution

MCP uses tools/list for discovery and tools/call for invocation. A client that does not see delete_record could still try to call that name directly. Test the invocation as well as the list, then check whether the upstream service received anything.

Some defaults deserve attention:

• Bifrost's tool rules include an Allow by Default option. Its MCP overview says requests without credentials see all available tools when enforce_auth_on_inference is false. Set the intended authentication and filtering rules before exposing the endpoint.
• Kong's per-tool ACL replaces the default ACL for that tool; it does not inherit the default entries. In listener mode, include_consumer_groups: true passes group membership to the aggregated tools.
• Cloudflare's portal guide says new tools and prompts are enabled by default. Set default_disabled to true for an opt-in mapping and review new tools after synchronization. The same guide says independent MFA, purpose justification and temporary authentication are not enforced for servers authorized through a portal.

Review each newly published tool description and schema as untrusted input, and require approval for sensitive write actions where your workflow calls for it. The MCP security practices cover threats including prompt injection and token misuse.

Run a two-user acceptance test

Assume a test server with a read tool and a write tool. Configure Alice to read but not write, and Bob to read and write. Use separate test accounts and a harmless test record.

Decide which layer enforces each rule. For a gateway-level test, use per-user tool policies where the product documents them. With team-wide tool selection and personal upstream credentials, test user-specific denial at the upstream service instead.

Measure the revocation window for each credential. In Bifrost's inbound OAuth documentation, revoking a grant stops refresh, but an issued access token continues until expiry. The default token lifetime is 600 seconds, so the remaining window depends on the token's age. Deleting the bound user or virtual key is different: the documented identity check rejects that token on the next request.

Audit records need their own review. A tool response can contain sensitive data, so ask who can view payloads, where they are stored, how long they remain and how they are deleted. Obot separates payload viewing permission from its MCP audit records. Check denied calls as well as successful calls, and distinguish tool-call records from administrator configuration changes.

Cloudflare changed its tool-call timeseries API on October 28. The analytics changelog says the account, portal and server timeseries endpoints now default to successful calls; set response_status=all to include errors and cached calls. Compare event definitions and filters before treating two totals as equivalent.

Test versions and capacity on both hops

An MCP gateway has a client-facing connection and a server-facing connection. Record the protocol revision and transport for each. The July 2026 MCP changelog removes protocol-level sessions and the initialization handshake from revision 2026-07-28; older clients use a different connection model. An application authorization grant or workflow session is a separate concept. Streamable HTTP can still return SSE streams, so an SSE response is not automatically the older HTTP-plus-SSE transport.

Cloudflare's compatibility announcement describes independent protocol selection on the client and upstream sides. Microsoft's repository requires 2026-07-28 clients and adapters on its current branch and provides no legacy downgrade. That branch is not a claim about every deployed release.

Now consider capacity. Assume a stable workload completing 10 tool calls per second. At an average of 2 seconds per call, about 10 x 2 = 20 calls are in flight. At 5 seconds, the same throughput requires about 10 x 5 = 50 in-flight calls. These are average in-flight counts; size for bursts and tail latency separately. A slow upstream server consumes concurrent capacity even when gateway processing is fast.

For a scale pilot, record each candidate's release, replica count and topology. Run the same read-only tool workload at a constant rate and a burst rate you choose. Record completed calls per second, errors, end-to-end p50, p95 and p99 latency, in-flight calls and whether limits hold across replicas. Repeat with a slow upstream and a dependency outage, then compare the results with your own targets.

Test limits across replicas and during dependency failure. ContextForge's RateLimiterPlugin reference distinguishes memory counters per worker from Redis counters shared across replicas and documents fail-open and fail-closed options when Redis is unreachable. Ask each vendor which operations a limit counts and measure burst behavior.

When tools are missing or authentication fails

If no tools appear, check server connectivity and the transport and protocol revision on both hops. Check upstream credentials and the gateway's enabled-tool selection, then refresh client discovery. Requesty's server management guide describes connection and tool exploration checks.

For a 401 or 403 response, check the caller's gateway authentication and policy separately from the upstream credential's validity and scopes. A gateway login can succeed while the upstream server rejects the credential used for the tool call.

Also inspect the MCP response. A tool execution failure can appear in a result with isError: true, including when HTTP returns 200. The MCP tools specification shows the result-level error format; its HTTP transport example shows a successful HTTP response carrying a JSON-RPC result. Record the HTTP status and the protocol response when investigating a denied call.

Product details that affect the shortlist

TrueFoundry and AWS: managed platform choices

TrueFoundry's authentication guide documents user-specific upstream OAuth alongside shared credentials. Its deployment documentation describes SaaS and customer-operated paths. A customer-hosted control and gateway plane still lists external authentication and analytics components; establish the dependencies before planning a disconnected deployment.

AWS AgentCore Gateway fits a team already operating on AWS. Its outbound authentication matrix distinguishes user-specific authorization for MCP targets from other identity flows. Attach the policy and logging needed for the target you use.

Obot, Bifrost and ContextForge: self-hosted choices

Obot's v0.27.0 release uses virtual MCP servers for client connections. Obot Community supports up to 100 users and 100 devices without a license key. A new license key needs access to Obot's license service for validation. Obot's tool profiles are additive: a narrow profile does not remove access granted by a broader one. Use Managed tool setup for a fixed selection; As-is passes through later upstream changes.

Bifrost combines MCP access and model traffic and supports local and remote server transports. Its authentication defaults and grant revocation behavior belong in the pilot described above. IBM ContextForge fits federation and conversion of existing services. Budget for deployment, upgrades, secrets and monitoring in either self-operated system.

Docker and Microsoft: local and Kubernetes operations

Docker MCP Gateway runs MCP servers in containers and lets developers select tools with profiles. The standalone CLI works with Docker Desktop or independently. A local profile is not an enterprise-wide user policy.

Microsoft MCP Gateway is a Kubernetes project with Entra integration and stateless request routing on its current branch. Its optional agent subsystem is preview and single-replica. Assess it separately from the gateway before using it for multi-tenant production.

Kong, Tyk, Cloudflare and Portkey: extend an existing estate

Kong AI MCP Proxy converts REST APIs to tools or proxies existing MCP servers. It requires AI Gateway Enterprise. If your team already manages Kong consumers and groups, test those identities against both list and call ACLs.

Tyk is an alternative for teams operating an API gateway. Its MCP policy documentation describes named-tool access and per-primitive limits. Tyk 5.16 supports MCP 2025-11-25 and 2026-07-28 side by side; versions 5.13 to 5.15 support 2025-11-25. Tyk uses Streamable HTTP, not stdio or legacy HTTP-plus-SSE. For stateful clients, Tyk rejects client responses to server-initiated requests, so flows requiring those responses, including sampling, elicitation and roots, do not work through it.

The 5.16 release notes also describe a fix for REST-as-MCP tool arguments mapped to source API headers: protected headers such as Authorization can no longer be set from a tool call. Remote MCP proxying is available across Gateway licenses; REST-to-MCP conversion requires Enterprise and an existing Tyk OAS REST API.

Cloudflare MCP server portals combine Access authentication with portal-wide tool selection. Per-user upstream OAuth and shared admin credentials cover different identity needs; service-token connections do not connect servers that require per-user OAuth.

Portkey's MCP Gateway provides a registry, tool provisioning and call observability. Pick it for a trial when Portkey already handles model traffic. Its deployment documentation describes managed and hybrid options with a Portkey-managed control plane; fully air-gapped deployments are no longer offered to new customers.

Set up remote MCP servers with Requesty

Register your MCP servers once for the organization, select the tools your team needs and track their use in MCP analytics. Enterprise users can add personal upstream API keys. Claude Code, Cursor and Roo Code can connect through one Requesty MCP URL, alongside the model gateway. The MCP Gateway documentation lists streamable-http and sse upstreams; stdio support is coming soon. For a local stdio server you want the gateway to run, pick Docker, ToolHive, Bifrost or Obot.

1. 1
   Register a server

   Open the MCP Gateway console. Choose a template or add a custom server URL. For a custom server, select streamable-http or sse and configure the required authentication headers.

2. 2
   Review and select tools

   Choose Explore Server. Review the descriptions and input schemas, enable the tools the team needs and save the configuration. The server management guide describes the dashboard flow.

3. 3
   Choose upstream credentials

   An admin can configure an organization-wide credential. On Enterprise, the admin can instead enable personal key management and users can add their own upstream API keys through Manage Keys. These server credentials are separate from the Requesty credential used to identify the caller.

4. 4
   Connect Claude Code

   In your project directory, set REQUESTY_API_KEY in your shell to your Requesty API key. Then add the Streamable HTTP endpoint using Anthropic's documented MCP command:

   Shell

   Copy

   claude mcp add --transport http requesty https://router.requesty.ai/v1/mcp --header "Authorization: Bearer $REQUESTY_API_KEY"
   claude mcp get requesty

   The shell expands the key into the command, and Claude Code stores the resulting header in ~/.claude.json under this project's local configuration. The key can also be visible in process arguments. Protect the file and update the configuration when you rotate the key. The Requesty endpoint and bearer header are also listed in the MCP integration guide. In our October 30 initialize call, the server reported protocol revision 2025-06-18.

5. 5
   Test the tools

   In Claude Code, open /mcp and check the server's status and tool list. Call an enabled read tool. For the disabled-tool test, use an MCP client that can send a tools/call for an arbitrary known tool name without first requiring it to appear in tools/list. Send the disabled tool's known valid test arguments, inspect the protocol response and check the upstream server log for a matching request. When using personal credentials, test different users' permissions at the upstream service. Review request volume, latency, success and tool usage in MCP analytics.

Enterprise includes individual activity and audit of key changes and security events, as described in the user-key documentation. Requesty adds a 5% service fee on top of credit top-ups, with no seat fees or minimums. Compare that separately with model usage and charges from upstream services.

Choose your first pilot

Pick AWS AgentCore for an AWS-native tool layer, Obot or ContextForge when you want to operate the gateway, and TrueFoundry for a broader enterprise AI platform. Pick Requesty for managed MCP access and model traffic in the same gateway.

This week, register one test server. Allowlist one read tool and leave one harmless write tool disabled. Call both, inspect the gateway and upstream records, and use the result to decide what belongs in your production policy. To start with Requesty, sign up and register the server.