What is an MCP gateway?
An MCP gateway is the enforcement layer every Model Context Protocol tool call passes through with authentication, policy checks, routing, and observability.
Concepts
Customer-Hosted Enterprise MCP Gateway & Server Registry
Jarvis is an enterprise MCP gateway and server registry that runs in your AWS or Azure environment to discover, authorize, route, and observe every approved tool call. Connect MCP servers and AI clients through one customer-controlled, policy-enforced endpoint.
Components
What's Inside the MCP Gateway
Five core components work together to make every MCP server in your enterprise discoverable, governed, and ready for any AI client or copilot.
Auto-Discovery
Every registered MCP server and its tools discovered via one endpoint - permission-scoped so each AI client sees exactly what it can invoke.
Federation Layer
Cross-cloud MCP registry federation importing servers from AWS AgentCore and Azure AI Foundry into one governed MCP server namespace - no redeployment.
Egress Authentication
Per-user OAuth lifecycle management - tokens encrypted at rest, silently refreshed, and isolated per MCP server per user.
Governance Layer
RBAC scopes and per-tool ACL policies enforced at the MCP gateway uniformly across self-hosted, AgentCore, and Azure AI Foundry MCP servers.
Identity & Observability
On-behalf-of identity propagated through every nested MCP server tool call. OTEL-native traces record tool, identity, and policy snapshot per invocation.
Features
Enterprise-Grade MCP Gateway Capabilities
Everything you need to discover, govern, secure, and observe every MCP server tool call across your enterprise AI stack.
01—Auto-Discovery
One Endpoint. Every MCP Server Auto-Discovered.
Connect any AI copilot or MCP client to a single authenticated gateway endpoint and get automatic discovery of every registered MCP server and its tools - no per-client configuration, no manual server lists. The MCP registry surfaces only the tools each identity is permitted to invoke, giving every client a permission-scoped view of your entire MCP server catalog.
02—Governance Layer
RBAC and ACL Across Every MCP Server
Define role-based access control scopes and per-tool ACL policies that apply uniformly across every MCP server in the catalog - whether self-hosted, federated from AWS AgentCore, or imported from Azure AI Foundry. The MCP gateway enforces policy on every tool call at the gateway layer, not inside individual MCP servers.
03—Identity & Observability
Identity-Bound Calls, Traced End to End
User identity propagates through every nested MCP server tool call so each server in the chain sees who initiated the request. An integrated OTEL collector records the resolved MCP tool, arguments, identity, and policy snapshot on every invocation - ship to Datadog, Grafana, or any OTLP backend without touching your MCP servers.
04—Ingress Auth Conformance
OAuth 2.1 with RFC 8707 Resource Indicators
Every MCP server is an OAuth 2.1 resource server. The MCP gateway sits in front as the protected-resource enforcement point - PKCE mandatory, RFC 8707 resource indicators validated on every token so a credential minted for one MCP server cannot be replayed against another. MCP gateways that haven't implemented RFC 8707 are a full spec revision behind.
05—Egress Authentication
Per-User OAuth Lifecycle Management
The MCP gateway manages the full OAuth credential lifecycle on behalf of each user - tokens are issued, encrypted at rest with AES-256, silently refreshed before expiry, and injected into outbound MCP server calls without ever being surfaced to the calling client. Each user's credentials are isolated per downstream MCP server, so a token compromise is contained to a single server and a single identity.
Multi-Cloud Federation
One MCP Registry Across AWS and Azure
MCP servers deployed in AWS AgentCore and Azure AI Foundry are imported into the Jarvis MCP registry, governed under your access policies, and exposed through a single MCP gateway endpoint - no redeployment, no duplicated infrastructure.
☁ AWS AgentCore
AWS AgentCore Federation
MCP servers deployed in AWS AgentCore are imported into the Jarvis MCP registry, governed under your access policies, and exposed through a single MCP gateway endpoint - no redeployment, no duplicated infrastructure.
- ✓Cross-account IAM via assume-role for secure MCP server discovery across AWS accounts
- ✓Automatic catalog sync brings AgentCore MCP servers into the Jarvis MCP registry
- ✓Inherited governance same RBAC, ACL, and audit trail as native MCP servers
- ✓No redeployment MCP servers continue running inside AgentCore
◈ Azure AI Foundry
Azure AI Foundry Federation
Bring Foundry-hosted MCP servers into the same governed registry as your AWS-native and self-hosted MCP servers. Jarvis handles discovery, lifecycle sync, and access control across the Azure tenant boundary.
- ✓Tenant-scoped discovery across subscriptions and resource groups
- ✓Unified catalog Azure MCP servers alongside AWS and self-hosted servers
- ✓Cross-cloud RBAC applied uniformly regardless of MCP server origin
- ✓One endpoint for all AI clients regardless of which cloud hosts the MCP server
Integrations
Works With Every AI Copilot and MCP Client
Jarvis Registry acts as the universal MCP gateway - connecting any AI client to every registered and federated MCP server through one endpoint.
Claude Desktop
Chat Copilot
Claude Code
Coding Copilot
VS Code
IDE
Cursor
IDE
GitHub Copilot
Coding Copilot
Microsoft Copilot
Enterprise
Windsurf
IDE
Jarvis Chat
Chat Copilot
ChatGPT
Chat Copilot
Custom Clients
Custom App
Ready to Govern Every MCP Tool Call?
See how Jarvis Registry brings enterprise-grade MCP gateway governance, MCP server registry management, and full observability to your AI stack.
MCP Gateway at a glance
The MCP Gateway is the component of Jarvis Registry that fronts Model Context Protocol servers, turning scattered tool integrations into 1 governed endpoint. These 6 rows cover the facts that decide whether it fits an existing estate.
| Concern | How the gateway handles it |
|---|---|
| Discovery | One endpoint publishes every approved MCP server, so a client integrates once instead of once per server. |
| Existing servers | Servers stay where they are — registration is configuration only, with no redeploy and no protocol shim. |
| Authorisation | OAuth 2.0 with resource indicators (RFC 8707), so a token issued for 1 server is not replayable against another. |
| Auth elicitation | Supported, so a tool can request a downstream credential mid-session instead of failing the call outright. |
| Access policy | Per-tool ACL entries evaluated on every invocation, layered on top of Azure EntraID roles. |
| Telemetry | An OpenTelemetry collector records each call, its policy decision, and its latency for troubleshooting and audit. |
MCP Gateway technical specifications
The gateway stands or falls on its authorisation model, because it holds credentials for many downstream servers. These rows name every specification involved so that model can be reviewed rather than assumed.
| Specification | Value |
|---|---|
| Protocol | Model Context Protocol (MCP), published November 2024, over JSON-RPC 2.0 |
| Integration surface | 1 endpoint per client instead of 1 integration per MCP server |
| Server redeploys required | 0 — registration is by endpoint, servers keep their runtime |
| Base authorization | OAuth 2.0 (RFC 6749), Bearer usage per RFC 6750 |
| Token scoping | Resource Indicators (RFC 8707) — a token for 1 server is not replayable at another |
| Delegation | OAuth 2.0 Token Exchange (RFC 8693) |
| Public-client flows | PKCE (RFC 7636) |
| Token format | JSON Web Token (RFC 7519), signed per RFC 7515 |
| Auth elicitation | Supported — a tool can request a downstream credential mid-session |
| Identity federation | OpenID Connect Core 1.0 and SAML 2.0 |
| Access model | Per-tool ACL evaluated on every invocation, layered on RBAC roles |
| Transport security | TLS 1.2 minimum, TLS 1.3 preferred (RFC 8446) |
| Telemetry | OpenTelemetry OTLP — call, policy decision, and latency per invocation |
| Denial responses | HTTP 401 unauthenticated, HTTP 403 policy denial, HTTP 429 rate limited |
| Zero-trust reference | NIST SP 800-207 (2020) |
| Runtimes | 3 managed Kubernetes services — Amazon EKS, Azure AKS, Google GKE |
Watch MCP in practice
A 3-minute demonstration of what changes when a copilot reaches enterprise context through a governed MCP endpoint rather than a direct per-server integration.
How to put a gateway in front of your MCP servers
Adoption does not require touching the MCP servers themselves, which is why most teams complete these 5 steps inside a single change window rather than as a migration project.
- Deploy the gateway. Install Jarvis Registry into an existing Kubernetes namespace on Amazon EKS, Azure AKS, or Google GKE.
- Register the servers. Add each running server to the catalog by endpoint; it keeps its current host, runtime, and release cycle.
- Configure OAuth. Issue resource-scoped tokens per RFC 8707 so downstream credentials cannot be reused across tools.
- Scope the tools. Write ACL entries exposing each tool to the specific teams that need it, and nothing wider.
- Point clients at one endpoint. Repoint copilots and agents at the gateway URL, then confirm the OTEL trace shows the expected decisions.
Governance and discovery in practice
A gateway is where tool sprawl becomes a governed catalog: servers are discovered automatically, then exposed only through explicit policy.
Frequently asked questions
The questions below separate a gateway that fits an existing MCP estate from one that would require rebuilding it.
What is an MCP gateway?
It is a single governed endpoint in front of many Model Context Protocol servers. Clients discover and invoke tools through it rather than integrating with each server individually.
The practical effect is that access policy, authorisation, and audit are implemented once at the gateway instead of being re-implemented in every server and every client.
Do we need to redeploy our MCP servers?
No. Servers keep their current host, runtime, and release cadence. Registration adds a catalog entry pointing at the endpoint they already expose.
That is what makes adoption a change-window task rather than a migration programme.
Why does RFC 8707 matter here?
Resource indicators bind a token to the specific resource it was issued for, so a credential minted for 1 MCP server cannot be replayed against a different one.
Without that binding, a gateway that holds credentials for many servers becomes an attractive single point of compromise rather than a control point.
What is auth elicitation and why does it help?
It lets a tool request the downstream credential it needs during a session instead of failing the call because a credential was not provisioned in advance.
For enterprise estates where different tools authenticate against different systems, that is often the difference between a workable integration and a brittle one.
Related Jarvis resources
The MCP Gateway and the Agent Gateway are the two halves of Jarvis Registry. These pages cover each in more depth.
- MCP Gateway FAQ — discovery, OAuth, auth elicitation, and federation questions in depth.
- Jarvis Registry — the catalog and platform the gateway belongs to.
- Agent Gateway — the agent-side counterpart covering registration and routing.
- Jarvis Knowledge Base — enterprise retrieval exposed through the gateway as a governed tool.
- Governed AI overview — identity, privacy, and observability across every layer of execution.
Standards and references
ASCENDING is an AWS Advanced Tier Services Partner with the AWS Generative AI Competency, and builds Jarvis as licensed software that runs inside your own cloud account. These are the documents worth reading before an architecture review.
- Model Context Protocol (MCP) — the specification the gateway proxies and governs.
- RFC 8707 — Resource Indicators for OAuth 2.0 — why a token minted for one server cannot be replayed against another.
- Amazon EKS documentation — the most common runtime for a self-hosted gateway deployment.
- OpenTelemetry specification — the trace format the built-in collector emits.
ASCENDING empowers businesses with AI-driven solutions and cloud transformation strategies. Unlock innovation, scalability, and efficiency with our expert services in AI, cloud migration, and digital modernization.