An enterprise MCP registry is a catalog of internal MCP servers, their owners and the rules for sharing them. A gateway checks requests when clients use those servers. Jarvis Registry is one customer-hosted option for those jobs. The full design must also cover business-system permissions, changes and evidence.
A product may package the registry and gateway together. Keep their jobs clear: the catalog records what is approved; the runtime path must enforce the access rules. A catalog entry alone does not block a call.
Hero illustration: example catalog entries and counts, not a record of a deployed environment.
When does an enterprise need a private MCP registry?
Use a private registry when teams need to share internal servers, assign owners and review changes in one place. A public listing does not supply that process. For an isolated prototype, a maintained client config may meet the need. Reassess it when the team cannot manage access or changes reliably.
| Situation | What to evaluate |
|---|---|
| Publicly accessible server metadata for developer discovery | A public catalog or aggregator; inspect its authenticity and review process |
| Private endpoints used by multiple teams or AI clients | A private catalog with owners, identity-filtered discovery and an enforced runtime path |
| Different write rights for people using the same server | The downstream and gateway authorization design, not catalog membership alone |
| Evidence for an access or compliance review | Correlated operational records and tested retention/export; a catalog or metrics dashboard is insufficient |
How Jarvis supplies the private catalog
Jarvis Registry combines a private MCP catalog with a gateway for permitted requests. Its MCP server guide describes registering a reachable server, its transport and authentication method. The resource owner then shares access with the intended users or groups.
Compatible clients connect through the Registry Endpoint using the configuration generated for their deployment. Discovery applies endpoint scopes and resource ACLs, so different users can receive different server results. The server’s runtime and business-system credentials still need their own owners.
For the invoice-server example below, first decide which teams may discover and access the server. Then test the required read and update restrictions in the complete request route. Server access alone does not establish those operation-level rights. Use the two-user access walkthrough to begin that check, and retain the business-record tests alongside it.
Last verified: October 28, 2026. The six layers below are evaluation requirements. They are not a claim that every listed control is built into Jarvis or every other registry.
The Short Architecture
A production design has six responsibilities:
- Inventory and discovery: Catalog MCP servers, tools, owners, environments, versions, and approval state.
- Identity: Preserve the identity of the user, workload, or agent requesting access.
- Policy: Decide which identities can discover and invoke each server or tool.
- Runtime enforcement: Apply that decision at a gateway before the downstream call runs.
- Lifecycle: Approve, update, deprecate, roll back, and retire capabilities without leaving stale routes.
- Observability and audit: Record the caller, tool, policy decision, result, latency, and failure path in a system the organization can query.
The official MCP Registry is a public catalog of public servers. Its guide recommends a private registry for private servers. That solves the listing choice. The access and operating model still need a design.
Registry and Gateway Are Different Jobs
An MCP registry records the tools and servers a team manages. An MCP gateway is a runtime entry point between clients and servers. Test which rules it enforces on the actual request path.
| Control point | What it stores or does | Example decision |
|---|---|---|
| Private MCP registry | Server and tool metadata, owner, environment, approval, version, and lifecycle state | “This Jira server is approved for production and owned by Platform Engineering.” |
| MCP gateway | Authentication, authorization, routing, credential handling, and tool-call telemetry | “This user may invoke search_issues, but not delete_issue.” |
| Agent registry | Agent identity, owner, version, approval, and deprecation state | “Version 4 of the support agent is approved; version 3 is retired.” |
| Agent gateway | Runtime policy and routing for agent-to-agent calls | “This workflow may invoke the approved finance agent in Azure.” |
AWS’s MCP hosting guide describes gateways as central proxies that manage access to registered servers. Microsoft’s API Center inventory and AI Gateway controls also separate inventory from runtime controls. Check both jobs when comparing products.
This avoids comparing unlike products. A public catalog, an API gateway plugin and a private registry may cover different parts of the same workflow.
Layer 1: Governed Discovery
Start discovery with a server record that clients can read. Show each caller only the resources their access rules permit.
A useful record normally includes:
- server name and description;
- owner and support contact;
- environment and endpoint;
- tools and input schemas;
- authentication method;
- risk or review status;
- approved version and deprecation state;
- policy references;
- last validation time.
An approved tool may still be private to one team. Even its name or description can reveal sensitive work. Filter discovery before the client builds its tool list.
This gives teams a place to find reviewed servers. Servers outside that catalog still need separate discovery and runtime controls. A private listing does not find or block every unapproved endpoint by itself.
Layer 2: Identity Through the Full Call Chain
Follow identity beyond the person who opened the chat. A call may pass through an AI client, an agent, a gateway and several tools. Each hop needs the right credential.
The architecture should define:
- how the user or workload authenticates;
- whether the original identity is preserved or exchanged;
- which service receives which credential;
- how short-lived tokens are issued and refreshed;
- how access is revoked when a role or employment status changes;
- how the audit trail correlates every hop.
RFC 8707 defines OAuth resource indicators. They let a client name the protected resource it wants to access. Test that flow with the actual client, server and identity provider. Sharing an OAuth label does not prove that their settings work together.
Layer 3: Policy That Reaches the Tool
Server-level access is often too broad. A team may be allowed to search a ticket system without being allowed to delete a ticket, change an assignee, or export an attachment.
An enterprise policy model should be able to combine:
- roles and groups;
- individual or workload identity;
- environment;
- server and tool;
- data classification;
- approval state;
- time or session context;
- downstream authorization.
Check access close to the tool call and record which policy applied. Security and engineering teams then have a way to explain why a request passed or failed.
Jarvis documents three separate controls. Application roles allow Registry actions. Resource ACLs grant access to a server. The disabled-tools list switches tools off for all users of that server through normal discovery and execute_tool.
The tool-enablement contract says the transparent proxy does not enforce that list. If people need different tool rights, test how the complete design enforces them. The server-wide switch does not establish per-user tool policy.
NIST SP 800-207 supplies the broader zero-trust principle. Base access on the resource and identity; do not grant it merely because a request came from the company network.
Layer 4: Runtime Enforcement and Credential Boundaries
The runtime route puts the design to work. It must check the caller, find the server and tool, and apply the access rule. It then needs a valid downstream credential to send the request. Decide where the outcome will be recorded.
Map where data goes, even with a customer-hosted gateway. A model provider or SaaS tool may still receive part of a request. Show each external destination, the credential used and any retained data on the production diagram.
Useful proof tests include:
- Invoke an allowed tool as an approved user.
- Invoke a blocked tool using the same identity.
- Revoke access and repeat the call.
- Update or deprecate the server version and observe propagation.
- Trace the full call in the organization’s monitoring system.
Ask each vendor to show those cases with your identity and tool stack. Start a Jarvis resource-access test with the two-user MCP walkthrough. Then test the real business system separately. A harmless sample call does not prove access rules for business records or a completed customer deployment.
Layer 5: Lifecycle and Change Control
The design must handle changes after a server is first listed.
For every server, tool, or agent, define:
- who can submit it;
- who reviews security and ownership;
- how versions are promoted;
- which clients receive the new version;
- how a change is rolled back;
- what deprecation means for active workflows;
- when credentials and routes are removed.
AWS’s Agent Registry guide describes curation and approval workflows. Apply that principle to your own registry too. Discovery should reflect the version approved for use, not merely the latest endpoint added.
Layer 6: Observability and Audit
An MCP audit record should help a reviewer trace a call across systems. Agree which fields are needed to explain its outcome.
At minimum, correlate:
- initiating user, workload, or agent;
- client and session;
- selected server and tool;
- policy decision and policy version;
- credential or authorization method without logging secrets;
- request and response status;
- latency, retries, and failure reason;
- downstream agent or tool hops.
OpenTelemetry provides a vendor-neutral way to collect traces, metrics and logs. It does not decide which identity or policy fields your app records. Use stable identifiers to link the caller, policy, server and tool across those records.
These are requirements to test, not fields every product emits. Jarvis’s observability guide separates platform metrics from agent LLM traces. It does not establish a complete per-call audit schema. Use the MCP audit evidence tests to find available records, missing fields and downstream results.
Example Decision: Finance and Support Share an Invoice Server
Consider a proposed design, not a reported deployment. Finance needs to update invoices; Support needs to search only the invoices it may see. Both teams use the same MCP server.
The catalog needs an owner, an approved version and the intended audience. Server access lets a user reach that resource. It does not prove that Support cannot run an update tool or read another team’s invoice.
For Jarvis, a server-wide disabled-tool switch cannot give Finance an update right while denying it only to Support. The team must show a separate access design for that split. It must also test the credentials and record rules in the invoice system.
The decision is concrete: accept the design only after an explicit forbidden update and restricted-record lookup fail as intended. Record which component blocks each request. Use those results to decide what the existing stack covers and where another control is needed.
Multi-Cloud Does Not Mean One Giant Catalog
A multi-cloud registry can share metadata while servers keep running in their current clouds. Decide which system owns each record and where access is enforced. You do not need to move every workload into one runtime to build that view.
For example, a company may keep agents in AWS AgentCore and Azure AI Foundry, with internal MCP servers on Kubernetes. Its registry can share approved metadata. The gateways still need to enforce access at the relevant cloud and service boundaries.
The key design questions are:
- Which system is authoritative for ownership and lifecycle?
- How quickly do updates and revocations propagate?
- Which cloud identity is exchanged at each boundary?
- Does the audit trail correlate calls across clouds?
- Can a client discover only what its identity may use?
ASCENDING documents its implementation of this pattern on the Jarvis AWS and Azure federation page.
For a healthcare example, use insurance eligibility verification to test lookup and update rights separately. A payer-call evidence handoff adds a delayed-result check. The returned result must keep its job identity and reach a reviewer with the right access.
An Enterprise MCP Registry Implementation Checklist
Before selecting a platform or approving an internal build, require a written answer for each item:
- Scope: MCP servers only, or tools, agents, skills, and workflows too?
- Hosting: Managed, customer-hosted, hybrid, or cloud-specific?
- Inventory: How are capabilities registered, synchronized, and removed?
- Identity: Which IdPs, clients, users, and workloads are supported?
- Policy: Server-level, tool-level, agent-level, and environment-level controls?
- Secrets: Where are credentials stored, exchanged, rotated, and revoked?
- Runtime: Where is policy evaluated and how are failures handled?
- Lifecycle: Approval, versioning, deprecation, rollback, and retirement?
- Telemetry: Which traces, logs, and metrics are emitted and where can they be exported?
- Operations: Who owns upgrades, incidents, protocol changes, and support?
For a vendor-selection framework, use the enterprise MCP gateway comparison. For Jarvis product detail, review the MCP Gateway, Agent Registry, and Agent Gateway pages separately. For the program around the registry, covering owners, risk tiers, approval and review, use the MCP governance checklist.
For the catalog’s day-to-day operating record, use the private MCP registry guide. Pair the architecture with per-user tool-permission tests and the open source gateway comparison. Where a server wraps an existing service, MCP vs REST API keeps the destination’s business rules visible in the design.
The Practical Next Step
Choose one real workflow and map the route from client to business system. Include identity, catalog state, access rules, credentials, external services and evidence stores. Run the same allowed, denied, revoked and failed cases against each design.
If you need a customer-hosted layer across AWS and Azure, evaluate Jarvis Registry against that workflow. Ask the team to show its supplied controls and identify the integration and operating work still required.
References
- Model Context Protocol. “MCP Registry”.
- AWS. “MCP Hosting Strategy”.
- Microsoft Learn. “Register and discover MCP servers in Azure API Center”.
- Microsoft Learn. “AI Gateway governance controls”.
- IETF. “RFC 8707: Resource Indicators for OAuth 2.0”.
- NIST. “SP 800-207: Zero Trust Architecture”.
- AWS. “Bedrock AgentCore Registry”.
- OpenTelemetry. “What is OpenTelemetry?”.
- Jarvis Registry. “MCP tool-enablement boundaries”.
- Jarvis Registry. “Two-user MCP access walkthrough”.
FAQ - Enterprise MCP Registry Architecture
What is an enterprise MCP registry?
An enterprise MCP registry is a private, governed catalog of MCP servers and tools. It records metadata such as ownership, environment, approval state, version, authentication method, and policy references so teams and AI clients can discover approved capabilities.
What is the difference between an MCP registry and an MCP gateway?
The registry is the system of record for discovery and lifecycle state. The gateway is the runtime enforcement point that authenticates, authorizes, routes, and observes MCP tool calls. An enterprise architecture often connects both.
Can an existing API gateway replace an MCP registry and gateway?
An API gateway can continue to govern application APIs. Verify whether it also handles MCP discovery, client and workload identity, tool-level policy, protocol-specific authorization, lifecycle state, and tool-call traces. Custom extensions may be required when those jobs are not native.
How does a private MCP registry help control shadow MCP servers?
A private registry gives teams a sanctioned place to discover reviewed servers and tools. When runtime gateways and endpoint controls use the same approval state, unapproved servers can remain undiscoverable and their calls can be blocked.
