Once a few teams have built MCP servers, someone proposes a registry. The argument is usually about discovery: teams are building the same integration twice because they cannot see what already exists. A catalogue fixes that.
It does, and that is the smaller benefit. The larger one is ownership. A server that lets an AI application read claims documents is a production integration with access to personal information. It needs an owner, a review history and a plan for the day its builder leaves. A registry is the obvious place to record those things, and the only place most organisations will look.
Kalahari Assurance is fictional, and its systems and figures are illustrative. In Part 1 a Kalahari developer built a small MCP server that let an assistant read claims documents. It was well built and quickly found consumers. When the developer resigned, nobody knew who owned it, which systems it could reach or which applications depended on it. It took the platform team two weeks to establish that three applications used it, one of them in production.
MCP itself is covered elsewhere
CloudNala's MCP Without the Hype series explains the protocol, how to design a server as a product, the nine-question MCP security review and when an enterprise MCP gateway helps. This article assumes that material and takes an organisational question: who owns the registry, who owns what is in it, and how does ownership survive staff turnover?
There is also a public registry. The open-source MCP project launched an official public registry of servers in preview in September 2025. A public registry helps you discover servers others have published. It cannot tell you who in your organisation owns the server that reaches your claims system, so an internal record is still needed.
The registry entry is an ownership record
Kalahari rebuilt its registry around one principle: an entry is not complete until someone else could decide, from the entry alone, whether a new application may use the server.
The fields that carry the weight are not the technical ones.
Owner. A named team with a named lead and deputy. Not an individual alone, because individuals leave. Not a department, because departments do not answer messages.
Systems reached and data classes. What the server can read and write, and which classes of information pass through it. This is what a security reviewer and a privacy officer need first.
Authentication. Whether the server acts as the signed-in user or uses a shared credential. Shared service keys were the single most common finding in Kalahari's first review, because they are the fastest way to get a demonstration working.
Review date. When the server was last reviewed and when it is next due. A server that has not been reviewed for a year is a server whose risk nobody currently understands.
Consumers. Which applications may use it. Without this field, deprecation is guesswork.
The tool list, the field most catalogues lead with, is the least important for governance. It changes often and says little about risk on its own.
The lifecycle, including the state nobody plans for
A registry also needs a lifecycle, so that status means something.
Proposed means a team intends to build or adopt a server and has named an owner. Reviewed means it has passed the security review and its data classes are recorded. Published means approved applications may use it. Deprecated means no new consumers, and existing ones have a migration date. Removed means it is switched off and its credentials are revoked.
The state most registries forget is orphaned: the owner field has become empty because a person or team has left. Kalahari treats this as a first-class state with automatic consequences. On the day a server becomes orphaned, it stops accepting new consumers. Its existing consumers' owners are notified. If nobody adopts it within 30 days, it moves to deprecated and then removed. If a team adopts it, it goes back through review, because the new owner has to understand what they are accepting.
The orphaned state is enforced by connecting the registry to the identity system. When a named owner's account is disabled, the registry notices. This is a small piece of integration with a large effect.
Who owns the registry itself
Ownership of entries is one question. Ownership of the registry is another. Kalahari split it three ways:
| Role | Owns |
|---|---|
| Platform team | Running the registry, its integration with identity and the gateway, and enforcement of states |
| Security and privacy | The review standard each entry must pass, and the data-class vocabulary |
| AI guild | The server design standard and reference implementations (Part 6) |
| Server owners | Their entries, reviews and consumers |
Without an explicit owner for the registry, it becomes a wiki page that is accurate for a few months and then quietly drifts out of date.
Connecting the registry to enforcement
A registry that only records is a catalogue. A registry that enforces is a control. Kalahari's platform makes registration meaningful in two ways.
First, AI applications on the governed platform can only reach MCP servers that are published in the registry. An unregistered server can still be run locally for development, but it cannot be wired into a production application through the paved road.
Second, the gateway reads the consumers field. An application that is not listed as a consumer of a server is refused, which turns the consumer list from documentation into an access rule.
Neither control is perfect. Somebody determined can bypass a gateway, as the Agent Evidence Layer series points out. The point is that the default path is governed, and bypasses become visible exceptions rather than normal practice.
Starting from the servers you already have
A registry is rarely built before the first servers exist. More often it is built after an incident like Kalahari's, when the organisation realises it does not know what is running. The first job is therefore discovery, and it is more practical than it sounds.
Kalahari used four sources. Repository scans for MCP server code and configuration files found most servers built in-house. Client configuration in the approved assistants showed which servers people had connected to. Gateway and network logs showed which internal endpoints AI applications were calling. And a short request to every team lead asked a direct question: have you built or connected anything that lets an AI tool reach one of our systems?
The scan found 17 servers. Each was triaged with three questions: does it reach personal or confidential information, does it write as well as read, and does it have a living owner? Servers that reached sensitive data with no owner were suspended within the week, with their consumers notified. Servers with an owner entered the registry as proposed and were scheduled for review. A few turned out to be abandoned experiments and were removed.
The exercise took about three weeks, most of it waiting for answers. It was also the most persuasive argument for the registry: once leaders saw the list, nobody needed convincing that ownership mattered.
Teaching registry ownership
Registry ownership becomes part of the capability programme in two places. Engineers and architects learn to create and maintain an entry as part of building a server, using the server design standard. Team leads learn that owning an entry is an operational responsibility, like owning a service, with a review date that appears in their team's plan.
Next: Part 6, The AI guild must produce standards, not just enthusiasm. All parts are on the series page.
How CloudNala can help
We help organisations inventory the MCP servers and other AI integrations they already have, design a registry entry and lifecycle that records ownership and risk, and connect the registry to identity and the gateway so that status has consequences. The first output is usually a list of servers with no clear owner, which is a useful place to start.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Plan an AI Capability Programme or write to us at consult@cloudnala.co.za