Is your feature request related to a problem? Please describe.

This sub-issue covers the following questions from this parent issue:

While the initial scope of the official registry is of course MCP server-oriented, there is a (less pressing) need for similar functionality for MCP clients.

How should we model it in the OpenAPI spec?

Do we need some sort of client.json concept?

Current Problem:

The MCP client documentation (docs/clients.mdx) currently uses a manually-maintained markdown table with 87+ clients. As discussed in PR #1515, this approach has become difficult to maintain and doesn't scale well:

1. Hard to update: Each feature addition (e.g., transport columns) requires manually editing every row
2. Inconsistent data: No validation ensures completeness or accuracy
3. Missing information: Current schema doesn't capture transport support, platform availability, or authentication capabilities

From PR #1515 discussion:

@olaservo: "IMO we need to change the way we store vs present this information before we add more columns. The markdown table is already very clunky and getting very hard to understand and use once there are diffs/PRs which doesn't really motivate others to keep the page up to date."

@theailanguage: "Maybe it could entail moving the data to docs/data/clients.json and a component to render it in docs/components/ClientsTable.jsx so that clients.mdx is clean and acts as a separate "presentation" tool compared to the data "stored" in json?"

Describe the solution you'd like

Define a schema for client metadata that we could using in the MCP client documentation.

Describe alternatives you've considered

Stay with the manually-maintained table, or define the schema totally separately from the registry.

Additional context

Scope

This issue focuses on:

• ✅ Defining the schema for client metadata
• ✅ Establishing file structure and naming conventions

This issue explicitly excludes:

• ❌ Fully incorporating clients into the registry API/backend

Key Questions

Schema scope: What metadata should we capture?

• Current table columns: Resources, Prompts, Tools, Discovery, Sampling, Roots, Elicitation
• Missing from table: Transport support (STDIO, SSE, Streamable HTTP) per PR #1515
• Additional useful fields: Supported platforms, OAuth compatibility details

Support status granularity: How do we represent support levels?

• Current docs use: ✅ (yes), ❌ (no), ❓ (unknown), ⚠️ (partial)
• Need to model these states in the schema?