- MDX 96.1%
- TypeScript 3.9%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
c1fa4f315e* docs: add skills-extension-candidates tracker Scaffold a candidates list for MCP servers, dev tools, SDKs, and skills repositories that could adopt SEP-2640. Initial entries: FastMCP 3.0 Skills, chrome-devtools-mcp, hf-mcp-server, Hugging Face skills library, github-mcp-server (PR #2428 demo), Azure Skills Plugin. Cross-link from related-work.md and add a row to the README docs table. * docs: add Issue/PR tracker column to candidates table * docs: add client-mcp-support survey alongside candidates tracker * docs: link Azure MCP Server source in candidates table * docs: remove gemini-cli from client MCP support survey * docs: verify hermes-agent, switch source refs to main-branch links, refresh takeaways - Promote hermes-agent from first-pass to verified; note its per-server tool pattern (`mcp_{server}_read_resource` + `mcp_{server}_list_resources`) and confirm end-user docs exist - Drop stale line numbers throughout; convert path refs to GitHub source-file links on `main` (commit-pinned URLs decayed once files moved) - Goose: PR #8989 has landed, so describe current `(extension_name, uri)` required signature and drop the now-closed issue/PR tracking - Takeaways: collapse to three implementation patterns (Goose now fits the `(server, uri)` bucket), fix open-source count to fourteen, drop the smolagents name-drop (not in survey), add strands-agents alongside mastra for the internal-SDK-only pattern, and reframe the signature recommendation around server-resolution reliability rather than URI portability * docs: verify remaining first-pass clients, flip cline/Roo-Code to Yes Verified adk-python, agent-framework, crewAI, mastra, cline, Roo-Code against local source clones. Two corrections to prior state: - cline and Roo-Code both expose access_mcp_resource(server, uri) as a model-facing tool via McpHub.readResource. Flipped from No to Yes. - adk-python's load_mcp_resource takes resource_names: array[string] in a single call (not two-shot); opt-in via use_mcp_resources flag. Headline count updated from six to eight of fourteen open-source clients satisfying #2527. Cross-cutting observations and takeaways adjusted for the new (server, uri) family members and the four-pattern signature breakdown. Trust-model list extended. * docs: add Figma and Adobe MCP as SEP-2640 testing candidates * docs: update FastMCP 3.0 Skills entry with detailed notes on SEP-2640 compliance * docs: drop unconfirmed Cursor SEP-2640 entry, track latest SEP-2640 wire-contract PRs Remove the Cursor row + deep dive (reported WIP never confirmed). Add the in-flight PRs realigning to the 2026-06-05/06-09 SEP-2640 schema (frontmatter + archives[] index, resources/directory/read): hf-mcp-server#174, fast-agent#825, huggingface/skills#172. * docs: add Slack (interested) and Bloomberg (internal use) as SEP-2640 candidates * docs: remove archived Roo-Code from client survey, update strands repo to harness-sdk * docs: re-verify SEP-2640 implementations against current upstream main Both reference implementations have migrated to the July 2026 v1 shape, verified against fresh clones rather than the prior June commit pins: - hf-mcp-server (d794b10, v0.4.6): skills/list + skills/get, per-file {uri,digest} resources manifest, directoryRead:true, no index.json or archives. Migrated in #219 (merged 2026-08-03). Also records the snapshot/TTL model and HTTP-transport-only constraint. - fast-agent (79b903c, 0.10.1): pins SEP-2640 revision d7490ec, treats legacy index.json skill-md/archive entries as unsupported. Requires --prerelease=allow (pins fastmcp-slim 4.0.0b1), per @evalstate. Corrects the earlier note claiming implementations lagged the SEP: the #174/#825/#172 round merged 2026-06-19 and was never in flight, and a second realignment followed the v1 rework. Also fixes drift found while re-checking fast-agent's resource tool: smart_agent.py is gone (now core/harness_tools.py), get_resource is opt-in via harness_tools (default False, was unconditional), and server_name is now optional - the one surveyed client where the model may omit server identity. Runtime skill loading is still unshipped; #816 remains open. 🦉 Generated with [Claude Code](https://claude.com/claude-code) * docs: track SEP revision 0eb05fe and add mcpkit to the candidates tracker The SEP moved from d7490ec to 0eb05fe (2026-08-05). The delta is editorial for the wire contract -- skills/list, skills/get, and the per-file resources manifest are unchanged -- so d7490ec-pinned implementations stay compatible. Records what it does change: a soft reg-name constraint on the first skill-path segment, the skill root URI fixed as skill://<skill-path> with no trailing slash, whether skills/get carries ttlMs/cacheScope reopened, and normative host obligations in the security section. Adds mcpkit (panyam/mcpkit, Go, v0.3.0) from #118 as a candidate. It implements the pre-v1 index.json catalog shape with per-file digests, so the ecosystem is now split across draft revisions rather than uniformly caught up. 🦉 Generated with [Claude Code](https://claude.com/claude-code) * docs: refine mcpkit entry — deliberate tracking, partial v1 migration Checked mcpkit's issues and PRs rather than inferring alignment from code shape. Its lag is a tracked decision, not drift: - #1185 (merged 2026-08-04) implements origin-tagging and per-origin resolve citing SEP L179/L183/L185 -- the host obligations 0eb05fe made normative -- so it is already on v1 for the security section. #1187 adds a SEP-2640 security/conformance harness as a WG demo. - #780 is an explicit index-schema tracking issue that has absorbed the archives removal and the resources:[{uri,digest}] direction but waits on WG confirmation; its conformance fork pins provenance at 556154c. - The carrier change is still unbooked: nothing references skills/list or skills/get. - Archives are kept as a non-spec extended surface rather than deleted, unlike fast-agent -- a counter-case for whether deferring a feature removes it from the ecosystem. Sharpens the callout accordingly: the draft split runs within an implementation, not only between them, so "which draft does X implement" often has no single answer. 🦉 Generated with [Claude Code](https://claude.com/claude-code) |
||
| .github | ||
| docs | ||
| .gitignore | ||
| AGENTS.md | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| LICENSE | ||
| README.md | ||
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 |
| Skills Extension Candidates | MCP servers, dev tools, SDKs, and skills repositories that are candidates for adopting the skills extension |
| Client MCP Support | Survey of model-facing MCP resource loading and SEP-2640 support across open-source clients |
| Decision Log | Record of key decisions with context and rationale |
| Rationale | Design rationale for SEP-2640's Resources-based skills extension |
Contributing
See CONTRIBUTING.md for how to participate.