Prototype skill resource loading in a major open-source client

[olaservo]

Background

Split from #40 based on this comment.

Peter Alexander (MCP Core Maintainer) suggested at the Feb 26 office hours that rather than having each server ship its own load_skill tool, clients should support model-driven resource loading directly — e.g., a built-in read_resource tool on the client side and a SDK-level list_skill_uris() method.

Existing implementations

Several community implementations already demonstrate this pattern:

• skillsdotnet by Peder Holdgaard Pedersen — Full client-side implementation in C# with ListSkillsAsync, SkillCatalog, progressive disclosure via frontmatter, multi-server support, and dependency resolution. Covers discovery, loading, context injection, and a load_skill tool for model-driven access.
• skills-over-mcp by Keith Groves — Exposes skills as skill:// MCP resources with index, lookup, and progressive disclosure patterns.
• my-cool-proxy — Gateway that wraps MCP servers and exposes "Gateway Skills" as MCP resources with progressive disclosure.

What's missing is adoption in a major open-source client — none of the above are integrated into clients with broad user bases.

Scope

Contribute or prototype client-side skill resource loading in a major open-source client such as VS Code. The implementation should:

1. Connect to one or more MCP servers
2. Call resources/list and identify skill resources (by URI pattern, MIME type, or naming convention)
3. Present discovered skills to the user (list with name/description)
4. On selection, call resources/read to fetch the full skill content
5. Inject the skill content into the model context
6. Optionally subscribe to resources/subscribe for skill updates

The existing implementations above (especially skillsdotnet) can serve as reference designs. URI schemes and metadata conventions from #44 and #55 should inform how the client identifies skill resources.

Note: The URI-based approach is one option — #54 makes a case for custom _meta metadata instead of URI conventions. The prototype should evaluate both and document trade-offs.

Acceptance Criteria

• Working integration in a major open-source client that can discover and load skills from at least 1 MCP server
• Demonstrates both the discovery flow (resources/list → filter → present) and the loading flow (resources/read → inject)
• Documents which URI patterns or conventions are used to identify skills
• Evaluates URI-based vs. metadata-based identification (see The case for custom metadata instead of a URI convention #54)
• README or docs with setup instructions and demo walkthrough
• Findings added to docs/experimental-findings.md

References

• Peter Alexander's comment on SEP-2076
• Feb 26 office hours notes
• Open Question 12 — "Why not just resources?"
• #44 — Define well-known URI schemes and naming patterns for skill resources
• #54 — The case for custom metadata instead of a URI convention
• #55 — Define recommended _meta keys for skill resources
• Related to Add examples to common shared skills folder for testing implementation(s) #27 (shared skills folder for testing)
• Parent exploration: Build client-side reference implementation for model-driven resource loading #40

[olaservo]

Just noting that this issue needs to be updated to match the latest #69 (or can just point there)