MCP Registry: The Official Registry, Vendor Catalogs and How to Run a Private Enterprise MCP Registry

What an MCP registry is, and what it is not

The Model Context Protocol lets AI applications discover and call tools exposed by MCP servers. Once an organisation has more than a handful of servers, two questions appear: where can people find them, and which ones are allowed? An MCP server registry answers both. It is a catalogue, not a runtime: it stores descriptions and installation details, while the server code lives in a package registry or runs as a remote service.

A registry is also not the same thing as the list of tools an agent sees. An MCP host connects to the servers it is configured for and asks each one for its tools. The registry sits a step earlier, deciding which servers can be configured in the first place. For the basics of servers, clients and hosts, see our introduction to MCP servers.

The official MCP Registry

The MCP project runs an official registry, described in its documentation as the centralised metadata repository for publicly accessible MCP servers, backed by contributors including Anthropic, GitHub, PulseMCP and Microsoft. The facts below were checked on the project’s documentation and GitHub repository in October 2026.

Three design choices matter for enterprises. First, the registry is deliberately unopinionated: it verifies who published a server, not whether the server is safe. Second, it does not promise uptime or durability, and the project expects aggregators to copy its data on a regular but infrequent schedule, around once an hour, rather than query it live. Third, metadata is generally immutable apart from a status field, which can mark a server version as deprecated or deleted; a deleted status usually signals a moderation-policy violation such as spam or malware, so consumers should keep that field in sync.

The project also says host applications should not read the official registry directly. They are meant to read a downstream registry that implements the same API.

Sub-registries and aggregators

The official registry publishes an OpenAPI specification that any other registry can implement. The documentation calls an aggregator that implements it a sub-registry. Clients written against that interface can then read any compliant registry, public or private.

Sub-registries can add their own information through a _meta field on each server record. The project’s example adds user ratings, download counts and security scan results under a key named after the sub-registry. For an enterprise, the same mechanism is a natural home for internal fields such as owning team, approval status or risk tier.

Vendor registries and catalogs

Several vendors now offer registry or catalogue features. The summaries below use only what each vendor’s own documentation states (verified October 2026). For a broader look at the gateways that often sit alongside these catalogues, see our MCP gateway comparison.

GitHub

GitHub runs a public MCP catalogue at github.com/mcp that lists servers with an install action. For Copilot customers, organisation and enterprise owners can set an MCP Registry URL in Copilot policy and choose between “Allow all” and “Registry only”; with “Registry only”, only servers from that registry can run and Copilot connectors are blocked. GitHub’s documentation labels the custom registry approach as public preview and not prioritised for development, notes that it matches servers only by name or ID and that users can bypass it by editing configuration files, and recommends the generally available allowlist in a managed-settings.json file instead. For Azure API Center, GitHub says to enter the base URL including the workspace path and not to append /v0.1/servers, because Copilot adds that path itself.

Microsoft Azure API Center

Azure API Center can hold an inventory of remote and local MCP servers alongside an organisation’s APIs. Administrators register servers in the Azure portal with a title, description, remotes or packages, version and lifecycle, or add partner servers from a curated list; inventories can also sync from Azure API Management and from Git repositories. Developers browse the inventory in the API Center portal, which includes a test console for running tools, and access can be restricted with API Center’s access management. API Center exposes an MCP registry endpoint in the form https://<name>.data.<region>.azure-apicenter.ms/workspaces/default/v0.1/servers for tools such as Visual Studio Code and GitHub Copilot, and administrators can map custom metadata into the _meta section. Microsoft also notes that servers registered there can feed tool catalogues in Microsoft Foundry.

AWS Agent Registry

AWS announced AWS Agent Registry, part of Amazon Bedrock AgentCore, in preview on 9 April 2026. Its documentation describes a managed catalogue for MCP servers, tools, agents, agent skills and custom resources, with an approval workflow in which publishers submit records and curators approve, reject or deprecate them. MCP and agent records are validated against their protocol schemas. Access is through the AWS CLI and SDKs, the console, or the registry’s own remote MCP endpoint, authorised with IAM or with JSON Web Tokens from a corporate identity provider, and CloudTrail logs registry API calls. On 31 August 2026 AWS added an integration that lets Amazon Quick users browse and enable registry entries.

Docker MCP Catalog

Docker’s MCP Catalog is a curated collection of more than 300 MCP servers packaged as container images and distributed through Docker Hub, with each server running in its own container. Docker states that it builds and signs the local servers in its catalogue and that servers carry provenance and SBOM metadata. Teams can create custom catalogues with the CLI, for example a curated subset of the Docker catalogue plus private servers, publish them to an OCI registry and have colleagues import them in Docker Desktop or pull them with docker mcp catalog pull.

Why an enterprise MCP registry has to be private

The official registry is a good source of public metadata, but it cannot be an enterprise’s system of record. It refuses private servers, it does not judge safety, and it is not meant to be read live. More fundamentally, the decision that matters inside a company is not “does this server exist?” but “who approved it, for which roles, at which version, touching which data?” Only the organisation can record that.

A private MCP registry also closes a supply-chain gap. MCP’s own security guidance describes how a locally installed server runs with the privileges of the client that starts it, and how a malicious startup command or package can exfiltrate data. A registry that pins versions and sources, combined with a rule that only registered servers may run, turns “anyone can install anything” into a reviewed process. Our list of vetted MCP servers for enterprise teams includes an approval checklist you can reuse.

What to record for every MCP server

Keep the record in a format that clients can read. Implementing the official OpenAPI interface, or using a catalogue that does, lets you put internal fields in _meta while staying compatible with hosts that understand the standard.

A workable approval flow

1. Request. A team proposes a server with its purpose, owner and the tools it needs.
2. Review. Security checks the source, version, dependencies and authorization model; the data owner confirms which data the tools may touch.
3. Classify. Each tool is marked read or write, and write tools are flagged for human approval at run time.
4. Grant. The server is approved for named roles or agents only, not for everyone.
5. Publish. The record appears in the private registry, with the approved version pinned.
6. Enforce. Clients run only registered servers, and a gateway checks grants on every call.
7. Re-review. Version changes, new tools or new scopes send the server back to step 2.

Registry, allowlist and gateway: you need all three

A registry on its own is a directory. GitHub’s documentation is candid that registry-based restriction in Copilot can be bypassed by editing configuration files, which is why it recommends a managed allowlist. Even an allowlist acts only at the client, deciding which servers may start. It does not see which tool an agent calls, on whose behalf, or whether that call needed approval.

That last step belongs to an MCP gateway in the call path. It enforces per-role grants, holds write actions for approval and records each invocation. Our MCP gateway overview describes that layer, and the MCP vs API explainer shows where it sits relative to API gateways.

How VDF Agent Hub’s tool registry fits

In VDF AI, the registry and the enforcement point are the same component. Agent Hub keeps an MCP tool registry that administrators govern: tools are registered once, internal services can be wrapped as MCP endpoints and added to it, and each role is granted only the tools it needs. An agent inherits its role’s grants, so neither a prompt nor an Agent Skill can add a tool the role was never given, and revoking a tool is a single change in the registry.

Because VDF AI runs on your own servers, in a private cloud or air-gapped, the registered servers run inside your perimeter too. Write actions can sit behind a human approval step, and every tool call is logged with the agent, role and user, so the registry’s approval decision and the run-time evidence live in one place. VDF AI Cloud offers the same model for teams that prefer a hosted service. The VDF AI Agents product page shows the builder and the registry.