An MCP gateway comparison starts with control

Most companies do not need an MCP gateway when one developer connects one trusted assistant to two read-only tools. They need one when tool access becomes a company capability: several users, several agents, shared systems, write actions, credentials that must not live on laptops, or an auditor who will ask who approved what. Buying a gateway before that point adds another service to operate. Waiting beyond it leaves policy scattered across clients you do not control.

The useful comparison is not a checklist of protocol support. Nearly every serious contender can proxy a tool call. The hard questions are whether the gateway preserves user identity, authorizes the specific tool and arguments, separates inbound from upstream credentials, records a defensible decision, and fails safely when an upstream server changes. A product that centralizes connection strings but cannot answer those questions is a directory with a proxy, not a control boundary.

MCP is also moving quickly. Treat every vendor capability in this article as something to verify in a proof of concept, especially transport versions, client compatibility, deployment modes, and features marked preview. Architecture survives release notes. Feature matrices do not.

You need a gateway when access becomes shared

A company needs an MCP gateway when the cost of inconsistent access exceeds the cost of operating a central enforcement point. Server count alone is a weak signal. Three servers that can deploy code, change billing, and read customer records deserve more control than thirty public documentation servers.

I use five triggers. The first is shared distribution: teams copy server definitions, environment variables, and tokens among multiple clients. The second is privileged action: an agent can write, delete, deploy, refund, invite, or change configuration. The third is identity: the company needs the tool to act as the employee or workload that initiated the call, not as one shared service account. The fourth is evidence: security or compliance needs a durable record of the request, policy decision, and result. The fifth is operational ownership: someone must approve servers, pin versions, remove compromised tools, and keep client configurations consistent.

One trigger can justify a gateway if the consequence is serious. A finance agent with a single refund tool needs stronger controls than a research group using many public search tools. Conversely, ten engineers using local, read-only documentation servers may be fine with managed configuration and endpoint protection instead of a runtime gateway.

Do not put a gateway into the call path merely to make an architecture diagram look mature. Every hop adds failure modes, latency, certificate work, upgrades, and an on-call obligation. If the gateway cannot enforce a policy that the client or server cannot enforce reliably, keep the direct path. A central registry may solve discovery without taking responsibility for runtime traffic.

A simple threshold test is useful. List each tool and mark whether it uses company credentials, reaches nonpublic data, changes state, crosses a trust zone, or needs a retained audit record. If any write tool has two marks, or any tool has three, a central control point deserves a pilot. This is a risk screen, not a compliance formula, but it stops teams from buying on server count.

A proxy, registry, runtime, and gateway are different

An MCP gateway sits in the data path and makes a decision on each relevant request. A registry tells clients which servers exist. A runtime launches or hosts servers. An API gateway handles HTTP concerns and may understand nothing about MCP methods, tool names, sessions, or streaming behavior. Products can combine all four, but procurement should score them separately.

This distinction catches a common failure. A platform team publishes one endpoint for five upstream servers and calls the result governed. The endpoint authenticates the client and forwards traffic, but every authenticated user can see and call every tool. The team has centralized routing, not authorization. If list_invoices and cancel_invoice share the same access rule, the protocol boundary is doing little security work.

A registry has a different job. It establishes ownership, provenance, supported versions, approved clients, and retirement status. It can stop developers from finding tools in random repositories, but it cannot stop a client from calling a previously configured endpoint. A registry needs distribution controls or a gateway if removal must take effect quickly.

A runtime solves yet another problem: local servers are programs with dependencies and operating-system privileges. Docker MCP Gateway focuses on this layer by running servers in isolated containers, restricting privileges, network access, and resource use, while also centralizing routing and credentials. That is attractive for developer workstations and server lifecycle management. It does not automatically answer an enterprise question such as whether Alice may call merge_pull_request only in repositories owned by her group. Test the policy layer separately from the sandbox.

A conventional API gateway can be the right base when MCP is another protocol in an established platform. It already has certificates, high availability, identity integration, rate limits, logs, and operators. But matching /mcp and validating a JWT is not protocol awareness. Ask whether it parses tools/call, understands tool discovery, maintains stream semantics, filters advertised tools, and can apply policy to arguments without corrupting JSON-RPC responses.

Write the requirement in verbs. "Register servers" belongs to the catalog. "Run untrusted local servers" belongs to the runtime. "Reject this user's production delete call before execution" belongs to the gateway and authorization system. That vocabulary prevents a polished control plane from hiding a thin data plane.

Identity must reach the policy decision

The gateway must know which human or workload initiated a call, which client carried it, and which upstream identity will execute it. Collapsing those identities into one API key makes the deployment easy and the audit trail nearly useless.

