What Is an MCP Registry? Public vs Private, and When Your Company Needs Its Own Approved List

What an MCP registry is

MCP, the Model Context Protocol, is the open standard for connecting AI assistants to other software. A tool that wants to be reachable from an assistant gets an MCP server: a small piece of software that exposes the tool’s data and actions in the standard format. There are servers for CRMs, file stores, project trackers, accounting systems, databases and thousands of niche tools. If the basics are new to you, start with what Claude connectors are and which one to set up first.

Thousands of servers raise an obvious question: how does anyone find them, and how does anyone know which ones to trust? A registry is the answer to the first half. It is a catalogue. Each entry says what the server is, who published it, which version is current and how to install or connect it.

That is all a registry does. It does not run the servers, and on its own it does not stop anyone from using a server that is not on the list. It is the reference that other controls point at. Keep that distinction in mind, because vendors often sell “registry” features that are really something else.

The public MCP registry

The MCP project runs an official public registry at registry.modelcontextprotocol.io. It launched in preview in September 2025 and is meant to be the single upstream source of publicly available servers. Three things about it matter to a business reader.

It stores descriptions, not software. The registry holds metadata: the server’s name, version, description and installation instructions. The code itself stays in ordinary package repositories. When someone installs a server they found in the registry, they are downloading it from somewhere else.

Names are verified; code is not. A server published under a company’s namespace has to prove it controls that namespace, so a listing that says it comes from a given vendor is more likely to actually come from that vendor. That is useful. But verifying who published something is not the same as checking what it does. A listing in the public registry tells you a server exists. It is not an endorsement.

It is built to be copied. The registry’s format is open, and the project expects others to build “sub-registries” on top of it: marketplaces attached to particular AI tools, and private catalogues inside companies that pull from the public list and keep only what they have approved. The connector directories you see inside Claude and other assistants work on the same idea. Someone has already filtered the long public list down to a shorter one.

For a leader the takeaway is simple. The public registry is where your developers and your more curious employees will discover servers. It is not where your company decides which ones are allowed.

A private registry: your approved list

A private registry is your own catalogue of the servers your company has said yes to. In a large organisation it might be software that feeds directly into the tools people use. In a company of fifty it is usually a page, a table and a named owner. The format matters far less than the fact that it exists and is kept up to date.

Without one, the approved list is whatever each person happened to connect. Picture a sixty-person consultancy in Gothenburg. The partners use Claude with the shared drive and the calendar. Two consultants have added a scraping tool they found on a forum. Finance connected the accounting system with write access because the setup screen suggested it. A developer runs a database server on their laptop that nobody else knows about. None of this was anyone’s decision, and none of it is written down. When a client’s security questionnaire asks which systems your AI tools can access, the honest answer is a guess.

A private registry turns that into a short set of facts:

• Which servers are approved. Named, with the exact version or source, so “the Google Drive connector” means one specific thing.
• Who may use each one. All staff, one team, or a named role.
• At what level. Read-only by default, write access only where it was deliberately granted.
• Who owns it. One person who answers questions about it and removes it when it is no longer needed.

Those four facts are the same ones a client, an auditor or your board will eventually ask for. A registry is how you have the answer ready rather than assembling it under pressure.

Public and private side by side

When a company needs its own

Not on day one. If ten people use one assistant with the three connectors that ship with it, the admin console in your business plan is your registry: it shows what is switched on, and that is enough. Writing a separate catalogue at that stage is paperwork.

You need your own list when several of these are true:

• People connect AI to more than a handful of tools, and you can no longer say from memory which ones.
• Different teams use different assistants: Claude in one place, Copilot in another, ChatGPT somewhere else. Each has its own settings and none of them shows the whole picture.
• Someone has connected, or wants to connect, a server that did not come from the assistant’s own directory: something from GitHub, a forum or the public registry.
• Your developers have built a server for an internal system, and others want to use it.
• You handle client, personal or financial data that a connector could reach.
• Employees keep asking “am I allowed to connect this?” and the answer depends on who they ask.

The last one is the most reliable signal. When the same question gets three different answers, the list exists only in people’s heads, and the cautious majority of your team will take that as a reason not to connect anything. That is the other side of the problem: a missing approved list does not only let risky connections through. It also stops the useful ones from spreading. We wrote about that pattern in the Claude Team plan rollout guide, where vague rules are one of the main reasons rollouts stall.

What goes in each entry

Keep entries short enough that someone will actually maintain them. Seven fields cover what you need. Copy this as a starting point:

The review date is the field most companies leave out and later regret. Servers change, vendors get acquired, and a connector approved for a pilot quietly stays connected for two years. A review every six months, where the owner confirms it is still used and still needed, keeps the list honest.

Add one more section below the table: servers we have said no to, and why. It saves the next person from asking, and it shows that the list is a decision rather than an accident.

Where the list should live

A registry that sits in a document nobody opens has no effect. The list only works when the tools people use actually follow it. There are three levels, and most companies move through them in order.

1. A shared page plus the admin settings. The list lives somewhere everyone can find it, and the owner mirrors it in each assistant’s admin console. On the Claude Team and Enterprise plans, for example, an Owner has to add a connector for the organisation before members can use it, and can restrict what it may do, such as read but not write. That setting is your registry put into practice. This level is enough for most companies of 20 to 200 people.

2. Enforcement in each tool. Some assistants can now enforce a list directly. GitHub Copilot, for instance, lets enterprise administrators define which MCP servers its clients may start, and offers a separate private-registry setting that GitHub itself describes as a preview and not the recommended way to restrict access. The lesson carries over to other tools: a catalogue tells people what is approved; a setting in the tool stops them from using what is not. You want both, and they must match.

3. A gateway in front of everything. When several assistants each keep their own settings, keeping them in step becomes a job in itself. A gateway solves that: every assistant connects to one entry point, and the approved list is enforced there, with a record of what was called. Most gateways include a registry for exactly this reason. If you are at this stage, read our guide to MCP gateways before talking to vendors.

Building the first version in a week

You do not need a project. A week of short sessions with one owner is enough to go from no list to a working one.

Two habits keep it alive afterwards. First, every new request goes through the owner, and the owner answers within a day or two; if approval takes weeks, people route around it. Second, look at what is actually used. A connector nobody has touched in three months should come off the list. A team that has nothing connected is a team that is not yet getting much out of AI. Our guide to measuring AI adoption covers which numbers tell you that.

The point of the registry is not control for its own sake. It is what lets you say yes quickly and with confidence: here is what you can connect today, here is who to ask about the rest. That is what gets the whole team using AI on real work, rather than the few people who were going to set it up anyway.

Taking the inventory, deciding the approved list and getting every team connected to it is part of the work we do in Deployed Partner. If you are just starting, a Deployed Kickstart gets your team set up with the right connectors in a single session.

Frequently asked questions