- MDX 96.1%
- TypeScript 3.9%
| Filename | Latest commit message | Latest commit date |
|---|---|---|
924a356da5* docs: log URI scheme decision for skill resources Backfills a decision-log entry for the `skill://` URI convention adopted via PR #70. Captures the convergence signal, the key reversal (decoupling path from skill name), and notes the month-long open-review period on GitHub and in Discord. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com> * docs: update rationale for URI scheme decision to clarify discussion context * docs: broaden URI scheme decision to cover domain-specific schemes Acknowledges implementations that used domain-specific URI schemes alongside skill://, and frames the adopted pattern as a recommended convention rather than a universal rule. * docs: align URI scheme decision with SEP draft's final position Updates the 2026-04-16 URI scheme entry to reflect where the draft SEP actually landed rather than the survey's earlier recommendation: - Final path segment MUST equal the skill's frontmatter name (not fully decoupled). Prefix segments remain server-chosen. - Enumeration is via the well-known skill://index.json resource, not scoped resources/list. - Domain-specific URI schemes are permitted when indexed, which the earlier wording placed in Context as observed convergence rather than as an allowed Decision point. - No-nesting phrasing aligned with the SEP ("descendant directory of a skill"). Context also restored to the survey's four-implementations framing. * docs: restore Context framing on URI scheme decision Restores the earlier "Several...etc." wording and "Resources to represent skills" framing in Context; keeps the SEP-structural edits (final-segment-equals-name, index.json, domain-specific schemes). * docs: calibrate enumeration wording to match SEP SHOULD level The SEP specifies servers SHOULD expose skill://index.json, with an explicit escape hatch for unenumerable catalogs. Previous wording used RFC 2119 OPTIONAL which understated the recommendation. Also notes alignment with the Agent Skills well-known URI index format and folds template entries into the enumeration bullet where they belong. --------- Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com> |
||
| .github | ||
| docs | ||
| .gitignore | ||
| 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.
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
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.
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) |
| Open Questions | Unresolved questions with community input |
| Experimental Findings | Results from implementations and testing |
| Related Work | SEPs, implementations, and external resources |
| Decision Log | Record of key decisions with context and rationale |
| Draft SEP: Skills Extension | Pre-submission SEP draft defining the skill:// resource convention |
Contributing
See CONTRIBUTING.md for how to participate.