Repository navigation
SEP-2640: Skills Extension #568
Description
Requesting support for SEP-2640 (Skills Extension, Extensions Track, Final), which serves Agent Skills over the existing Resources primitive.
Nothing in the SDK covers it today: no skills/* constants in lib/mcp/methods.rb, no helper module, and no match for skill anywhere under lib/ on main (1.6.0). ROADMAP.md names DPoP, workload identity federation, and the tasks extension as the unimplemented extensions — skills isn't listed.
What a server declaring the extension owes
skills/listandskills/get— both MUSTresources/directory/read— optional, gated behinddirectoryRead: true- the SEP-2133
capabilities.extensionsfragmentio.modelcontextprotocol/skills, alongside a declaredresourcescapability - on 2026-07-28,
skills/listresults carry the SEP-2549ttlMs/cacheScopehints
Prior art in the other official SDKs
- python-sdk: Add SEP-2640 (Skills Extension) protocol support python-sdk#3486, Add
Skillsextension python-sdk#3485 - typescript-sdk: Add first-class SEP-2640 Skills extension APIs typescript-sdk#2798, feat(skills): add SEP-2640 Skills extension APIs (phase 1: schemas, client ops, server handlers) typescript-sdk#2818
- go-sdk: skills: add SEP-2640 protocol support go-sdk#1238, skills: add filesystem provider helper go-sdk#1240
- csharp-sdk: Add support for the Skills extension (SEP-2640) csharp-sdk#1863, Add the Skills extension (SEP-2640) as ModelContextProtocol.Extensions.Skills csharp-sdk#1864
Notes
MCP::Apps looks like the shape this would take: a helper module for an Extensions-Track SEP, with Capabilities#support_extensions for negotiation and the resources primitive underneath.
Most of it can be assembled today from define_custom_method plus resources_read_handler, and a custom method's result does get resultType stamped on the modern path. The SEP-2549 hints don't follow: Server::CACHEABLE_RESULT_METHODS is frozen and consulted internally, so a hand-rolled skills/list has to merge ttlMs/cacheScope into its own result. Worth folding into whatever first-class support lands.
Activity
YuzuruS commentedon Sep 30, 2026
Thanks for taking this on. Sharing one production use case in case it helps shape the API; no action needed.
We run a Rails app with the
mcpgem as a remote MCP server over Streamable HTTP. After OAuth, we build anMCP::Serverper request for the authenticated user, and serve Agent Skills (SKILL.md) that are generated from user-published content.Two properties of our catalog seem different from the filesystem case:
SKILL.mdbehind the same URI changes now and then.Today we do this with tools (
list_my_skills,search_skills,get_skill) and put a short index of the user's pinned skills in the serverinstructions, which works across current clients. When the extension lands in the SDK, these would make it easy for us to serve the same catalog throughskills/list/skills/getalongside the tools:skills/listandskills/gethandlers that run per request with access toserver_context(the authenticated user), instead of only a static registry.skills/getstill answers for any skill the user can read.cacheScope: "private"andttlMson those results."dynamic".Happy to try a pre-release against our server and report back if that's useful.