Serve skills over MCP (SEP-2640) for agents that can only reach an MCP endpoint

[salmonumbrella]

The situation

Can you add a way for Skillshare to serve the skills it manages over MCP?

I run Executor self-hosted. Some of my agents run on throwaway VMs or in hosted assistants. They can reach Executor's MCP gateway, but not the filesystem where Skillshare syncs my skills, so they get my tools and none of my skills.

MCP has a standard for this now. The Skills extension (SEP-2640, io.modelcontextprotocol/skills) went Final on 2026-09-13 and builds on base revision 2026-07-28. Each skill file is an MCP resource, and the extension adds skills/list and skills/get. Executor has two open skills PRs, #1986 and #2091. The closed plan in #1918 proposes passing skills from upstream MCP servers through to agents. Codex has an open request too (openai/codex#48000).

What works today, and why it is not enough

• skillshare sync works for agents on machines I control, but not for an agent that only has a network path to an MCP endpoint.
• skillshare mcp manages MCP client config for Targets. It doesn't serve anything.
• A generic file-serving MCP server doesn't know enabled/disabled state or Target filters, and doesn't speak SEP-2640.
• Executor #2091 proposes its own managed skill store imported from GitHub. I'd rather serve the source and selection Skillshare already manages than maintain a second copy.

Ask

Add skillshare mcp serve (name up to you): a standalone, read-only SEP-2640 server for the skills Skillshare manages.

• Protocol. Implement SEP-2640 on 2026-07-28, declared through server/discover, so capabilities.resources plus capabilities.extensions["io.modelcontextprotocol/skills"]. Support skills/list (cursor pagination, each skill entry whole on one page) and skills/get for every served skill, plus resources/read. Directory reads can wait.
• Publish validated packages. Build each skill's URI from its source relPath (skill://_anthropics/skills/academy-guide/SKILL.md), whatever the Target naming. The last segment must equal the SKILL.md frontmatter name, not Skillshare's flattened name. Each entry carries the full frontmatter as JSON and a complete manifest: every file once, including SKILL.md and nested skills, with a raw-byte sha256: digest and size. Skip skills that are invalid or over the 512-file / 16 MiB limits, with a warning. skillshare audit could flag those ahead of time.
• Scope with a Target. --target <name> reuses that Target's selection (include/exclude filters, enabled/disabled) and reads the packages from the source, whatever the sync mode. Apply the scope to every lookup and read, not just the listing. If an excluded skill sits inside a served one, skip the parent with a warning rather than publish an incomplete manifest. Without --target, serve every enabled skill.
• Stay in sync. Refresh manifests when content or selection changes, so install, update, enable and disable show up without a restart. Cache digests instead of rehashing the whole source per request. I have about 1,000 skills, so large catalogs matter.
• Transport. stdio by default, so a gateway can spawn it. Optional Streamable HTTP binds loopback by default and needs authentication before it's exposed further, directly or through a trusted gateway.
• Safety. Contain every read to its skill directory after URI decoding and symlink resolution, and reject anything that escapes.

Out of scope: running bundled scripts (this serves content only, and clients apply their own SEP-2640 approval rules), any write over MCP, and agents, extras, hooks or plugins. A tool-based fallback for clients without the extension could be a follow-up.

Related: #239 proposes a broader resource hub and #95 asked about MCP config. This one is narrower: serve the skills Skillshare already manages, in the standard format.

[runkids]

Thanks for the thorough write-up — the scope is clear and well thought out. I plan to support this; I'll dig into the SEP-2640 details first and follow up here before starting.