Repository navigation
Enrich the server definition to support the right selection (ServerCapabilities?) #79
Description
Activity
Thanks for the issue!
detailed definition of the skills/capabilities provided to support server selection
I think it would be reasonable to consider including
ServerCapabilitiesin the server.json, but I don't currently see a reason to go beyond that enhancement. I do think we should defer this work until after an initial go-live.as if the registry were an MCP server of MCP servers (which probably shouldn't be a bad idea).
Possible duplicate of #24
Currently, servers are described by a generic description field that we might suggest making as specific as possible, but after all, the description means everything and nothing.
I'd say this is a feature, not a bug: the new age of LLMs means that we need less structure, and more free form context. Unless there is a compelling reason to add more structure overhead, I would default to just adding more best practices guidance around the free form field.
Being more prescriptive in the specifications and adding fields to support the selection of the right tool would probably simplify the job of the AI administrator (or the agent that automatically selects the server to satisfy a given request). E.g., think of having more servers providing the same interactions with a given external system: how could we differentiate b/w them and pick the right one?
I think this is an unsolved problem, even if we had the metadata you are suggesting, and so we should be cautious of adding technical fields that will not actually solve the problem - we need a bias towards simplicity in a protocol and these protocol-adjacent work. Would want to see real-world examples describing the opportunity to differentiate server relevance based on static fields before pushing the solutioning further here.
Sorry, I should have been clearer with my ask for "examples"; I meant examples from production applications serving real users and issues they are running into. We need to start changes like this from a concrete problem definition (see some guidance here).
The concept of
skillsandmetadatadon't exist in MCP as a protocol, and they aren't registry-specific, so they aren't a fit to consider adding into registry work at this time.I'm going to keep this issue around for now as I think it's probably a good idea to consider including
ServerCapabilitiesin the server.json at some point in the futureReacted by Daniele Martinoli- changed the title
[-]Enrich the server definition to support the right selection[/-][+]Enrich the server definition to support the right selection (ServerCapabilities?)[/+]on Jul 31, 2025 if the registry were an MCP server of MCP servers (which probably shouldn't be a bad idea)
Yes, a server like this could be helpful once private registries become common. Suppose that, within a company, many teams host MCP servers for their tasks—perhaps by enhancing some open-source servers and hosting those. This kind of discovery server would let clients search across those servers instead of relying solely on manual search on registry; clients could search from within the client and even suggest, “Here’s a server you can use for your task.”
Registered servers should provide a detailed definition of the skills/capabilities provided to support server selection, as if the registry were an
MCP server of MCP servers(which probably shouldn't be a bad idea).Currently, servers are described by a generic
descriptionfield that we might suggest making as specific as possible, but after all, the description means everything and nothing.Being more prescriptive in the specifications and adding fields to support the selection of the right tool would probably simplify the job of the AI administrator (or the agent that automatically selects the server to satisfy a given request). E.g., think of having more servers providing the same interactions with a given external system: how could we differentiate b/w them and pick the right one?
BTW: metadata is probably a more generic concept that could include the skills/capabilities together with other relevant attributes (e.g. security related options) for differentiation and selection purposes.