An MCP gateway is a runtime control point between AI clients and MCP servers for traffic routed through it. Products can centralize identity, tool-level authorization, credential handling, routing and telemetry, but the implemented controls depend on configuration. Test the approved route and any path that could bypass it. This post follows a proposed call flow and turns each stage into an evaluation criterion; documented vendor examples aren’t a ranking.
Original evaluation checked October 7, 2026; Jarvis claims and audit-evidence guidance rechecked October 19. Confirm deployed versions and implementation details during procurement.
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. Request correlated evidence of the engineer, assistant, tool, access decision and downstream result. Use safe credential references, never credential values, and avoid unnecessary argument capture. Confirm which component supplies each fact rather than assuming one gateway record contains everything.
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). Teams already on Docker’s local gateway can compare five enterprise migration paths, two of which keep Docker in the stack.
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. For where model-side controls end and tool-side controls begin, see MCP gateway vs LLM gateway. 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. Our MCP gateway buyer’s guide shows how to test where policy is enforced, whatever the product is called.
Open-Source vs. Managed MCP Gateways for Enterprises
Open source describes how software is licensed and inspected; managed describes who operates the service. They are not strict opposites: open-source software can be vendor-hosted, and a managed offering can provide a customer-controlled deployment. Compare the operating boundary and evidence, not just the label.
| Decision area | Open-source, self-managed option | Managed service | What to verify |
|---|---|---|---|
| Operations | Your team deploys, patches, scales and responds to incidents | The provider operates some or all of the gateway runtime | Responsibility matrix, support hours, escalation path and upgrade controls |
| Customization | Source may be inspectable or modifiable, subject to the license and project | Configuration and extension points depend on the provider | Which policies and integrations are configurable, and whether changes survive upgrades |
| Data boundary | You choose where the runtime runs, but telemetry or dependencies may still send data elsewhere | Requests, logs or credentials may cross a provider boundary | Data-flow diagram, telemetry controls, credential handling and residency terms |
| Security evidence | Your team owns dependency review, patching and deployment evidence | The provider may supply independent reports for a defined service scope | Current report, covered components, customer responsibilities and exclusions |
| Availability | Your team owns capacity, backup and recovery unless separately contracted | The provider may operate availability and recovery controls | Published SLO, maintenance policy, recovery objectives and incident history |
| Total cost | License cost can be low or zero; engineering, infrastructure and on-call still cost money | Subscription or usage charges may include operations and support | Three-year cost, usage limits, support tier, egress charges and exit effort |
For a regulated or private-hosting requirement, ask where the control plane, tool traffic, credentials and audit records live. For a small platform team, managed operations may reduce maintenance work, but only if the service’s identity and policy model meets your requirements. A self-managed option offers more direct operational control, not automatic security or compliance.
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 | Show records for an allowed, denied and failed call | Correlated identity, tool, decision and outcome; safe authentication reference; coverage and export tests | Dashboard screenshots; “complete audit trails”; raw credentials or indiscriminate payload capture |
| 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. Which registration path works also depends on your identity provider: our MCP OAuth setup guide compares what Entra ID and Okta advertise.
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.
For Claude Code deployments, pair these gateway checks with the managed settings and SSO rollout guide. Client policy governs which tools the agent may attempt; gateway and destination authorization must still decide whether the current caller may perform the requested operation.
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.
The tool-definition change-review checklist turns this into a scoped test: compare a harmless change, record approval and verify release or withdrawal across sessions.
5. Audit evidence and per-tool observability
Ask for sanitized records that connect identity, tool, policy decision and execution result. Keep safe credential references separate from secrets, and collect payloads only for an approved purpose. Per-tool latency and volume are useful metrics, but don’t establish individual audit events. The MCP audit evidence guide provides a field worksheet and tests for denied calls, timeouts and collection failures.
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. For a SOC 2 report, check which system and responsibilities it actually covers.
- 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. Compare separate cloud control points with a shared catalog and access layer, as described on ASCENDING’s AgentCore and Foundry federation page. Verify supported resource types and how evidence connects across boundaries. A gateway may record its access decision without observing the final downstream business effect. Confirm correlation, retention and export across all participating systems.
Healthcare teams can make the proof run concrete with an AI insurance eligibility verification workflow: permit the lookup, preserve the payer response, and test who can approve the downstream update. For a separately selected voice service, use the payer-call evidence and human-handoff requirements to test callbacks and reviewer access. These are implementation scenarios to validate, not capabilities implied by the presence of an MCP gateway.
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 an open source project built and maintained by ASCENDING Inc, so apply the same evidence requests to our product. Jarvis Registry combines a resource catalog with runtime access controls. The MCP Gateway page documents permission-scoped discovery, RBAC/resource ACLs and encrypted downstream OAuth credential storage with refresh. AgentCore federation imports MCP servers and agents; the Azure AI Foundry integration documents agents.
Jarvis’s observability documentation describes platform metrics and agent LLM traces, not a complete per-call policy-snapshot audit schema. Request deployment evidence for identity, decision and outcome fields. Review configured telemetry destinations separately from where the gateway runs.
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.
MCP Gateway Buyer Checklist: How to Run the Evaluation
First, find the MCP servers your teams run without approval, so the proof run covers the clients and servers people actually use.
Budget about two weeks for a proof run against your own identity provider and servers, not a vendor sandbox:
- Connect one real client as two identities and diff the
tools/listresponses. - Capture the request that reaches an upstream server and confirm which credential arrived.
- Request the structured audit line for that call and map its fields to your evidence needs.
- Change a tool description upstream and observe whether the gateway notices.
- File the deployment document and certification statement with procurement, or record that neither exists.
Once you have chosen an enforcement point, the MCP governance checklist covers the controls around it: inventory, approval, owners and review. 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”.
- Jarvis Registry. “Observability”.
FAQ — MCP Gateway Questions Buyers Ask
What is an MCP gateway?
An MCP gateway is a runtime control point between AI clients and MCP servers for traffic routed through it. Authentication, tool-level authorization, credential handling, limits and telemetry depend on the product and configuration. Verify those controls and test direct paths that could bypass the gateway.
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.
What should regulated industries in the US look for in an enterprise MCP gateway?
Check the documented deployment and data flows, the scope of any independent assurance reports, the available audit evidence and the resource types supported by federation. Audit records should identify the caller, tool, decision and outcome without exposing credentials or unnecessary sensitive payloads. Validate each requirement against your deployment rather than inferring compliance from a hosting label.
Should an enterprise choose an open-source or managed MCP gateway?
Choose based on who should operate the gateway and where requests, credentials and audit records may flow. Open-source, self-managed options put deployment and on-call responsibility on your team; managed services may reduce that work but require review of provider access, data flow, service scope and exit terms. The labels alone do not establish security, compliance or hosting boundaries.
