What Is an MCP Gateway? Enterprise Evaluation Criteria

An MCP gateway is the inline control point that every Model Context Protocol tool call passes through between an AI client, such as Claude Desktop, Cursor, VS Code with GitHub Copilot or a custom agent, and an MCP server. On each call it resolves who is asking, checks whether that identity may use that tool, forwards the request with a credential the gateway holds rather than the user, applies rate limits, and writes one record of the outcome. This post follows one call through the gateway and turns each stage into an evaluation criterion; vendors appear only as documented examples, never as a ranking.

What Is an MCP Gateway?

The MCP specification names three participants: the host, the AI application that opens connections and coordinates the model; the client, which holds one session with one server; and the server, which exposes tools, resources and prompts. A gateway is a fourth role that platform teams add, by a common practitioner rule of thumb once three or more servers share an environment, because the protocol says nothing about which identities may reach which tool, where every invocation is recorded, or how a user’s credential stays out of the model’s context. The gateway gives those questions one auditable answer.

AWS documents AgentCore Gateway as one MCP endpoint in front of Lambda, OpenAPI, Smithy and existing MCP server targets, with inbound authorization in JWT, IAM or offloaded modes and a separate outbound credential per target. Microsoft documents Foundry Agent Service differently: remote MCP servers attach to agents as tools, each agent can carry its own Entra identity, on-behalf-of passthrough is available when configured, and a Toolbox republishes a curated tool set behind one managed MCP-compatible endpoint. Nothing there is marketed as a Microsoft MCP gateway; the Toolbox plus per-agent identity is the closest documented equivalent.

What Happens to One Tool Call Inside the Gateway

Suppose a release engineer asks an IDE assistant whether last night’s production deployment succeeded.

Inbound authorization. The first request either carries a bearer token or gets a 401 whose WWW-Authenticate header points at the gateway’s Protected Resource Metadata. Under the 2026-07-28 revision of the MCP authorization specification, servers must publish that metadata per RFC 9728, clients must send a resource indicator per RFC 8707, and servers must validate the token’s audience. A token minted for one server is therefore refused by another, and a gateway fronting both must preserve that boundary.

The diagram draws registration as dynamic client registration; the same revision names three client-registration mechanisms and deprecates that one, so ask which the gateway implements.

Connect and list. With the identity resolved, the client calls tools/list, and the gateway returns only the tools, resources and prompts that identity may see: get_deployment_status appears, trigger_rollback does not, because a model may attempt any tool it can see.

Policy decision. The gateway binds the requested tool name to the resolved identity and evaluates a rule, ideally one that also sees arguments and environment. AWS documents an attachable policy engine for AgentCore Gateway; others document expression rules keyed on tool name or per-tool access lists in plugin configuration.

Credential boundary. The inbound token should stop here; what goes downstream is a CI credential held by the gateway, or a token exchanged for this engineer and scoped to that pipeline. AWS’s AgentCore inbound-auth documentation calls passthrough not the recommended approach for production and points to on-behalf-of exchange for an audience-scoped token. Inbound user authentication and outbound system authentication are separate flows.

Forward and record. Some gateways document egress controls here (network allow-lists, secret detection, per-server resource caps); most document little. Then one structured line: the engineer, the assistant acting for them, get_deployment_status, the pipeline argument, the allow decision, and which CI credential was used.

MCP Gateway vs API Gateway, LLM Proxy, and MCP Registry

MCP gateway vs API gateway

An API gateway authorizes and routes HTTP at the endpoint level; an MCP gateway understands the protocol’s own methods, so tools/list, tools/call, resources and prompts are first-class objects and policy attaches to a tool, not a URL path. Two lineages meet in the category: API-management products that added MCP methods to an existing proxy (Kong, Tyk and Zuplo document this path) and designs built around MCP from the start (AWS AgentCore Gateway, open-source agentgateway, Docker MCP Gateway).

Is it a gateway or just a proxy?

Some products carry the label because they sit on the wire, not because they decide anything: an LLM proxy that logs MCP traffic can show every tools/call after the fact and still not stop one. Ask for the written form of a per-tool rule and where it is evaluated; a vendor whose only answer is a dashboard has shipped observability, not a gateway.

MCP gateway and MCP registry: two jobs, one control plane

The phrase MCP gateway registry usually names this pairing, not one product: the registry is the catalog and system of record for servers, tools, owners and approved versions; the gateway enforces that state on the live call. They form one control plane only when a revocation in the registry is refused at the gateway on the next request, not the next sync; our enterprise MCP registry architecture post covers the registry side. An MCP gateway is also the protocol-specific form of a broader agent gateway, sometimes marketed as an agentic gateway; see agent gateway vs API gateway for that layer.

MCP Gateway Evaluation Criteria for Enterprise Buyers

The six MCP gateway evaluation criteria below share one shape: a question to ask the vendor, the evidence that counts, and the evidence that does not.

