How to Build an MCP Server Registry and Govern MCP at Scale

Every AI agent your developers run reaches the outside world through tools, and increasingly those tools arrive as MCP servers - Model Context Protocol connectors that grant an agent the ability to read a database, call an API, browse a repo, or run a shell command. The protocol is open and the ecosystem is enormous, which is exactly the problem. A community server installed in thirty seconds becomes a live dependency with tool-call reach into your data, and nobody on the security team knows it exists.

An MCP server registry is how you take that sprawl back. It is a curated, governed catalog of every server your agents are allowed to connect to, with ownership, risk, authentication, and an approved version recorded for each. This guide covers what a registry is, how the official one differs from the one you actually need, the schema and lifecycle to build, and the concrete controls a security team puts in place to govern MCP at scale.

What an MCP server registry is

A registry is the source of truth for which MCP servers are sanctioned, who owns them, and how they may be used. It is not a marketplace and it is not documentation. It is a control surface: a place where an approval decision is recorded, a version is pinned, a risk tier is assigned, and a gateway can check whether a given server is allowed before an agent connects to it.

Think of it the way you already think about an internal package registry or an approved-software list. The unit of governance is a single server entry. Each entry answers the questions an auditor or an incident responder will ask: what is this, what can it touch, who signed off, what version are we running, and which agents break if we pull it.

The official MCP Registry is not a governance tool

In September 2025 the MCP project launched the official MCP Registry in preview - a minimal upstream catalog where server authors publish their servers and consumers discover them. It is genuinely useful for what it is: a canonical place to find servers and their metadata, anchored on a published server.json schema.

But it is built for discovery and publication, not for governance. It does not vet code, assign an accountable owner inside your org, pin a server to the specific version you approved, classify the sensitivity of the data a server touches, or enforce who is allowed to install what. Treating the public registry as your control plane is like treating npm as your software-approval process. You use it as an upstream source and build a private sub-registry that adds the governance layer on top.

How the schema works: extend server.json

You do not need to invent a format. Start from the official server.json schema - it already carries the server name, description, package source, and runtime details - and extend it with the governance fields that turn a package descriptor into a governable record.

The added fields are what your approval process, your gateway, and your auditors actually consume. At minimum, capture the following on every entry:

• Owner - a single named, accountable person or team. Unowned servers are deprecation candidates.
• Data classification - the most sensitive data class the server's tools can read or write (public, internal, confidential, regulated).
• Auth method - how the server authenticates, e.g. OAuth, API key, or none. See OAuth for MCP servers explained for what good looks like.
• Pinned version - the exact approved version or digest, not just the server name.
• Last review date and reviewer - when it was last vetted and by whom.
• Dependent agents - which agents are cleared to use it (this links the registry to your agent inventory).
• Risk tier - a coarse rating driven by data class, blast radius, and auth strength.
• Approval status - proposed, approved, restricted, or deprecated.

{
  "name": "io.github.acme/postgres-mcp",
  "description": "Read-only Postgres query server",
  "packages": [{ "registry_type": "npm", "identifier": "@acme/postgres-mcp" }],

  "x-anomity-governance": {
    "owner": "[email protected]",
    "data_classification": "confidential",
    "auth_method": "oauth",
    "pinned_version": "1.4.2",
    "last_review": "2026-06-10",
    "reviewer": "appsec",
    "dependent_agents": ["sales-copilot", "analytics-bot"],
    "risk_tier": "high",
    "approval_status": "approved"
  }
}

Namespacing your fields under an x- extension keeps you compatible with the upstream schema while letting tooling validate the governance block independently.

How it applies to AI agents and MCP

The reason a registry matters more for MCP than for ordinary software is the combination of autonomy and reach. An agent chooses which tools to call based on a prompt, and a single MCP server can expose dozens of tools. That makes every connected server a piece of your attack surface that activates without a human in the loop.

The risk is not theoretical. Researchers at Knostic found 1,862 MCP servers exposed to the internet with no authentication at all - anyone who found one could invoke its tools directly. Separately, the widely used mcp-remote connector carried a critical remote code execution vulnerability tracked as CVE-2025-6514 (CVSS 9.6), triggered when the proxy connected to a malicious server. Both are textbook supply-chain exposure: an unvetted server is an unvetted dependency, and the agent will call it without asking.

Connected MCP servers also widen the blast radius for prompt injection. When an agent can read untrusted content and call powerful tools and reach sensitive data, you have the conditions for the lethal trifecta of AI agent data exfiltration. A registry does not stop injection on its own, but it bounds the trifecta by controlling which high-reach servers are even reachable.

