Answers to common enterprise questions about MCP discovery, access control, federation, downstream OAuth, and observability. Can't find what you're looking for? Schedule a call.
An MCP gateway provides the endpoint AI clients use to discover and invoke MCP servers. Jarvis Registry combines that gateway role with a catalog of registered servers and their access settings.
Jarvis documents a single Registry Endpoint for clients to discover and invoke resources available to their authenticated users.
The MCP Gateway focuses on tool, resource, and prompt invocation against MCP servers. The Agent Gateway focuses on autonomous agents and agent-to-agent orchestration.
Both are part of Jarvis Registry and share identity, policy, and observability controls, but they operate on different runtime objects and invocation models.
The AgentCore federation documentation describes importing MCP servers and agents from AWS AgentCore. The Azure AI Foundry federation documentation describes importing agents.
The federation guides describe connecting to those external resources and applying the Registry sharing model after import; they do not document MCP-server federation from Azure AI Foundry.
The published integration guides document importing MCP servers and agents from AWS AgentCore, and agents from Azure AI Foundry, into Jarvis Registry.
Imported resources can be reviewed and shared using the Registry access model. The docs do not describe Azure AI Foundry MCP-server federation.
The MCP server registration guide lists no authentication, API key, and OAuth 2.0 as server authentication options.
For OAuth-protected servers, the registry documents storing downstream credentials and refreshing access tokens when needed.
The registry stores downstream OAuth credentials encrypted at rest and can refresh an expired or near-expiry access token. The calling copilot does not receive the raw credential.
The public documentation does not specify the encryption algorithm or document OAuth 2.1, PKCE, or RFC 8707 behavior for the MCP Gateway.
Jarvis Registry combines RBAC scopes with resource ACLs. The product FAQ describes access control down to individual MCP tools; resources default to private until they are shared.
The public security documentation describes authentication, endpoint scopes, and resource ACL checks. It does not establish a per-invocation audit stream.
The MCP Registry sharing documentation lists individual users, identity-provider groups, or all authenticated users as sharing targets.
Available permissions include VIEW, EDIT, and OWNER; users must be explicitly granted access unless the resource is published to authenticated users.
The observability guide documents OpenTelemetry and Prometheus metrics for registry operations, MCP discovery and execution, server requests, resource access, prompt execution, and latency.
Telemetry can be exported through the OpenTelemetry Collector to configured backends. The guide does not claim that MCP arguments, identity, or policy snapshots are recorded for each call.
Check that the user has the required access, the downstream credentials are valid, and the client can reach the gateway endpoint.
The Registry FAQ recommends checking authentication, ACL rules, network access, and service logs when an MCP client cannot connect.
Yes. An administrator can remove a user or group from a server’s sharing settings or change its visibility in the Registry.
The public documentation describes the available ACL controls but does not specify a propagation-time guarantee for revocation.
These are the deployment, transport, access, credential, federation, and observability details documented for the MCP Gateway.
| Specification | Value |
|---|---|
| Production deployment | Kubernetes on Amazon EKS or Azure AKS, according to the production deployment guide |
| MCP transports | HTTPStreamable and SSE |
| Downstream authentication | No authentication, API key, or OAuth 2.0 can be selected during server registration |
| OAuth credentials | Stored encrypted at rest; access tokens can be refreshed when expired or near expiry |
| Access model | Registry scopes and resource ACLs; resources are private by default until shared |
| Federation | AWS AgentCore documentation covers MCP servers and agents; Azure AI Foundry documentation covers agents |
| Observability | OpenTelemetry and Prometheus metrics for registry, authentication, and MCP activity |
| MCP activity metrics | Documented signals include discovery, tool execution, resource access, prompts, and latency |
A walkthrough of an MCP server connection through the gateway, including discovery and access checks.
The MCP Gateway provides a client-facing endpoint for registered MCP servers. These 6 rows summarize the documented deployment, access, credential, and observability behavior.
| Concern | Documented behavior |
|---|---|
| Discovery | The Registry Endpoint exposes the MCP servers an authenticated user is permitted to access. |
| Existing servers | Registration records the MCP server URL, transport, authentication type, and searchable metadata. |
| Authorisation | The registry supports OAuth 2.0 for downstream MCP servers and documents access-token refresh. |
| Transports | The MCP registration guide lists HTTPStreamable and SSE server transports. |
| Access policy | RBAC scopes and resource ACLs govern access; resources are private by default until shared. |
| Telemetry | OpenTelemetry and Prometheus cover platform and MCP activity metrics, including latency. |
Follow the documented deployment and Registry workflow to connect clients to approved MCP servers through one endpoint.
The gateway is where tool sprawl becomes a governed catalog: servers are discovered automatically, then exposed only through explicit policy.
The MCP Gateway is one part of Jarvis Registry. These pages explain related gateway, registry, and governance roles.
First-party product documentation for the capabilities described on this page.
Our team is happy to walk you through architecture, security, and pricing specific to your environment.
