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)
51 lines
5.5 KiB
Markdown
51 lines
5.5 KiB
Markdown
# 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](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/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`](docs/sep-draft-skills-extension.md).
|
|
**Charter:** [modelcontextprotocol.io/community/skills-over-mcp/charter](https://modelcontextprotocol.io/community/skills-over-mcp/charter) — mission, scope, membership, active work items, and success criteria.
|
|
**Project board:** [Skills Over MCP WG](https://github.com/orgs/modelcontextprotocol/projects/38/views/1)
|
|
**Meeting notes:** [Skills Over MCP WG discussions](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-wg)
|
|
**Discord:** [#skills-over-mcp-wg](https://discord.com/channels/1358869848138059966/1464745826629976084)
|
|
**Open work:** [Pull requests](https://github.com/modelcontextprotocol/experimental-ext-skills/pulls) — 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](docs/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"](https://aaif.io/blog/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](docs/problem-statement.md) for full details.
|
|
|
|
## Repository Contents
|
|
|
|
| Document | Description |
|
|
| :--- | :--- |
|
|
| [Problem Statement](docs/problem-statement.md) | Current limitations and gaps |
|
|
| [Why Skills Over MCP?](docs/why-and-when.md) | Value proposition and decision guide |
|
|
| [Use Cases](docs/use-cases.md) | Key use cases driving this work |
|
|
| [Approaches](docs/approaches.md) | Approaches being explored (not mutually exclusive) |
|
|
| [SEP-2640: Skills Extension](https://github.com/modelcontextprotocol/modelcontextprotocol/pull/2640) | Proposal to serve skills over MCP via the Resources primitive. The v1 baseline text is kept at [`docs/sep-draft-skills-extension.md`](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](docs/decisions.md). |
|
|
| [Open Questions](docs/open-questions.md) | Unresolved questions with community input (see also [issues](https://github.com/modelcontextprotocol/experimental-ext-skills/issues) and [meeting notes](https://github.com/modelcontextprotocol/modelcontextprotocol/discussions/categories/meeting-notes-skills-over-mcp-wg)) |
|
|
| [Experimental Findings](docs/experimental-findings.md) | Results from implementations and testing |
|
|
| [Related Work](docs/related-work.md) | SEPs, implementations, and external resources |
|
|
| [Threat Model](docs/threat-model.md) | Threat model for skills served over MCP (SEP-2640), with delivery-model recommendations and an archive appendix |
|
|
| [Skills Extension Candidates](docs/skills-extension-candidates.md) | MCP servers, dev tools, SDKs, and skills repositories that are candidates for adopting the skills extension |
|
|
| [Client MCP Support](docs/client-mcp-support.md) | Survey of model-facing MCP resource loading and SEP-2640 support across open-source clients |
|
|
| [Decision Log](docs/decisions.md) | Record of key decisions with context and rationale |
|
|
| [Rationale](docs/rationale.md) | Design rationale for SEP-2640's Resources-based skills extension |
|
|
|
|
## Contributing
|
|
|
|
See [CONTRIBUTING.md](CONTRIBUTING.md) for how to participate.
|