SEP-2640: Skills Extension #568
Description
Activity
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:
- Per-user catalog. Which skills a user can read depends on the user (some are available to everyone, some only to users with access to the underlying content), plus a small set the user has pinned. The listing must never be shared across users.
- Content changes over time. A skill is regenerated when its source content is updated, so the
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.- A way to return a partial listing (e.g. only the user's pinned skills) while
skills/getstill answers for any skill the user can read. - Setting
cacheScope: "private"andttlMson those results. - Either computing digests from content we generate on the fly, or marking resources as
"dynamic".
Happy to try a pre-release against our server and report back if that's useful.
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsIn progress
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 inlib/mcp/methods.rb, no helper module, and no match forskillanywhere underlib/onmain(1.6.0).ROADMAP.mdnames 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: truecapabilities.extensionsfragmentio.modelcontextprotocol/skills, alongside a declaredresourcescapabilityskills/listresults carry the SEP-2549ttlMs/cacheScopehintsPrior art in the other official SDKs
Skillsextension python-sdk#3485Notes
MCP::Appslooks like the shape this would take: a helper module for an Extensions-Track SEP, withCapabilities#support_extensionsfor negotiation and the resources primitive underneath.Most of it can be assembled today from
define_custom_methodplusresources_read_handler, and a custom method's result does getresultTypestamped on the modern path. The SEP-2549 hints don't follow:Server::CACHEABLE_RESULT_METHODSis frozen and consulted internally, so a hand-rolledskills/listhas to mergettlMs/cacheScopeinto its own result. Worth folding into whatever first-class support lands.