What Is an MCP Registry? Discovering and Governing MCP Servers
TL;DR
- An MCP registry is a discoverable, versioned catalog of Model Context Protocol servers, listing each server's capabilities, authentication requirements, and status so engineers can find and use approved tools without ad-hoc requests.
- The official MCP Registry launched in preview on September 8, 2025 as an open catalog of publicly available MCP servers; enterprise registries build on that shared schema while adding private servers, approval workflows, allow-lists, and deprecation.
- A registry alone lists servers, a gateway enforces policy, and an MCP gateway-backed registry unifies discovery, governance, and runtime enforcement so an approved server actually reaches the model and a denied server actually cannot.
- Bifrost combines a queryable MCP server inventory with per-virtual-key tool filtering, tool groups, federated authentication, and audit logs, so every server in the registry inherits the governance the gateway already enforces.
- Bifrost Edge extends that governance to every laptop by inventorying the MCP servers configured inside desktop apps and coding agents, so denied servers cannot be used even by an app that had them wired in before the policy existed.
An MCP registry is a queryable catalog of Model Context Protocol servers that records what each server does, how to reach it, how to authenticate, and which versions are current. Bifrost, the open-source AI gateway built by Maxim AI, sits in front of that catalog and turns it into an enforced control surface: every registered MCP server inherits the same virtual keys, allow-lists, budgets, and audit logs the gateway applies to model traffic. This post covers what an MCP registry is, why organizations need one, how public and enterprise registries differ, and how a gateway-backed MCP gateway turns the registry into runtime policy.
What Is an MCP Registry?
An MCP registry is a centralized, discoverable catalog of MCP servers that publishes each server's name, description, transport (STDIO, HTTP, SSE), authentication requirements, tool list, and version. It gives engineers a single place to find approved servers, evaluate their capabilities, and connect their agents to them without hunting through internal wikis or filing access tickets.
The registry model exists because MCP itself is decentralized. The Model Context Protocol lets any team stand up a server that exposes tools, resources, and prompts to any MCP-compatible client, and the ecosystem now includes thousands of public servers plus an unknown number of internal ones per organization. Without a registry, that surface area is invisible. Bifrost captures it as an aggregated tool registry exposed through the gateway, so a client sees one catalog of governed tools instead of many independent server endpoints.
Why Organizations Need an MCP Registry
Enterprises need an MCP registry because MCP server sprawl creates the same problems that unmanaged APIs and unmanaged secrets did in the last decade: duplicated work, unclear ownership, shadow access, and no audit trail. A registry turns that sprawl into inventory.
Three pressures drive the need. Internal MCP servers proliferate quickly, so a single quarter can produce servers for ticketing, the data warehouse, internal search, code, and observability. Public MCP servers vary in quality, so an engineer choosing between community servers for the same third-party API needs a curated view. Once agents execute tool calls against real systems, security review requires a stable list of what exists. Bifrost surfaces this list through the MCP client inventory, which the platform team hands to security as the source of truth. For the wider role a gateway plays here, see the MCP gateway explainer.
Public vs Enterprise MCP Registries
Public and enterprise MCP registries share a data model but differ on trust, scope, and enforcement. The official MCP Registry is an open, community-moderated catalog of publicly available servers; an enterprise registry is a private, governed catalog of servers the organization has approved for its own use.
| Dimension | Public MCP registry | Enterprise MCP registry |
|---|---|---|
| Contents | Publicly available MCP servers | Internal servers plus approved public ones |
| Who publishes | Anyone (community-moderated) | Platform, security, or DevRel teams |
| Discovery | Global search | Scoped to the organization, team, or role |
| Trust model | Reputation, community reports | Formal approval workflow with owner sign-off |
| Access control | None (anyone can connect) | Allow-list per team, virtual key, or user |
| Versioning | Publisher-declared | Pinned versions per environment |
| Deprecation | Denylist on report | Deprecation lifecycle with sunset dates |
| Audit trail | None for consumers | Immutable log of connections and tool calls |
The public registry solves discovery for the open ecosystem. It does not solve the governance problem for a company that needs to know which servers touch customer data, which have been reviewed by security, or which a specific engineer is allowed to call. That is what an enterprise registry backed by a gateway is for, and the shape Bifrost Enterprise is designed to support.
Governance Requirements for an Enterprise MCP Registry
An enterprise MCP registry is a governance surface, not just a directory. The requirements below are what separate a shared spreadsheet of server URLs from a control layer a security team will actually approve.
- Approval workflow. A new server enters as pending, is reviewed by an owner and by security, and only then moves to approved. Bifrost Edge implements this on the endpoint: when Edge detects a new MCP server on a device, the approval workflow surfaces it with Pending, Approved, and Denied states.
- Versioning. Every server entry records its version and lets consumers pin. A tool signature that changes between versions can silently break an agent, so environments should hold a specific version until they are ready to move.
- Allow-list per identity. Approval at the catalog level is the floor; the next layer is which teams and users can reach which approved servers. Bifrost implements this through MCP tool filtering per virtual key, with deny-by-default when no configuration is present.
- Deprecation lifecycle. Servers age out. A registry needs to mark a server deprecated, notify consumers, and remove it without breaking every agent that referenced it.
- Audit logs. Every registry mutation and every tool invocation should be recorded immutably. Audit logs in Bifrost Enterprise capture this with signed events, configurable retention, and export for SOC 2, GDPR, HIPAA, and ISO 27001 review.
- Federated authentication. Enterprise servers sit behind existing identity systems. MCP with federated auth lets the registry expose enterprise APIs as MCP tools with no glue code, so the same identity that governs the API governs the tool call.
A registry with no allow-list and no audit trail is a phone book. A registry backed by a gateway is a policy engine.
MCP Registry vs MCP Gateway vs MCP Tool Filtering
These three terms describe adjacent parts of the same stack, and confusing them leads to designs that duplicate effort or leave gaps.
- MCP registry is the catalog. It answers which MCP servers exist, what they do, and how to reach them. A registry stores metadata; it does not carry traffic.
- MCP gateway is the proxy and policy engine. It sits between the model and the registered servers, authenticates the caller, applies rules, invokes the tool, and returns the result. Bifrost as an MCP gateway exposes an aggregated tool surface to clients like Claude Desktop or Cursor.
- MCP tool filtering is the runtime rule the gateway applies on each request. It decides which tools are visible to the model based on the caller's identity, virtual key, and any request-scoped headers, described in the tool filtering docs.
The relationship is layered. The registry lists servers, the gateway routes and enforces, and tool filtering trims the exposed surface per caller. Removing any one leaves a gap. For the adjacent distinction between a gateway, a proxy, and a server, see MCP gateway vs MCP proxy vs MCP server.
How a Gateway-Backed Registry Unifies Discovery and Enforcement
A gateway-backed MCP registry makes the catalog the source of truth the gateway enforces. Every server the platform team adds becomes callable through the gateway, and every governance rule the gateway enforces applies to every server in the catalog.
Bifrost connects to registered MCP servers over STDIO, HTTP, or SSE and exposes them as one aggregated tool registry through its own MCP endpoint. Clients like Claude Desktop point at Bifrost's /mcp endpoint and see one governed tool surface instead of many independent server URLs. On every request, Bifrost applies the caller's virtual key configuration to decide which tools the model sees, then applies rate limits, budgets, and enterprise guardrails from the same policy used for model traffic.
| Capability | Registry without a gateway | Registry backed by a gateway |
|---|---|---|
| Discovery | Yes (list of servers) | Yes, plus servers callable through one endpoint |
| Approval workflow | Yes (metadata only) | Yes, and unapproved servers are unreachable |
| Per-team access control | Manual, per-app | Enforced at request time via virtual keys |
| Rate limits and budgets | No (out of scope) | Yes, same limits as model traffic |
| Guardrails on input and output | No | Yes, applied before and after each call |
| Immutable audit log | Partial (catalog changes) | Complete (catalog changes plus every tool call) |
| Runtime enforcement of denial | No (client can connect directly) | Yes (gateway is the only network path) |
At scale, MCP tool groups let a platform team curate reusable bundles of tools drawn from multiple servers and attach them to virtual keys, teams, customers, users, providers, or API keys, with the union of matching groups becoming the tool surface for that request. That is what turns a catalog into an operating model, and it is why organizations end up with the registry and the Bifrost MCP gateway as one system rather than two.
The same shape drives cost, not just control. A gateway-backed registry with Code Mode enabled has been reported to reduce token spend by up to 92% at scale once registered servers grow past three or four, because the model no longer sees every tool definition on every call.
Extending Registry Governance to the Endpoint
A gateway-enforced registry governs every tool call that reaches the gateway. It does not, on its own, govern the MCP servers a developer wired directly into Claude Desktop or Cursor on their laptop. Closing that gap is the job of the endpoint layer.
Bifrost, the AI gateway, is the control plane; Bifrost Edge extends it to every machine. Edge runs on macOS, Windows, and Linux, inventories the MCP servers configured inside supported AI apps (Claude Code, Claude Desktop, Gemini CLI, OpenCode, Codex, Cursor today), and reports them back to the same admin console the registry lives in. Admins make per-server allow or deny decisions through the endpoint MCP governance flow, and the decision is enforced on the device: a denied server cannot be used even by an app that had it configured before the policy existed. Edge deploys through MDM platforms including Jamf, Intune, Kandji, Workspace ONE, and JumpCloud, and is currently in alpha.
For this control across both surfaces, see MCP server governance across the gateway and endpoint and the MCP server management platform comparison.
Frequently Asked Questions
What is an MCP registry?
An MCP registry is a discoverable, versioned catalog of Model Context Protocol servers. Each entry records the server's name, description, transport, authentication requirements, tool list, and version, so engineers and agents can find approved servers and connect to them without ad-hoc requests. Public registries list open-source and community servers; enterprise registries add internal servers, approval workflows, and per-identity access control.
Is the MCP Registry open source?
Yes. The official MCP Registry is an open, community-moderated project maintained under the Model Context Protocol organization on GitHub. It launched in preview on September 8, 2025 and provides an open API for discovering publicly available MCP servers. Enterprise implementations can build on the shared schema while adding private servers and stricter privacy controls. Bifrost is also available as an open-source MCP gateway that operates on registered servers.
How is an MCP registry different from an MCP gateway?
An MCP registry is a catalog that stores metadata about which servers exist and how to reach them. An MCP gateway sitting in front of the registry is a control point that authenticates the caller, applies allow-lists and rate limits, invokes the tool, and returns the result. The registry answers "what exists"; the gateway answers "who can call what, and prove it." A gateway-backed registry uses the same system for both.
How does MCP authentication work in a registry?
Authentication is a property of each server in the registry and is enforced at call time by the gateway in front of it. Bifrost supports six MCP authentication types: none, static headers, per-user headers, admin OAuth 2.0, per-user OAuth, and enterprise token exchange. Server-level auth uses a shared credential; per-user auth stores a credential per caller; token exchange trades the caller's identity token on every call with nothing persisted.
Who uses an MCP registry?
An MCP registry is used by the engineers who select and approve servers and by the agents that consume them. In an enterprise setting the primary users are platform, security, and application teams, while the primary consumers of the servers it lists are the AI agents those teams build. Any client that speaks the Model Context Protocol can call any server the registry lists.
What is the difference between a public and an enterprise MCP registry?
A public MCP registry lists publicly available servers with community moderation and no access control. An enterprise MCP registry adds private servers, formal approval workflows, per-identity allow-lists, pinned versions, a deprecation lifecycle, and immutable audit logs. The two are complementary: enterprise registries can pull metadata from the public one for approved servers and enforce private policy on top through a gateway.
Do I still need tool filtering if I have a registry?
Yes. A registry lists approved servers at the organization level. Tool filtering trims that list per request, per virtual key, or per calling application, so an approved server a team should not use is not exposed to that team's models. Bifrost applies filtering at three stacked levels (client config, request header, virtual key), and a tool must pass every applicable filter to be visible.
Getting Started with the Bifrost MCP Registry
An MCP registry is the discovery layer; a gateway is what turns it into policy. Bifrost gives platform teams both in one system: a queryable inventory of connected MCP servers, per-virtual-key tool filtering, tool groups, federated authentication, role-based access control, signed audit logs, and endpoint enforcement through Bifrost Edge. Every registered server inherits the Bifrost governance model already applied to model traffic. To see how a governed MCP registry fits your stack, book a Bifrost demo.