There are two authorization legs. On the inbound leg, the MCP client authenticates to the gateway. On the outbound leg, the gateway authenticates to the MCP server or its backing API. The credentials should differ, and the gateway should bind them through an explicit policy. Passing the inbound bearer token straight to an upstream service looks convenient because it avoids token exchange and credential storage. It is the wrong shortcut.

The MCP Authorization specification explicitly forbids token passthrough. It requires a server to validate that a token was issued for that server as its audience. The accompanying Security Best Practices document explains the confused-deputy risk: a proxy that accepts and forwards a token intended for another resource can let callers bypass controls and destroys clear accountability. I agree with the prohibition, and I would reject any gateway design that treats header forwarding as delegated identity.

A credible gateway supports one of three outbound patterns. It can use a gateway-owned service credential for tightly bounded machine actions. It can keep a per-user OAuth grant and refresh it without exposing the token to the client. Or it can exchange the inbound identity for a short-lived token scoped to the upstream resource. The correct choice depends on whether the upstream action must appear as the user, an application, or a controlled automation account.

Ask vendors to demonstrate revocation, not just login. Disable a user in the identity provider while an MCP session remains open. Remove one group membership. Revoke the upstream OAuth grant. Rotate a backend secret. The next sensitive call should fail for the intended reason, and the log should identify which credential or policy changed. A gateway that checks identity only when a session starts can leave a long window of stale authority.

Client identity also matters. A trusted coding assistant and an unknown desktop client should not inherit the same approval merely because the same employee uses both. The current MCP security guidance calls for per-client consent in proxy authorization flows. In company deployments, that usually means registering approved client types, binding redirect URIs, retaining consent, and deciding whether dynamic client registration is open, restricted, or disabled.

Finally, keep authorization independent of the model's claim about itself. Tool arguments such as requested_by, prompt text that says "the CFO approved this," or an agent-generated reason are untrusted inputs. Use identity from validated credentials and workload metadata supplied outside the model context. The agent can explain a request, but it cannot attest to its own authority.

Tool-level policy is only the starting line

A production gateway must authorize the tool, the resource named in its arguments, and sometimes the proposed change. Allowing a user to call update_ticket says nothing about which ticket, which fields, or which transition should be permitted.

Tool-level allowlists are useful because they reduce discovery and execution to an approved set. They also make least privilege understandable to humans. Kong documents global and per-tool access control lists for MCP traffic. Gravitee maps OAuth scopes to individual MCP tools and can add an external authorization decision. TrueFoundry and Portkey describe tool-level access controls, while Cloudflare's MCP portals let administrators choose which tools appear through a portal. Those are meaningful primitives, but a checkbox called "tool RBAC" does not prove resource-level enforcement.

Make vendors run an argument test. Give a developer permission to read staging deployments and deny production. Then send the same tool with only one argument changed:

{
  "jsonrpc": "2.0",
  "id": 41,
  "method": "tools/call",
  "params": {
    "name": "get_deployment",
    "arguments": {"environment": "production", "service": "billing"}
  }
}

The expected denial should preserve the JSON-RPC envelope and produce a stable policy identifier for operators. Your exact error contract may differ, but define it before the test:

{
  "jsonrpc": "2.0",
  "id": 41,
  "error": {
    "code": -32003,
    "message": "Tool call denied by policy",
    "data": {"policy_id": "env-read-scope", "decision_id": "req-7f2a"}
  }
}

That artifact tests four things at once: protocol-safe rejection, argument inspection, a machine-readable decision, and correlation. Repeat it with a missing field, an array where a string belongs, extra properties, a Unicode lookalike, and an oversized value. Policy code that assumes clean model output will fail in production.

High-impact writes often need an approval state between allow and deny. The approval record should bind the exact tool, normalized arguments, user, client, expiry, and policy version. If an approver sees "deploy billing" while the stored request can later change the image tag or environment, the approval is theater. Hash the canonical request and reject execution when anything material changes.

Do not make a human approve every call. Approval fatigue moves the decision to muscle memory and stalls useful automation. Use automatic rules for bounded reads, require approval for exceptional writes, and deny actions the agent should never perform. The gateway should also support rate limits and concurrency limits by identity and tool, but those controls contain abuse; they do not replace authorization.

Audit logs need decisions, not transcripts

A useful MCP audit record explains who asked, what the gateway understood, why it allowed or denied the call, what upstream identity it used, and whether the action completed. A raw request transcript misses policy context. A full transcript can also collect secrets, personal data, source code, and model output that the company never intended to retain.

For each call, record a request ID, timestamp, authenticated subject, client identity, server and tool version, normalized tool name, policy version, decision, reason code, approval reference if present, upstream target, latency, and outcome. Store arguments selectively. A deployment environment and repository name may be appropriate; an access token, document body, SQL result, or customer message may not be. Redaction must happen before durable logging, not in a dashboard query.