Criterion	Question to ask	Evidence that counts	Evidence that does not count
1. Authorization conformance	Which spec revision and client registration mechanism?	RFC 9728 metadata, RFC 8707 audience validation, Client ID Metadata Documents, distinct 401 and 403 insufficient_scope	”Supports OAuth” with no detail; dynamic client registration headlined
2. Per-tool policy	Show one policy denying one tool to one group	Policy-as-code binding tool name to identity; denied tools absent from tools/list	Server-level allow or deny; static per-profile allow-lists
3. Credential brokering	Does the inbound token reach the upstream target?	Token exchange or gateway-held secrets, encrypted per-user storage, named downstream token	Passthrough as the default integration model
4. Tool integrity and blast radius	What happens when a tool description changes after approval?	Provenance checks, change detection, egress blocking, per-server resource caps	”We proxy the server” with no re-verification
5. Audit and observability	Send one structured log line for one tool call	Line naming human, agent, tool, arguments, decision, upstream credential; per-tool metrics; OpenTelemetry export	Dashboard screenshots; “complete audit trails”
6. Deployment and compliance	Which orchestrator, artifact and install path? Which certification, at what scope?	Helm, Kubernetes or on-premises document; named program with report type and boundary	”Self-hosted or cloud” as a phrase; company-level certifications with no scope

1. Authorization that matches the current MCP spec

The current revision allows Client ID Metadata Documents, pre-registration and dynamic client registration, marking the last deprecated; a checklist that leads with it is a revision behind. Evidence is a metadata document you can fetch, a WWW-Authenticate challenge carrying resource_metadata and scopes, and a 401 for a missing token versus a 403 with insufficient_scope.

2. Per-tool policy bound to caller identity

Server-level allow and deny cannot express the first rule most teams write: read a deployment’s status, but never trigger a rollback. Ask to see the rule in its native form, then watch it applied: the tool should vanish from tools/list for the denied group, not merely fail on invocation. Static per-profile allow-lists are deployment-time settings, not identity-aware authorization.

3. Credential brokering, not token passthrough

Once a vendor confirms the inbound token never reaches the upstream target, ask what is minted instead, how it is scoped, and where upstream secrets live, ideally encrypted at rest and keyed per user. If nobody can name the credential that reached the SaaS tenant, or who authorized it, the gateway adds latency without adding a boundary.

4. Tool-description integrity and blast radius

Tool descriptions reach the model as prompt text. Invariant Labs documented tool poisoning in April 2025: instructions hidden in a description, invisible to the user but visible to the model, plus shadowing and rug pulls, where a description changes after approval. Ask whether the gateway verifies server provenance, detects such changes, and can block a tool’s outbound network access. Expect thin answers, and budget to build change detection yourself.

5. Audit evidence and per-tool observability

The bar is one structured record per tool call, not the phrase “audit trail.” Ask for a sample line and its schema naming human, agent, tool, arguments, policy decision and upstream credential, and for latency, error rate and volume per tool, not proxy-level uptime. OpenTelemetry export is the portable baseline.

6. Deployment model and compliance artifacts

The deployment model must be a document naming orchestrator, artifact and install path, not the phrase “self-hosted or cloud.” A compliance claim needs a named program, report type and scope; a certification covering the vendor’s managed infrastructure may say nothing about a plane you host.

Enterprise MCP Gateways in Regulated Industries

Enterprise MCP gateways for regulated industries in the US get bought in one of four situations; settle hosting before any feature comparison.

• Residency decides first. Require a self-managed path documented well enough to build from, typically Helm on Kubernetes or on-premises; hyperscaler-managed gateways are usually excluded by residency, not features.
• You already own a gateway vendor. The native option is usually fastest through procurement; check license and edition prerequisites first.
• Procurement needs a report, not a promise. Ask for the current report and its scope, or a written statement that none exists.
• You are pricing the exit, not the entry. Open-source or foundation-governed gateways transfer integration and attestation work to your team.

Federation cuts across all four. A single-cloud estate can adopt that cloud’s gateway and stop; a hybrid or multi-cloud estate must choose between one gateway per provider, with policy and logs reconciled by hand, and one federating policy surface with a single audit trail, the pattern ASCENDING documents on its AgentCore and Foundry federation page. Finally, only the gateway sees caller, tool, decision and downstream credential together, so its log is what a reviewer will request a year later; verify retention and export during evaluation.

Red Flags That Should End the Evaluation

Stop if any of these is true:

• Passthrough is the default: the caller’s token reaches the upstream unchanged, with no documented exchange or gateway-held-secret alternative.
• Policy stops at the server boundary: rules can allow or deny a whole server but cannot name a tool.
• “Self-hosted” is the whole deployment story: no orchestrator, artifact or install procedure an architect could reproduce.
• No sample record: asked for one structured log entry for one tool call, the vendor offers a screenshot.
• Descriptions pass through untouched: nothing verifies a tool definition’s origin or notices when it changes after approval.

One more applies to vendor-authored comparisons, ASCENDING’s included: if the publisher wins every row, treat it as marketing until each row cites a document you can open.

Where Jarvis Fits, and What to Verify

