Repository navigation
Post-v1: query/filter on skills/list for large catalogs #99
Description
We are building an MCP server that will contain a massive amount of skills. Exposing them all in a skill://index.json is not practical and will leads to context bloat and poor skill selection.
From our server end, we have a mechanism to surface relevant skills based on a query string / passed in context. Today, we can workaround and surface that mechanism through a "discover_skills" tool and returning a list of resource URIs. But relying on a tool being called to discover skills is unideal
Could there be a more idiomatic way to do this in the Skills over MCP extension spec? Perhaps a skills/discover? Or a resources/discover if we are going Skills are just Resources route
This is similar to the "query" parameter proposed for tools in SEP-1821. modelcontextprotocol/modelcontextprotocol#1821
Activity
tobinsouth commentedon Jun 22, 2026
@pja-ant this came up today in a call!
pja-ant commentedon Jun 23, 2026
Hey @YousefHaggy - excited that you're interested in using this!
Could you elaborate a bit more on how you see
skills/discoverbeing different from a tool that is justskills_discoverthat returns a list of skill URIs?There's generally a couple of approach that could be taken here depending on your use case:
Use the
skill://index.jsonto package high-level skill categories. e.g. imagine you have a code review skill per programming language. Instead of putting them all in the index, you could have a singleskill://code-review/SKILL.mdin the index, and inside thatSKILL.mdit says something like: "For language-specific code review guidance, find the relevant skill inskill://code-review/languages" and the model will then go and explore that directory using theresources/directory/readmethod to find the relevant skill. This should work well for large hierarchical skill catalogues.For unassorted skills, you could have a single skill in the index which just says "Use the
skill_searchtool to find specific skills related to xyz" and thenskill_searchis a tool that returns skill URIs that the model can then load.Or of course, you could use a mix of these.
YousefHaggy commentedon Jun 25, 2026
@pja-ant Thanks for your reply. Generally I like both of those approaches. One issue is that in approach 2, the model can load the skill URIs that are returned but often does not. We've experienced that even with strong models like Opus 4.8, they often choose to ignore the returned resources and not read them
If the spec specified that MCP clients MUST read returned resource links deterministically instead of relying on the model, perhaps that would solve that problem?
Edit: While there is "priority" in the Resource Annotations, even priority 1 doesn't explicitly require the MCP client to deterministically read the resource, nor is it treated that way in practice.
t1 commentedon Aug 25, 2026
@YousefHaggy: how would an MCP client deterministically decide, if a skill is relevant? E.g., if you tell the LLM to build a web UI, how does the client know that it has to load the "Frontend" skill? String matching will not suffice.
How about some filtering mechanism: some tags that are configured in the project get sent to the server that uses them to filter, e.g.
java. WDYT?[-]Server driven discovery of skills[/-][+]Post-v1: query/filter on skills/list for large catalogs[/+]olaservo commentedon Aug 28, 2026
Retitled as a post-v1 proposal. v1's answer for large catalogs is partial/empty
skills/listplusskills/getby URI, with server-side search tools as an interim pattern. The proposal to develop here: a query/filter parameter onskills/list(cf. SEP-1821's query-on-tools). Per CONTRIBUTING.md, the vehicle is adecisions.mdentry with Status: Proposed. Related: #122.