Ask whether logs distinguish these outcomes: the gateway denied the call, the upstream rejected it, the network timed out, the user canceled approval, and the tool returned a business error. They mean different things to security and operations. A single failed=true field forces someone to reconstruct the incident from incomplete traces.

Observability also needs MCP-aware dimensions. HTTP status alone is weak because JSON-RPC errors can travel in successful HTTP responses, and streaming transports can fail after headers arrive. Track method, tool, server, session behavior, response completion, and policy decision. Confirm that tracing does not buffer or consume a stream. Microsoft warns that reading a streamed MCP response body in certain API Management policies breaks the stream; that is exactly the sort of implementation detail a glossy observability claim omits.

Retention should follow the data, not the enthusiasm of the AI team. Keep policy metadata long enough for investigation and compliance. Keep sensitive payloads only when a named use case justifies them, with tighter access and shorter retention. If a vendor cannot redact nested argument fields before storage, assume its audit feature will create a second sensitive-data system that your security team must govern.

Current vendors solve different company problems

The emerging market divides into established API platforms adding MCP, AI gateways expanding from model traffic, cloud security platforms building agent controls, and purpose-built open source gateways. Compare the operating model first, then the feature set.

Microsoft Azure API Management is the natural candidate for an Azure-centered company that already runs APIM. Its documentation covers pass-through MCP servers, exposing REST APIs as MCP tools, policies, products, quotas, monitoring, and a self-hosted gateway in supported tiers. Azure API Center adds discovery. The attraction is organizational reuse: the same platform team, identity system, networking, and policy process can govern APIs and tools. The cautions are tier differences, preview API versions for some management features, and documented gaps such as tools being supported while MCP resources and prompts are not in the established APIM MCP feature set. Microsoft's separate AI Gateway tier adds a managed catalog and federation model, but it is preview territory and should be scored as such.

Kong fits companies that already treat Kong as their API enforcement layer or want MCP, model, and API traffic under one gateway family. Its MCP proxy and OAuth documentation addresses external servers, identity-provider integration, credential stripping, and per-tool ACLs. That is more substantial than generic HTTP proxying. The evaluation should still prove which controls require enterprise products or particular versions, how Konnect and self-managed deployments differ, and whether argument-level policy can use your existing authorization service.

Gravitee is worth a look when the company wants API management, access management, and MCP under one control plane. Its current documentation describes protocol-native MCP proxying, converting managed APIs into MCP servers, per-tool OAuth scopes, and optional authorization decisions such as OpenFGA. This makes it interesting for mixed API and agent estates. Test the maturity of the MCP path with your exact clients and transport patterns, and separate shipped support from roadmap material across Gravitee modules.

Solo.io agentgateway takes a cloud-native, purpose-built route. The open source data plane targets MCP, model, and agent-to-agent traffic, while Solo sells the enterprise operations and governance around it. It is a strong architectural fit for teams comfortable with Kubernetes, Gateway API concepts, self-hosting, and policy composition. That same fit can be a burden for a small company without platform engineering. Score the open source build you can operate separately from enterprise features, support, and registry components.

TrueFoundry and Portkey come from the AI gateway side. Both document centralized MCP registries, one client-facing access path, upstream credential handling, tool access, logs, and guardrails. TrueFoundry describes per-user token mapping, RBAC and ABAC, approval workflows, and deployment choices tied to its broader AI platform. Portkey describes workspace and user provisioning, credential injection, per-tool availability, approvals, and a unified view with model traffic. These products can reduce integration work for an AI platform team, but buyers should test identity fidelity, data-plane placement, log residency, policy extensibility, and what continues working if the hosted control plane is unreachable.

Cloudflare MCP server portals make sense for organizations already using Cloudflare Access and Gateway. Portals aggregate servers behind one endpoint, authenticate users through Access, select exposed tools, and can send traffic through data-loss controls. This approach joins MCP governance to an existing secure-access edge. Verify upstream OAuth experience, non-HTTP or local-server needs, argument-aware authorization, regional routing, and the exact licensing bundle rather than assuming every Cloudflare gateway feature applies to MCP portals.

Docker MCP Gateway starts with server execution and developer distribution. It can launch MCP servers in isolated containers, inject credentials, restrict resources and network access, and centralize client connections. For a company trying to stop arbitrary local processes and duplicated workstation configuration, that is concrete value. Docker's documentation also places some governance capabilities behind an invite-only offering, so distinguish the open source gateway and Desktop workflow from Docker AI Governance during procurement. It may complement a remote policy gateway rather than replace one.