Jarvis is ASCENDING’s own product, so read this section as a vendor statement and apply the same evidence requests. Jarvis Registry is positioned as a combined MCP registry and gateway, with RBAC and per-tool ACLs evaluated on each invocation. The Jarvis MCP Gateway page documents those policies applied across self-hosted, AgentCore and Azure AI Foundry servers, RFC 8707 resource indicators validated per token, SAML 2.0 and OpenID Connect federation, per-user OAuth tokens encrypted at rest and injected into outbound calls, OpenTelemetry traces carrying tool, identity and a policy snapshot, and deployment on EKS, AKS and GKE.

Two gaps, stated plainly: the Jarvis pages publish no SOC 2, HIPAA or FedRAMP attestation for Jarvis Registry, and nothing here implies one; and they describe mechanisms without a log schema, a token-exchange trace or a client-registration mechanism, so request those artifacts and confirm any hybrid or on-premises path in writing. An open-source baseline lets a team inspect the resource-aware OAuth handling before buying. ASCENDING’s own enterprise MCP gateway comparison is framed as a scope comparison, not a ranking, but it is vendor-published, so apply the last red flag and open each cited page before scoring a row.

How to Run the Evaluation

Budget about two weeks for a proof run against your own identity provider and servers, not a vendor sandbox:

1. Connect one real client as two identities and diff the tools/list responses.
2. Capture the request that reaches an upstream server and confirm which credential arrived.
3. Request the structured audit line for that call and map its fields to your evidence needs.
4. Change a tool description upstream and observe whether the gateway notices.
5. File the deployment document and certification statement with procurement, or record that neither exists.

For the protocol-versus-pattern primer, start with MCP vs RAG. Teams evaluating a customer-hosted MCP gateway across AWS and Azure can ask ASCENDING for a scoped evaluation through the contact page.

References

• Model Context Protocol. “Authorization (revision 2026-07-28)”.
• IETF. “RFC 8707: Resource Indicators for OAuth 2.0”.
• IETF. “RFC 9728: OAuth 2.0 Protected Resource Metadata”.
• AWS. “Set up inbound authorization for your gateway”.
• Microsoft Learn. “What is Microsoft Foundry Agent Service?”.
• Invariant Labs. “MCP Security Notification: Tool Poisoning Attacks”.
• GitHub. “ascending-llc/jarvis-registry”.

FAQ — MCP Gateway Questions Buyers Ask

What is an MCP gateway?

An MCP gateway is the inline control point that every Model Context Protocol tool call passes through on its way from an AI client to an MCP server. It authenticates the caller, decides per tool whether that identity may invoke it, swaps the inbound token for a downstream credential the user never handles, routes and rate-limits the call, and writes one structured record of what happened. The MCP specification defines clients, servers and hosts; the gateway is a role that production deployments added once teams were operating more than a handful of servers.

Is an MCP gateway the same as an API gateway?

No. An API gateway routes and authorizes HTTP requests at the endpoint level. An MCP gateway understands the protocol's own methods, such as tools/list and tools/call, and enforces policy at the individual tool level, filtering what each identity can even see. Several API-gateway vendors have added MCP support, so the practical test is whether the product can show a written policy that denies one tool to one group and hides it from the tool list, not whether the word gateway appears on the box.

Do I need both an MCP gateway and an MCP registry?

For any estate beyond a pilot, usually yes, and they are different jobs. The registry is the catalog and system of record: which servers and tools exist, who owns them, which version is approved. The gateway is where that state is enforced on the live call. What matters in evaluation is how the two connect: a revoked tool or deprecated version should stop being callable on the next request, not after the next sync interval. Our enterprise MCP registry architecture post covers the registry side in depth.

Does Microsoft have an MCP gateway?

Microsoft's documented equivalent lives in Foundry Agent Service rather than under the name MCP gateway: remote MCP servers are added to agents as tools, each agent can have a dedicated Entra identity, OAuth on-behalf-of passthrough is supported when configured, and a Toolbox can share a curated tool set through one managed MCP-compatible endpoint. Because feature names and preview status change, verify the current documentation on Microsoft Learn before treating it as an enterprise-ready MCP gateway.

What should regulated industries in the US look for in an enterprise MCP gateway?

Four things decide most regulated evaluations: a self-managed deployment path documented well enough to pass a data-residency review (orchestrator, artifact, install method), a certification artifact with a stated report type and scope or a plain statement that none exists, an audit record that names caller, tool, arguments, policy decision and downstream credential for every call, and a clear answer on federation if your MCP servers span more than one cloud. Hyperscaler-managed gateways are usually excluded by residency rather than by features, so settle the hosting question first.

When do you actually need an MCP gateway?

A common rule of thumb is that once three or more MCP servers share an environment, per-server OAuth and ad hoc logging stop scaling and teams end up rebuilding gateway functions by hand. The better trigger is the first time someone asks who is allowed to call which tool, where every call is logged, or how a user's credential reached a downstream SaaS system. If those questions have no single answer, you need a gateway, whether you buy one or build one.