[FEATURE] MCP Server Registry Discovery: connect Claude Code to an enterprise MCP server catalog
Problem Statement:
Claude Code's MCP support is excellent for connecting to individual servers, but there is no built-in way to discover which servers are available across an organization. Today, teams share server URLs through wikis, Slack, or README files, and each developer manually runs claude mcp add for every server they need.
This is the same problem raised in #30727 (marketplace for Skills, MCP Servers, and Agents) and #53386 (provenance verification). Enterprises need a centralized, governed catalog where developers can search for and connect to approved MCP servers without knowing individual URLs upfront.
Proposed Solution:
We maintain an open-source MCP Gateway Registry that solves this today. It's a centralized catalog of MCP servers, agents, and skills with OAuth/DCR-based access control, and it already works with Claude Code via claude mcp add.
How it works today (zero changes needed on Claude Code side):
claude mcp add --transport http airegistry-tools https://your-enterprise-registry/airegistry-tools/mcpOnce connected, Claude Code gains a search_registry tool that lets it find and connect to any server in the catalog on the user's behalf. The registry supports:
- Semantic search across all registered MCP servers, agents, and skills
- OAuth/DCR integration with Keycloak and Microsoft Entra ID (per-user auth, no shared tokens)
- Per-user authorization with scope-based access control
- CIMD support (Client ID Metadata Document,
draft-parecki-oauth-client-id-metadata-document) for zero-touch client registration
What deeper native integration could look like:
- Registry-aware
claude mcp add: A--registry <url>flag that searches a registry and presents matching servers for the user to pick from, instead of requiring the full endpoint URL upfront. The registry already implements a/.well-known/registry-carddiscovery endpoint that describes the registry instance and its capabilities.
- Auto-discovery via well-known URL: The registry publishes a
/.well-known/mcp-serversendpoint that returns JSON with all discoverable MCP servers. If Claude Code supported fetching this well-known URL from a configured registry, it could auto-populate available servers without the user needing to search manually.
- Enterprise registry source in settings: Allow organizations to configure a registry URL in project or user settings, so available MCP servers appear in
/mcpalongside manually configured ones.
Use Case Example:
A developer joins a team that has 20+ internal MCP servers (database tools, deployment pipelines, monitoring dashboards, internal APIs). Instead of receiving a wiki page with 20 URLs and running claude mcp add 20 times, they connect to the enterprise registry once and search for what they need in natural language. The registry enforces that they only see servers their team's IAM groups grant access to.
Additional Context:
- Demo (8 minutes): https://app.vidcast.io/share/09a267f4-3a5c-43a4-91fb-f128ed0e7983
- MCP Gateway Registry repo: https://github.com/agentic-community/mcp-gateway-registry
- DCR/OAuth integration tested end-to-end with Claude Code (see Integration Guide)
- Related issues: #30727 (marketplace), #53386 (provenance/supply chain), #60252 (MCP registry fetch)
- The registry is open-source (Apache-2.0), self-hostable, and deploys on AWS ECS, EKS (Helm), or Docker Compose
!AI Gateway Registry Landing Page
This is not a PR submission. Happy to discuss the integration approach and provide technical details.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Strong +1 on the discovery/catalog need. One thing worth adding: there are two distinct shapes here, and I think the open one is the better bet.
The solution proposed above (a gateway exposing a
search_registrytool) puts the registry in the call path. That works, but it couples every team to one gateway and routes traffic through a central component.The alternative is consuming the official open MCP registry spec (registry.modelcontextprotocol.io,
/v0.1/servers) natively, as pure discovery that stays out of the call path: the client reads metadata, then connects straight to each server. VS Code / Copilot already does exactly this with custom/self-hosted registries.I validated it end to end this week:
modelcontextprotocol/registry, Docker + Postgres) on an internal box.The only gap is that Claude Code can't point at the same instance yet. If it consumed the official registry spec natively, one self-hosted catalog would serve VS Code, Claude Code and any spec-compliant client: no vendor gateway, no lock-in, governance via the registry's review/publish layer. That feels like the sovereign, interoperable path, and it complements the git plugin marketplace you already support.
Happy to share setup notes if useful.
+1 on using the official MCP Registry spec for that: https://modelcontextprotocol.io/registry/about
Another use-case besides discovery is version updates. Ideally, you'd pin MCP Server versions (to concrete semver, as per registry spec), and with proper registry integration, claude could automatically suggest updates to the most recent version.
The MCP Registry standard supports authentication on the registry itself as well. That authentication works the same way as auth towards an MCP server (i.e. OAuth with DCR/CIMD/...): https://github.com/modelcontextprotocol/registry/blob/main/docs/reference/api/registry-authorization.md
The discovery-vs-trust split seems important here. Native registry support can solve "what servers exist and how do I connect," but clients also need a portable way to decide "which identity/evidence backs this server or agent" before adding it.
I would keep those as two linked records rather than one overloaded catalog entry:
That keeps the registry from having to become the reputation system. Claude Code could consume the open MCP registry spec for discovery, then optionally surface a profile URL/trust summary when present. Enterprise teams can use their own registry and policy; open-web servers can still publish public evidence that independent clients can inspect.
This is the role AgentFolio is useful for as a reference shape: public agent/server profile, verification evidence, trust score, and external attestations. Boundary: not saying Claude Code or the MCP registry should depend on AgentFolio, only that discovery metadata and portable trust evidence are easier to compose if they stay separate and linkable.
A minimal client UX could be:
profile_urlor equivalent exists, show verified operator/proofs/status beforemcp addThat would make enterprise catalogs and open registries interoperable without routing all trust decisions through one gateway.