MCP Gateway Registry vs MCP Server Registry
Separate an MCP server registry for discovery and provenance from the gateway policy, credential and runtime records that enforce each tool call.
An MCP server registry answers what servers exist, who owns them, where they run and which capabilities they advertise. An MCP gateway registry answers what a tenant approved, how traffic reaches it, which identity and credential rules apply, and which policy governs runtime calls. One catalog can store both views, but the records should remain distinct.
The MCP gateway guide explains the enforcement category. This article prevents a discovery record from being mistaken for permission.
Model the two records
type ServerCatalogRecord = {
serverId: string;
name: string;
publisher: string;
endpoint: string;
transport: string;
advertisedToolsDigest: string;
provenance: string[];
observedAt: string;
};
type GatewayAdmissionRecord = {
tenantId: string;
serverId: string;
approvedEndpoint: string;
ownerId: string;
status: 'approved' | 'quarantined' | 'revoked';
allowedTools: string[];
credentialProfile: string;
policyDigest: string;
metadataDigest: string;
reviewedAt: string;
};
The catalog may contain public, private and unreviewed servers. Only an approved admission record should affect gateway routing. Names are display labels, not identities. Use stable IDs and bind approved endpoints and metadata digests.
Detect drift
Tool descriptions and schemas can change after security review. Compare the current metadata digest with the admission record. A material change should quarantine the tool or trigger a new review according to policy.
| Drift | Default response |
|---|---|
| description wording only | record and apply configured review rule |
| input schema adds optional field | re-evaluate policy and validation |
| tool changes read to write behavior | quarantine |
| endpoint host changes | quarantine and reverify ownership |
| authorization server changes | reject until trust review |
| server signing or package provenance fails | revoke or quarantine |
The server's tool list remains untrusted input. The gateway validates tools/call against its approved copy and current runtime policy. Hiding an unapproved tool from discovery is useful, but the call path must also deny it.
Keep tenant admission separate
Two companies may approve the same server with different tools, credentials and policies. Never attach one global credential to a public catalog entry. Partition admission records, secret references, policy and evidence by tenant. Test identical server and tool IDs across tenants to catch cache-key omissions.
The MCP architecture documentation distinguishes hosts, clients and servers. The protocol defines interaction, not an enterprise approval workflow. Registry governance remains a deployment responsibility.
Prove enforcement
A registry review should include this fixture:
given: approved metadata digest A
when:
server advertises digest B
client calls newly added tool transfer_funds
then:
discovery_result: hidden_or_quarantined
runtime_result: denied
upstream_calls: 0
alert: metadata_drift
Also revoke an admission record while a client session is active. New tool calls should stop without waiting for the client to refresh its list.
See MCP gateway architecture and the open source gateway evaluation method. Intelliger's live platform overview is the related product path for governed server admission and request enforcement.
This design does not imply that Intelliger operates a universal MCP server catalog. Public materials describe gateway and OATI developer-preview capabilities; production registry operations remain deployment specific.
Registry design questions
Who may publish and who may admit a server?
Publishing makes a server discoverable in a catalog. Admission makes it usable in a tenant. Keep those permissions separate. A vendor or developer may publish metadata, while a tenant security or platform owner approves endpoint, tools, issuer and credential profile. Record both actors and require a new admission decision when ownership or a protected endpoint changes.
How is publisher ownership verified?
Use a provenance method appropriate to the catalog, such as verified domains, repository ownership, package signing or an enterprise onboarding process. No single signal proves the code is safe. Combine publisher identity with artifact review, endpoint verification and current security status. Preserve what was checked so a later incident does not rely on a display badge.
Should the registry fetch live tool lists?
It may collect them for comparison, but an untrusted endpoint can change or return tenant-specific content. Bound network access, response size and parsing. Store observation time and digest. The gateway should use an admitted snapshot and drift policy rather than blindly routing from the latest fetched description.
What happens when a server is revoked?
Stop new discovery and runtime calls, disable or rotate its credential references, terminate or expire relevant sessions and identify in-flight work. Preserve the historical admission and evidence for investigation. A catalog label change that does not reach gateway replicas or upstream service identity is not effective revocation.
How should private servers be represented?
Keep endpoint and tool metadata within the tenant or approved organization boundary. A shared registry service should partition search, cache and evidence. Avoid leaking internal server names and capabilities through autocomplete or error messages. Use stable opaque IDs where clients do not need the network location.
How can teams test catalog-to-gateway consistency?
Select admitted records and compare owner, endpoint, metadata digest, tool policy and status with active gateway configuration. Then select gateway traffic and resolve its admission record. Automate alerts for unknown records, stale snapshots and calls after revocation. Run the check across regions because one stale replica can preserve a bypass.
Treat deletion as a lifecycle event, not a missing row. Before removing a server, stop admission, block new calls, identify sessions and queued work, revoke credential references and preserve the historical metadata needed to interpret earlier evidence. If a server is replaced, issue a new stable identifier unless the trust, endpoint and ownership contract truly remain the same.
Registry search also needs abuse tests. A user from tenant A should not infer tenant B's private server names, tool descriptions or owners through autocomplete, result counts or error timing. Test common prefixes and identical display names. Public catalogs and private enterprise admission may share software, but they should not share an unrestricted search index or cache key.
Record why a server was admitted and which business workflows depend on it. During revocation, this lets operators distinguish an unused catalog entry from a server whose removal will strand active work. Dependency data should guide communication, not weaken the runtime block.
Test that dependency record during a tabletop exercise. Owners should be reachable, alternatives should be named and the gateway block should remain effective even when replacement work takes longer than expected.