How to Choose an MCP Gateway
A category guide for AI and Platform leaders
Caveat: Distinguish categories from capabilities
The MCP gateway market arrived fast. In less than two years, a protocol designed to standardize how AI agents connect to tools has spawned an entire infrastructure category and now a crowded vendor landscape to go with it.
Most evaluation guides jump straight to feature matrices. This one doesn’t, because the features that matter to you depend almost entirely on what kind of solution you’re actually evaluating. An MCP Gateway built as an extension of an existing API management platform behaves differently, carries different trade-offs, and serves a different organizational need than one built purpose-first for AI governance.
Before you compare capabilities, you need to understand the category of solution in front of you.
The Four Categories of MCP Gateway
Category 1: The Point Solution
These vendors built an MCP gateway as their primary product. MCP governance is not a feature, it’s the whole business.
What this looks like: A dedicated control plane for MCP traffic, typically with strong native support for the MCP specification (OAuth 2.1, transport variants, tool-level RBAC), a curated server registry, and deployment models designed specifically for enterprise AI workloads. The roadmap follows MCP, not some broader platform agenda.
What you get: Depth. When the product exists to solve the MCP problem, you tend to get tighter protocol fidelity, faster alignment with spec evolution, and a vendor whose support team has seen every MCP failure mode before you have.
What to watch for: Breadth gaps. If your enterprise also needs LLM routing, spend governance across non-MCP AI traffic, or data protection at the prompt layer, a pure MCP point solution may leave you stitching together another product alongside it.
Category 2: The Platform Add-On
These are cloud platform providers or large enterprise software vendors that have added MCP gateway functionality to an existing, broader platform. Think hyperscalers, major cloud-native networking vendors, and enterprise integration suites that have bolted MCP support onto their existing infrastructure.
What this looks like: MCP as a plugin, module, or feature release within a platform you may already be running. The gateway often inherits the parent platform’s auth model, observability stack, and deployment constraints.
What you get: Consolidation. If you’re already standardized on the parent platform, the marginal cost to add MCP governance may be low, and integration with adjacent capabilities (existing audit pipelines, IAM, etc.) is often native.
What to watch for: MCP is not the vendor’s core competency, and it shows. Protocol fidelity often lags the spec. Features tend to mirror what the parent platform’s architecture already supports rather than what MCP governance actually requires. The vendor’s roadmap is set by the broader product, not by your MCP use cases. And if you’re not already a customer of the parent platform, you may be buying considerably more than you need.
Category 3: The API Gateway Extension
These vendors started as general-purpose API gateway or API management providers and have extended their products to support AI traffic, including MCP. They occupy a distinct position from Platform Add-Ons because API governance is their heritage; that means they understand proxy patterns, policy enforcement, and traffic management well, and that MCP is a natural adjacency.
What this looks like: An existing, mature API gateway product with new AI-aware plugins, MCP proxying capabilities, and LLM traffic routing layered on top of a proven data plane.
What you get: A familiar operational model for teams already running this vendor’s API infrastructure. Policy configuration, observability pipelines, and deployment patterns are consistent with what the platform team already knows. If you’re managing hundreds of APIs and want MCP governance to live in the same control plane, this approach has real appeal.
What to watch for: AI-specific concerns like prompt-level data protection, agent identity, spend attribution, and context window management are not native to the API gateway mental model. Expect to find these capabilities thinner, slower to develop, or missing entirely. You may also find yourself paying for significant API management infrastructure you don’t need just to get to the MCP features you do.
Category 4: The Integrated AI Control Plane
This category is newer and reflects where the market is heading. These vendors have built a unified control plane that spans MCP Gateway, LLM Gateway, and in some cases broader AI agent governance that treats all AI traffic (tool calls, model calls, agent actions) as a single governed surface rather than separate infrastructure problems.
What this looks like: A single deployment that handles prompt-level LLM governance (spend attribution, data protection, model routing, audit) alongside MCP tool governance (server registry, tool-level access control, runtime security, identity propagation). The identity model, policy engine, and audit trail are shared across both layers.
What you get: A control plane that reflects how AI actually works in production. LLM calls and MCP tool calls aren’t separate concerns for the agent making them, and they shouldn’t be separate concerns for the platform team governing them either. A unified deployment also means one integration with your IdP, one audit stream to your SIEM, one place to set budgets and access policy, and one vendor relationship.
What to watch for: This category requires vendors to have executed well across two adjacent but distinct technical problem sets. The depth of LLM governance and the depth of MCP governance may not be equal. Evaluate each layer on its own merits, not just on the appeal of consolidation.
Evaluation Criteria by Organizational Priority
1. Deployment model requirements
This is often a hard filter before features matter at all.
- Data residency and regulatory requirements will disqualify any solution that requires traffic to route through a shared SaaS layer. Self-hosted, in-VPC deployment is the baseline for regulated industries.
- Air-gapped or on-premises requirements further narrow the field to vendors with genuine self-hosted options, not SaaS products with a “bring your own cloud” checkbox.
- Kubernetes-native operations vs. appliance or agent-based models affects your platform team’s operational burden long-term.
2. Identity and access model
The question is not whether a gateway supports OAuth 2.1. Almost all of them will say they do. The question is whose identity model the gateway is built around.
A key-centric identity model (virtual API keys, team keys) is operationally simpler but creates fundamental governance gaps: keys rotate on a different cycle than employment, don’t propagate user context to downstream tools, and are harder to attribute in an audit. A claim-centric, IdP-bound identity model (where every LLM call or MCP tool call carries a real user or agent identity derived from your organization’s identity provider) is harder to implement but produces the audit trail your security and compliance teams actually need.
3. Scope of AI governance
Determine whether you need to govern just MCP traffic, or AI traffic broadly.
Most production AI applications generate LLM calls and MCP tool calls within the same agent run. If your gateway only governs tool calls, you have visibility into what the agent did but not what it was told to do or what it spent getting there. For finance, this is a significant gap (model spend attribution). For security, it’s an audit gap. For platform teams, it means running two separate infrastructure products and two separate policy models.
4. Supply chain and server provenance
In production, your platform team needs to answer: which servers are approved, who approved them, what version is running, and has it been verified?
Look for: curated server registries with provenance verification, SLSA attestations or signed artifacts, a clear process for adding new servers to the approved catalog, and runtime controls that prevent unapproved servers from being invoked.
5. Operational fit for the platform team
The best governance architecture fails if the platform team can’t maintain it. Evaluate:
- Onboarding new teams and agents: how long does it take, and does it require a new security review every time?
- Integration with existing observability: does the gateway produce OpenTelemetry-compatible traces, or does it require a proprietary observability stack?
- Upgrade path and vendor support model: open-source projects require your team to own the maintenance burden. Enterprise software with a formal support model does not. Know which one you’re buying.
Where Stacklok Fits
Stacklok is an Integrated AI Control Plane (Category 4) that is purpose-built for enterprises that need to govern all AI traffic, not just MCP tool calls.
The product was built under a single design principle: every AI interaction in the organization, from a developer’s coding assistant to a business user’s drafting tool, should pass through one governed control point, bound to real identity, with one audit trail and one policy model.
Stacklok is the right fit if:
- Deployment model is non-negotiable. Stacklok runs in your environment, behind your firewall, with no traffic routing through shared SaaS infrastructure. For regulated industries, this is a hard requirement.
- Identity is the foundation, not a feature. Every request is tied to a real person or named agent through your existing identity provider. Access follows employment. When someone leaves, access ends. When an auditor asks, there’s a record.
- You need to govern both LLM and MCP traffic. Stacklok handles prompt-level governance (spend attribution by team and agent, sensitive data detection and blocking, multi-provider LLM routing) alongside MCP governance (server registry with provenance verification, tool-level access control, Kubernetes-native MCP server management).
- Your platform team needs leverage, not more projects. New teams, tools, and agents inherit the governance controls automatically. The platform team sets policy once; they don’t approve every new AI initiative from scratch.
- Finance and security need to sign off. The most durable AI governance decisions in large organizations have three sponsors: the team that controls spend, the team that controls risk, and the team that controls the platform. Stacklok is built to give all three what they need from one deployment.
The Evaluation Checklist
Before you score any vendor, confirm your answers to these questions:
On deployment:
- Does this need to run in our environment, or can it route through third-party infrastructure?
- Do we have air-gap or on-premises requirements?
On identity:
- Is every request (LLM and MCP) bound to a real user or agent identity from our IdP?
- Does the audit trail carry that identity, or just a key or API credential?
On scope:
- Do we need to govern LLM traffic and MCP traffic, or only MCP?
- Is spend attribution across both layers a requirement for finance?
On supply chain:
- Can the platform team maintain a curated, verified registry of approved MCP servers?
- Is there provenance verification (signatures, SBOMs, attestations) for server artifacts?
On operations:
- How does the platform team onboard a new team or agent without a new security review?
- Does the vendor have a commercial support model with SLAs, or does our team own maintenance?
On the vendor:
- Is AI governance the vendor’s primary business, or a feature added to something else?
- Does the vendor’s roadmap follow the AI governance problem, or the parent platform’s agenda?
May 22, 2026