This is why MCP governance and discovery are inseparable. As we argue in AI agents are the new shadow IT, you cannot govern what you have never enumerated, and the full picture only exists when your MCP server security program is backed by a registry that knows what is actually running.

The MCP server lifecycle

A registry entry is a living record, not a one-time signoff. The lifecycle has six stages, and the value comes from running every server through all of them - especially the ones teams skip, like re-vetting on update and deprecation.

1. Discovery

You cannot govern servers you cannot see. Discovery means finding every MCP server already in use across the fleet - in IDE configs, agent settings, CI runners, and developer machines - not just the ones someone remembered to register. This is the same scanning problem we describe in what we found scanning AI configs: the gap between declared and actual is where the risk lives.

2. Vetting

Each discovered server gets reviewed before approval: read the code or audit the package, check the maintainer and update history, inspect the tool definitions for over-broad permissions, confirm the auth method, and pull dependencies for known vulnerabilities. Watch specifically for hidden instructions in tool descriptions - the MCP tool poisoning pattern hides attacker text exactly where an agent will read it.

3. Approval with version pinning

Approval writes the registry entry: owner, risk tier, data class, and the pinned version. Pinning is non-negotiable. If you approve postgres-mcp by name but not by version, a compromised update ships straight into your agents - the same dynamic behind the npm worm and credential-stealer campaigns covered in our AI supply chain attacks defender's guide.

4. Monitoring

Once a server is approved and in use, watch how it actually behaves: which agents call it, what tools they invoke, what data flows out. Static vetting cannot catch a server that is abused at runtime through injection or that quietly changes behavior. Pair the registry with runtime monitoring and anomaly detection for AI agents so a vetted-but-abused server still surfaces.

5. Re-vetting on update

When a new version is published, the pinned approval no longer applies. The update goes back through vetting before the pin moves. This is the stage that defeats slow-burn supply-chain attacks, where a package earns trust and then turns malicious in a later release.

6. Deprecation

Servers that lose their owner, fail re-vetting, or fall out of use are marked deprecated and removed from the allowlist. The dependent-agents field tells you exactly which agents break first, so deprecation is a planned migration rather than an outage.

Concrete controls: rolling out enforcement in phases

The fastest way to fail at MCP governance is to start by blocking things. You will break working agents, developers will route around you, and your registry will be both incomplete and resented. Roll out enforcement in three phases at an MCP gateway or proxy - a chokepoint all agent-to-server traffic passes through.

The sequence matters because each phase builds the data the next one needs. Log-only populates the registry from reality. Alerting drives owners to get servers vetted while nothing is broken. Only when coverage is high and the allowlist is trusted do you flip to enforcement. A gateway also gives you the central logging that feeds your AI agent audit trail.

Alongside the gateway, apply these standing controls:

• Least privilege per server - scope each server's tools and credentials to the minimum its job requires; see least privilege for AI agents.
• Strong auth, no anonymous servers - require OAuth or scoped keys; the 1,862 exposed servers were all auth-free.
• Secrets isolation - never let a server hold long-lived broad credentials; follow secrets management for AI agents.
• A written policy - codify what is allowed in an AI acceptable use policy for agents and MCP so the registry has rules to enforce.
• Linkage to identity - tie each server and agent to a governed identity so actions are attributable; see non-human identity governance.

A pragmatic build order

1. Stand up a gateway in log-only mode and capture what agents actually connect to.
2. Define the extended server.json schema with your governance fields.
3. Seed the registry from discovery - every server already in use becomes a proposed entry.
4. Vet the high-reach servers first (anything touching confidential or regulated data).
5. Assign owners; deprecate anything no one will own.
6. Pin approved versions and turn on update alerts.
7. Move the gateway to alert, then enforce, once coverage is high.
8. Wire runtime monitoring so abuse of vetted servers is still caught.

Where continuous MCP visibility fits

A registry is only as good as your knowledge of what is actually running against it. The hard part is not the schema - it is keeping the catalog honest as developers add servers, versions drift, and agents multiply across IDEs, CI, and laptops. That is the discovery problem Anomity is built for: continuously finding every agent and MCP server across the fleet, reconciling them against the approved registry, flagging unvetted or unpinned servers, and watching runtime behavior for anomalies. The registry is the policy; continuous visibility is what keeps it from quietly going stale. You can read how that discovery works in inside Anomity discovery.

Build the registry first regardless of tooling - the schema, the lifecycle, and the phased gateway are durable practices. Then make sure something is watching the gap between what the registry says and what your fleet is really doing, because that gap is exactly where the next unvetted server is being installed right now.