No vendor wins this comparison in the abstract. Existing APIM ownership favors Microsoft, Kong, or Gravitee. A Kubernetes platform can favor agentgateway. A company buying a broader AI control plane may prefer TrueFoundry or Portkey. A Cloudflare-centered security team has a different shortest path, and a developer-platform team worried about local server processes should test Docker. The cheapest product that matches your operating model usually beats the product with the longest feature page.

Build versus buy depends on policy complexity

Build a thin MCP gateway when your requirements are narrow, your identity and authorization services already exist, and you can keep the gateway out of the business of hosting servers, running approvals, and building a catalog. Buy when you need several of those systems together or need another party to support protocol churn and client compatibility.

Use a weighted scorecard rather than a feature count. Score each option from 0 to 5, multiply by the weight, and require written evidence from a test. A slide earns zero. A working demonstration in your environment earns three. An automated acceptance test plus an operational owner can earn five.

The weighting is deliberately unfriendly to feature theater. Identity and credential handling dominate because a mistake there turns the gateway into a privilege concentrator. Three-year cost gets a smaller percentage because teams routinely understate internal engineering and overstate license savings. Calculate money after technical disqualifiers, not before.

For the build option, estimate at least these work streams: protocol proxy and compatibility tests, authentication, policy integration, upstream token lifecycle, configuration distribution, audit redaction, high availability, upgrades, and incident response. A reverse proxy with a JWT check is a prototype, not the completed build. The build can still win if an existing gateway supplies most of those parts and the MCP-specific adapter stays small.

Set disqualifiers before scoring. Examples include token passthrough, shared upstream credentials for actions that require user attribution, no pre-storage redaction, no way to revoke a tool centrally, or a hosted data path that violates residency rules. A weighted total must not let good dashboards compensate for a broken security property.

A proof of concept should try to break the gateway

The pilot should reproduce your ugliest access path, not the vendor's happiest demo. Use one read tool, one write tool, one user-authorized SaaS server, one internal server, and at least two client types. Include a client the vendor has not optimized its demo around.

Run a fixed acceptance sequence. First, connect and list tools as a fully authorized user. Then remove one tool permission and verify that discovery and execution both change. Next, alter a protected argument, revoke the upstream grant during an active session, and retry an identical request with the same JSON-RPC ID. Force an upstream timeout after response headers. Rotate a server definition while one client holds a session. Finally, search every emitted log for the planted secret and personal-data value that should have been redacted.

Capture the result in a decision table with four columns: test, expected control, observed result, evidence location. Record packet traces and exported logs where policy permits. Make the vendor explain every partial pass. "The dashboard eventually updated" is not a pass for revocation, and "the client hid the denied tool" is not a pass if a direct call still succeeds.

Measure latency, but do not optimize the median while ignoring failure behavior. Tool calls often wait on external systems, so a few milliseconds of policy evaluation may be acceptable. Broken streaming, duplicated writes after retries, dropped cancellation, or a gateway that fails open are not. Confirm whether retries apply only to safe operations and whether the gateway can distinguish idempotent reads from state changes.

Test control-plane loss as well. Existing sessions, new sessions, policy updates, revocation, logs, and server discovery may behave differently when the management service disappears. Decide which functions must fail closed and which can use a last-known-good configuration. A company that needs emergency tool removal cannot accept a data plane that honors cached access for hours without a separate kill switch.

The pilot ends with an operating plan. Name who approves servers, who owns policies, who responds to an authorization outage, who reviews sensitive logs, and how teams request a new tool. If those names are blank, the gateway will centralize technical traffic while organizational access remains ad hoc.

The first purchase is an ownership decision

Choose the smallest gateway that enforces your required boundary and fits the team that will operate it. For many startups, that means delaying a broad platform purchase, centralizing only privileged remote tools, and leaving harmless local documentation tools outside the gateway. For a regulated company with an existing API platform, extending the established control plane may be safer than introducing a fashionable specialist.

I argue against buying a combined MCP registry, runtime, gateway, model router, prompt store, and agent builder merely because the bundle looks complete. The bundle is popular because procurement gets one product and a clean diagram. It also couples unrelated migrations and gives a young control plane custody of identities, secrets, logs, and every tool call. Buy the bundle only if you want its operating model and have tested each boundary.

The first internal artifact should be a tool ownership map, not a vendor shortlist. Assign every privileged tool an owner, data class, allowed identities, upstream credential model, write policy, and retirement path. That map reveals whether you need a registry, a runtime, a policy gateway, or all three. It also gives vendors something concrete to implement in a pilot.

At oleg.is, the Team & AI Audit is the engagement I use when a founder needs that operating map tied to engineering cost and a five-day decision process. The gateway choice then follows the access model instead of driving it.

Do not sign until one denied production write produces the identity, policy version, normalized arguments, and reason you expected, while the upstream system receives nothing. That single test says more about an MCP gateway than another hundred boxes in a comparison sheet.