Why Your Company Needs an Internal MCP Server Registry

Ask your platform team one question: which MCP servers are engineers wiring into AI agents? If the answer is a Slack thread and a shrug, you need an MCP server registry. MCP (Model Context Protocol) servers give agents tools, like querying a database or filing a ticket, so every team that installs its own is quietly deciding what an agent can read, write or delete. One internal catalog, with an owner, version, approval status and scopes per server, turns that guesswork into a list you can audit.

Why unmanaged servers break MCP server governance

Installing a server takes a minute, and nothing stops it: by default, anyone running Claude Code can connect any MCP server they choose. Who owns the Jira server someone built at a hackathon? Can the "reporting" server write to production? You'll find out during an incident, the worst time to do research.

Copy the official MCP Registry's design, not its servers

The official MCP Registry, in preview since September 2025, catalogs publicly accessible servers. It says it does not support private servers and recommends hosting your own private MCP registry, which matches the MCP team's picture of public and private sub-registries.

What you borrow is the shape: server.json entries with reverse-DNS names like com.acme/jira-readonly, plus an OpenAPI spec that private registries can implement so existing host applications can read them. The docs also say the official codebase isn't designed for self-hosting. Implement the API, don't fork the server, and expect preview-era changes.

What an MCP server registry entry should record

{
  "$schema": "https://static.modelcontextprotocol.io/schemas/2025-12-11/server.schema.json",
  "name": "com.acme/jira-readonly",
  "title": "Jira (read-only)",
  "description": "Search and read Jira issues for Acme engineering projects.",
  "version": "1.4.0",
  "remotes": [
    {
      "type": "streamable-http",
      "url": "https://mcp.internal.acme.com/jira/mcp"
    }
  ],
  "_meta": {
    "com.acme.registry/governance": {
      "owner": "platform-team@acme.com",
      "approval": "approved",
      "scopes": ["jira:issues:read"],
      "data_classes": ["internal"],
      "last_reviewed": "2026-10-01"
    }
  }
}

The spec lets a subregistry add custom data under _meta and recommends a key that names the subregistry. The fields inside com.acme.registry/governance are our own convention, not a standard. We say approval because the official registry already uses status for values like deprecated and deleted. Published versions there are immutable, like npm. Copy that: a changed scope means a new version and a new review.

Turn the registry into an MCP allowlist

A catalog nobody has to consult is a wiki page, so wire it to the clients.

GitHub Copilot admins can point an organization at a registry URL and choose Allow all or Registry only, the stricter mode (public preview). GitHub's docs name the caveat: enforcement matches on server ID, users can bypass it by editing config files, and GitHub points to a managed-settings allowlist for URL-based restrictions users can't override.

Claude Code has no built-in registry to browse, so its docs suggest publishing your approved list where people will find it. For enforcement, have CI render approved entries into managed settings:

{
  "allowManagedMcpServersOnly": true,
  "allowedMcpServers": [
    { "serverUrl": "https://mcp.internal.acme.com/jira/*" },
    { "serverUrl": "https://mcp.internal.acme.com/runbooks/*" }
  ]
}

allowManagedMcpServersOnly stops user settings from widening the list. Match on serverUrl or serverCommand: the docs warn that a serverName entry is not a security control, because users pick the name.

The objection: a registry slows teams down

It does if approval is a ticket queue, so make it a shortcut. Registering a server is a pull request that adds one JSON file, and CI checks the schema and rejects entries with no owner. Use three approval states: pilot for non-production data, approved and deprecated. Save human review for write scopes and sensitive data classes.

Teams get something back too: discovery. When the Jira server is listed with an owner, the next team reuses it instead of building a fourth. Today's slow path is invisible: duplicate servers, and the incident review where you find them.

What a registry will not do

• It stores metadata, not safety. The official registry leaves code scanning to package registries and aggregators, so your review still has to check what a server does.
• Enforcement depends on each client, so test the ones your engineers use.
• With three servers and one team, a table in the repo README is enough. Build the registry when nobody can recite the list.

Start with an inventory this week

Ask each team which servers they use, and search repos for .mcp.json files, Claude Code's project-scope config. Create one Git repo with a server.json per server, fill in owner and scopes, and mark everything pilot. Entries with no owner are your first conversation.

An agent in production is only as safe as the least-reviewed tool it can call, and a registry is how you learn what that tool is before an incident does.