c00ca72d94* docs: sync repo SEP copy with canonical v1 text The repo-local copy of SEP-2640 had drifted well behind the canonical text on the sep/skills-extension branch, which was a source of confusion: it still specified the well-known skill://index.json resource and predated skills/list, skills/get, resources/directory/read, nested skills, and per-file digests. Replace the body with a verbatim copy of the canonical SEP as of d7490ec (2026-07-15) and swap the stale "not actively maintained" notice for a disclaimer that states what this file now is: a synced snapshot, re-synced by overwriting rather than hand-editing, with review on the upstream PR and anything beyond v1 raised as a PR in this repository. Also drop "working draft" from the README and related-work references to this file, since it is no longer where the text is drafted. * docs: frame the SEP copy as the v1 baseline for decision-log proposals The previous note told readers not to propose changes here at all, which is the wrong instruction: the WG does want to propose beyond v1, just in this repo rather than on the upstream SEP. Reframe the file as the v1 baseline and route proposals through the existing decision log rather than a parallel mechanism. decisions.md already carries the ADR-lite format, the Proposed/Accepted/Superseded status idiom, and the precedent for consolidating a version's scope into one record (the 2026-07-16 v1 entry), so a change beyond v1 is simply the next dated entry. The note also defines the marker that ties an amended section back to its record, so v1 text stays distinguishable from accepted deltas as the document accumulates them. Align the README and related-work references to the same framing. * docs: mark the 2026-04-16 URI decision superseded in part Every other decision the v1 scope-down changed carries a forward pointer in its status line (2026-04-19, 2026-06-02, 2026-06-05, 2026-06-09). The 2026-04-16 URI entry was left as plain Accepted while three of its bullets no longer hold, so it reads as current guidance for index.json enumeration and the no-nesting rule. Give it the same treatment, naming which bullets changed and which parts of the URI convention carry forward, so the entry stays useful as a record of the structure it settled. * docs: add AGENTS.md and make the SEP PR link prominent Readers were landing on the repo-local SEP copy and taking it for the spec, which is how the stale version misled people in the first place. Say plainly, in the places they land, that the v1 spec text lives on modelcontextprotocol#2640: - README: a source-of-truth line at the top of the link block, above the charter. - The baseline copy: lead the header note with the PR rather than mentioning it mid-paragraph. - AGENTS.md: state the rule for agents working in this repo, along with how to propose beyond v1 via the decision log and the repo's markdown conventions. CLAUDE.md is a one-line pointer to AGENTS.md rather than a symlink, so it resolves on Windows checkouts too, where symlinks need Developer Mode and would otherwise land as a stub. * docs: use the @AGENTS.md import in CLAUDE.md A markdown link is not an import — Claude Code would have loaded the pointer line and never expanded AGENTS.md into context. The documented syntax is @path, which the docs specifically recommend over a symlink on Windows, where symlinks need Administrator privileges or Developer Mode. The maintainer note is a block-level HTML comment, which Claude Code strips before injecting the file, so it costs no context while staying visible to anyone opening the file. https://code.claude.com/docs/en/memory#agents-md * docs: tighten AGENTS.md to the source-of-truth rule Cut the project overview and conventions sections and lead with what an agent most needs to get right: the v1 spec text is on the PR, and the copy here is only as current as its pinned commit. CONTRIBUTING.md already covers participation and process.
5.1 KiB
Skills Over MCP Working Group
⚠️ Experimental — This repository is an incubation space for the Skills Over MCP Working Group. Contents are exploratory and do not represent official MCP specifications or recommendations.
📄 SEP-2640 (Skills Extension): modelcontextprotocol#2640 — the source of truth for the v1 spec text. Review and comments belong on the PR. The copy in this repo is a synced baseline for discussion; see docs/sep-draft-skills-extension.md.
Charter: modelcontextprotocol.io/community/skills-over-mcp/charter — mission, scope, membership, active work items, and success criteria.
Project board: Skills Over MCP WG
Meeting notes: Skills Over MCP WG discussions
Discord: #skills-over-mcp-wg
Open work: Pull requests — proposals, decisions, implementations, and other in-flight contributions welcome.
Why Skills Over MCP?
MCP servers give agents tools, but tools alone are insufficient for complex workflows — tool descriptions tell an agent what a tool does, not how to orchestrate multiple tools to achieve a goal. Skills bridge this gap. They are structured "how-to" knowledge: multi-step workflows, conditional logic, and orchestration instructions that can run to hundreds of lines.
Skills are context, and MCP is a context protocol. Agents already connect to remote services over MCP to get tools — they can get the know-how to use those tools through the same channel. A remote MCP server can serve both its tools and the instructions for using them together, as a single atomic unit. This also enables automatic discovery (connect to a server, find its skills), dynamic updates (server-side changes flow without reinstall), multi-server composition (skills orchestrating tools across servers), and enterprise distribution (RBAC, multi-tenant, version-adaptive content) — all through infrastructure MCP servers already provide.
See why-and-when.md for the full value proposition and a guide for when MCP distribution applies vs. simpler alternatives. For an accessible external framing of the premise, see Angie Jones's "Skills Over MCP" (Agentic AI Foundation) — "ship the manual with the product."
Problem Statement
Native "skills" support in host applications demonstrates demand for rich workflow instructions, but there's no convention for exposing equivalent functionality through MCP primitives. Current limitations include:
- Server instructions load only at initialization — new or updated skills require re-initializing the server
- Complex workflows exceed practical instruction size — some skills require hundreds of lines of markdown with references to bundled files
- No discovery mechanism — users installing MCP servers don't know if there's a corresponding skill they should also install
- Multi-server orchestration — skills may need to coordinate tools from multiple servers
See problem-statement.md for full details.
Repository Contents
| Document | Description |
|---|---|
| Problem Statement | Current limitations and gaps |
| Why Skills Over MCP? | Value proposition and decision guide |
| Use Cases | Key use cases driving this work |
| Approaches | Approaches being explored (not mutually exclusive) |
| SEP-2640: Skills Extension | Proposal to serve skills over MCP via the Resources primitive. The v1 baseline text is kept at docs/sep-draft-skills-extension.md, synced from the canonical SEP. Comments and review of v1 happen on the PR; changes beyond v1 are proposed as entries in the decision log. |
| Open Questions | Unresolved questions with community input (see also issues and meeting notes) |
| Experimental Findings | Results from implementations and testing |
| Related Work | SEPs, implementations, and external resources |
| Threat Model | Threat model for skills served over MCP (SEP-2640), with delivery-model recommendations and an archive appendix |
| Decision Log | Record of key decisions with context and rationale |
Contributing
See CONTRIBUTING.md for how to participate.