Evaluating MCP Gateways: Buy Against the Specification, Not the Feature Grid

An MCP gateway sits between your agents and your systems and enforces who may call which tool, under whose identity, with what left behind in the audit log. Most of what it should enforce is already mandatory in the Model Context Protocol specification. So evaluate gateways on conformance, not features: the spec supplies the correct answers before any vendor call.

1. Why the feature grid fails here

Run a normal gateway bake-off and you will build a matrix with rows like "RBAC," "audit logging," "SSO," and "OAuth support." Every serious vendor will tick every row. The matrix produces no ranking because the rows are not discriminating — they are category table stakes, phrased at a level of abstraction where nobody can fail.

The MCP specification is unusually generous to buyers here, because it does not describe capabilities in the abstract. It states obligations in RFC 2119 language — MUST, MUST NOT, SHOULD — attached to named mechanisms with named standards behind them. "Do you support OAuth?" is a row every vendor ticks. "Do you validate that inbound tokens carry your gateway in the audience claim, and reject those that do not?" is the same subject rendered falsifiable. One of those questions sorts a shortlist.

2. What changed in the current revision

MCP moves fast enough that a shortlist assembled six months ago can be testing for guarantees the protocol has since restructured. Three changes in the current revision matter directly to how you evaluate a gateway, and each one invalidates a question you might otherwise have asked.

The pattern across all three is the same: the protocol tightened its identity guarantees and removed an implicit one. A gateway built against the older model is not necessarily insecure, but it is answering a question the specification has stopped asking — and that gap is precisely what a conformance-led evaluation surfaces and a feature grid hides.

3. Eight conformance questions with answers already written

Each row below pairs a normative requirement from the specification with the procurement question it licenses. The middle column is the standard the vendor is being measured against; you are not asking for an opinion, you are asking whether a documented obligation is met. Answers that arrive as "yes, we support OAuth" to a question about audience validation are themselves informative.

4. Build, buy, or defer

Every requirement in the table above is something an in-house team could implement. The specification is public, the underlying mechanisms are ordinary OAuth, and organizations that already run an API gateway and an identity provider hold most of the pieces. So the honest build-versus-buy question is not whether you could build it, but whether the part you would be building is the part that is actually hard.

The hard part is rarely the first server. It is the tenth, and the governance surface around it: who approved this server's addition, which agents may reach which of its tools, whose identity is on the call when an agent acts, and how any of that is reconstructed six months later during an incident review. A gateway is a bet that this surface grows fast enough to be worth a dedicated control plane. If you are running one internal MCP server behind an existing API gateway, that bet is premature, and the specification's requirements are a checklist for your own implementation rather than a shortlist for procurement.

There is also a legitimate defer option that vendors will not raise. MCP is still changing shape — the current revision restructured the session model and deprecated a registration mechanism.^[1][3] Signing a multi-year agreement against a protocol revision that may be superseded inside the contract term is a real risk, and the mitigation is contractual rather than technical: ask what the vendor commits to on revision support, and how quickly past revisions were adopted.

5. Where a gateway is the wrong instrument

Two honest limits are worth stating before anyone signs. First, conformance is a floor, not a grade. A gateway that meets every requirement above has met the minimum bar the protocol sets for any compliant implementation; it has not thereby proven it is well-operated, well-supported, or a fit for your topology. Conformance sorts a shortlist and eliminates the unserious. It does not pick a winner.

Second, and more consequentially: a gateway can only enforce what passes through it. The specification's most severe attack class for many organizations is local MCP server compromise, where a developer's client executes a downloaded server binary with the developer's own privileges — the spec's illustration is a startup command that exfiltrates an SSH key.^[2] That traffic never touches a gateway. If your actual exposure is engineers wiring up local servers on laptops, the control you need is client configuration policy and endpoint management, and a gateway purchase will leave the real risk exactly where it was.

6. Reading what vendors disclose — and what they leave out

Enterprise MCP gateway pages are, at the time of writing, considerably less specific than the specification they implement. Reading the product pages of five enterprise gateway and control-plane vendors for our own catalog in August 2026, we found the same vocabulary throughout — role-based access control, audit trails, SSO, OAuth — and, across all five, no statement of which protocol revision the product targets and no mention of the audience-validation or issuer-validation requirements above. That is an observation about five pages on one date, not a market survey; the point is that the specific questions in this guide were not pre-answered by any of the marketing we read.

Treat that silence as information rather than as a defect. A page that does not mention deployment topology has not promised on-premise availability; a page that does not name a certification has not claimed one. The practical discipline is to record, per vendor, both what the page states and what it conspicuously does not, and to carry the second list into the vendor call as your agenda. A conformance question that a vendor cannot answer in the call is a finding, and it is a finding you obtained before signing rather than after.

7. Questions buyers actually ask

8. The takeaway

The reason to lead with conformance is not pedantry about standards. It is that this is a young category where marketing vocabulary has converged faster than implementations have, and the specification is the only shared, dated, falsifiable reference the whole market is measured against. Buying against it costs nothing, requires no benchmark you have to trust someone else to run, and produces questions vendors cannot answer generically.