Add Registry Metadata Endpoint for Client Identification

[BobDickinson]

Introduction

The MCP Registry ecosystem is designed to support multiple registries. Clients will be able to configure and connect to one or more registries, including:

• Subregistries - Curated registries that add value through filtering, ratings, or enhanced metadata
• Private registries - Internal corporate registries for proprietary servers
• Community registries - Third-party implementations of the MCP Registry API

All these registries use the same MCP Registry API specification, allowing clients to seamlessly work with multiple registry sources.

Problem Statement

Currently, when MCP clients connect to a registry, there's no way for the client to:

• Display which registry the user is connected to
• Show registry-specific information (name, description, icon, etc.)
• Provide transparency about the source of server data
• Allow users to distinguish between different registries they might have configured

This becomes particularly important in a multi-registry environment where users need to understand which registry they're browsing or which registry a particular server came from.

Proposed Solution

Add a new endpoint to the Generic Registry API specification:

GET /v0/info

This endpoint returns metadata about the registry instance, allowing clients to display registry information to users and provide transparency about data sources.

Response Format

{
  "name": "Some MCP Registry",
  "description": "An MCP registry that provides a curated server list",
  "icon": "https://registry.foo.com/icon.png",
  "url": "https://foo.com/registry",
  "protocolVersion": "1.0.0",
  "capabilities": {
    "publish": false
  }
}

Field Descriptions

• name (required): Human-readable name of the registry
• description (required): Brief description of the registry's purpose
• icon (optional): URL to registry icon/logo
• url (optional): URL to registry's website or documentation
• protocolVersion (optional): The version of the MCP Registry protocol supported
• capabilities (optional): Object describing what the registry supports
  • publish (boolean): Whether this registry accepts new server publications

Benefits

1. User Transparency: Clients can clearly show which registry they're connected to
2. Registry Branding: Registries can provide their own branding and information
3. Client UX: Clients can display registry-specific information in their UI
4. Trust & Verification: Users can verify they're connected to the expected registry
5. Multi-Registry Support: Clients can easily support multiple registries with clear identification
6. Source Attribution: Users can understand which registry a server came from
7. Feature Discovery: Clients can adapt their UI based on registry capabilities

Implementation Notes

• Backward Compatibility: This is a new endpoint, so existing clients won't break
• Optional: Registries can choose whether to implement this endpoint
• Caching: Clients should cache this information to avoid repeated requests
• Fallback: Clients should gracefully handle cases where this endpoint doesn't exist
• Registry ID: The registry's unique identifier is implicit (the URL used to connect)

Alternatives considered

.well-known

Using the .well-known approach, leveraging RFC 8615 (similar to how agent discovery in A2A works) was considered. In that model, the registry would serve the same proposed metadata, but at

/.well-known/mcp-registry

Given that registry clients already know the endpoint and that it implements the MCP Registry protocol, and that this is not a general capabilities discovery problem, and given extra deployment complexity and standards work required, this approach was not preferred.

registryId

A registryId was considered for inclusion in the metadata (a concise ID that could be used by the client to track the source of a server, for example). Since there would be no way of validating such a field, or of ensuring global uniqueness, this idea was abandoned. If a unique registry ID is required by the client, the URL used to connect to the registry should either be that ID or the basis for that ID (as it is unique and essentially self-validated).

[BobDickinson]

The recent SEP-1649 proposal might mean we also favor the "Registry Card" approach (.well-known wirth JSON card).

[mukteshkrmishra]

+1 to this. We are also looking at something similar. Another option we are considering is a common schema (similar to metadata registry here) and then adding a RAG/semantic search layer on top of that for dynamic discovery.