modelcontextprotocol
Create Client schema for identifying supported MCP features
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:
- Hard to update: Each feature addition (e.g., transport columns) requires manually editing every row
- Inconsistent data: No validation ensures completeness or accuracy
- 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?
I believe @jancurn is also passionate on this topic!
It may make sense to model this very analogously to wherever we land for servers in https://github.com/modelcontextprotocol/modelcontextprotocol/issues/1649
Indeed, I am :)
We've built https://github.com/apify/mcp-client-capabilities with a goal to provide the most up-to-date community-maintained list of MCP clients and their capabilities. The primary goal of the package is to provide MCP servers with understanding which features does each client support, as the MCP protocol doesn't communicate all the features. But the package might eventually be used also to generate the client capability table https://modelcontextprotocol.io/clients, so that you no longer need to maintain this data.
Currently the package only list a few clients, but we're already collecting data to fill the gap. Our goal is to cover all clients listed at https://modelcontextprotocol.io/clients in a few coming weeks.
One field that I would really like to include (though it will likely have to be optional) is a dedicated URL pointing to server installation instructions (i.e., documentation for how to install / configure an MCP server in the client).
An example would be https://code.visualstudio.com/docs/copilot/customization/mcp-servers.
But that sounds like something for MCP server schema, not MCP client schema...
But that sounds like something for MCP server schema, not MCP client schema...
These would be instructions for the specific client / host application on how to install any MCP server.
Oh I see, thanks for the explanation, that makes sense. We'll add it to https://github.com/apify/mcp-client-capabilities