Skip to content

SEP-2640: Skills Extension #568

Description

@anirudhmungre

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/list and skills/get — both MUST
  • resources/directory/read — optional, gated behind directoryRead: true
  • the SEP-2133 capabilities.extensions fragment io.modelcontextprotocol/skills, alongside a declared resources capability
  • on 2026-07-28, skills/list results carry the SEP-2549 ttlMs/cacheScope hints

Prior art in the other official SDKs

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

  1. self-assigned this
    on Sep 22, 2026
  2. YuzuruS commented on Sep 30, 2026

    @YuzuruS

    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 mcp gem as a remote MCP server over Streamable HTTP. After OAuth, we build an MCP::Server per 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.md behind 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 server instructions, which works across current clients. When the extension lands in the SDK, these would make it easy for us to serve the same catalog through skills/list / skills/get alongside the tools:

    1. skills/list and skills/get handlers that run per request with access to server_context (the authenticated user), instead of only a static registry.
    2. A way to return a partial listing (e.g. only the user's pinned skills) while skills/get still answers for any skill the user can read.
    3. Setting cacheScope: "private" and ttlMs on those results.
    4. 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

enhancementNew feature or request

Type

No type

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions