* docs: point README and AGENTS.md at the released spec and official docs SEP-2640 is Final and the extension ships from specification/stable/skills.mdx, so the README now leads with a Specification section linking the spec file, the official docs page (modelcontextprotocol.io/extensions/skills/overview), the published SEP, and the client matrix. The experimental banner is replaced with a note that docs/ holds working documents; the charter, pulls, and issues links move off the redirecting experimental-ext-skills / charter URLs. AGENTS.md no longer names the SEP PR as the source of truth; it points agents at the stable spec page and describes the decision-log flow against that file. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: accepted spec changes land in a draft revision, not the stable file The stable specification is a released snapshot. README and AGENTS.md now say accepted decision-log proposals go into a draft revision that ships as a new release, matching the ext-tasks specification layout. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: move pre-release design documents to docs/archive SEP-2640 is Final, so docs/ now holds only living working documents. Eight historical documents move to docs/archive with an index explaining what each was and what superseded it: the SEP baseline copy, why-and-when, use-cases, approaches, skill-uri-scheme, glossary, client-mcp-support (superseded by the official client matrix), and agent-plugins-analysis. Files the published SEP links to by path (decisions, experimental-findings, open-questions, problem-statement, rationale, related-work, skill-meta-keys) stay in place so those links keep working. Cross-links are rewritten and verified; the README contents table is trimmed to match. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: archive open-questions and skill-meta-keys Both are pre-release documents whose outcomes live in the decision log and the specification. The published SEP links to them by path; a companion change in modelcontextprotocol/modelcontextprotocol repoints those links. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: fix sibling links inside archived open-questions and skill-meta-keys Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: keep only the decision log and rationale in docs/ threat-model, experimental-findings, findings-template, problem-statement, and related-work move to docs/archive with index rows. The candidates tracker and the archived client-support survey are removed in favor of the official extension client matrix, and links to them are repointed there. README drops the Why and Problem Statement sections, which duplicate the SEP's Motivation and the official overview page. CONTRIBUTING routes new implementation findings to GitHub issues. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: fix sibling links inside newly archived documents Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: add a concise implementations list One table each for servers/SDKs and hosts, one line per entry, replacing the retired candidates tracker and the related-work implementation tables. Seeded from those plus PR #141 and issue #144. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: put tracking links in the Status column of the implementations list Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: add a vendor/community category to the implementations list Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: replace the interim reference package with the TypeScript SDK row The @olaservo/ext-skills package is retired in favor of first-class skills APIs in the TypeScript SDK (typescript-sdk#2798, phase 1 in #2818). The archived related-work page now points at implementations.md for current information. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: drop pre-SEP rows from the implementations list They are already recorded in the archived related-work page; the list now points there instead. FastMCP stays because its row tracks the migration to v1. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: add official SDK progress, Tachyon, and Inspector 2.6.0 to implementations From the WG Discord channel and the SDK repos as of 2026-09-15: Go, TypeScript, Python, and C# SDKs all have open SEP-2640 PRs (Go passes conformance); the conformance suite merged; Inspector 2.6.0 shipped skills verification; Tachyon reports a server implementation. Adds an "in progress" status for open PRs. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: track Goose host support via the official issue Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: only tag community rows in the implementations list Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: tag MCP-project rows as official in the implementations list Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: split the implementations list into SDKs, servers, and hosts Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * docs: add MCPJam Inspector to hosts Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> * Revise implementations table format and content Updated the implementations table to include language and status columns. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> * Correct links and clarify documentation references Updated links to SEP-2640 and clarified document references. Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com> --------- Co-authored-by: Claude Fable 5.1 <noreply@anthropic.com> Co-authored-by: Sambhav Kothari <sambhavs.email@gmail.com> Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
4.9 KiB
Contributing
How to Participate
This Working Group welcomes contributions from anyone interested in skills distribution over MCP. You can participate by:
- Joining discussions in the #skills-over-mcp-wg Discord channel (info on joining the Discord server here)
- Opening or commenting on GitHub Discussions in the main MCP repo
- Sharing findings from your own implementations as GitHub issues
- Contributing to documentation and pattern evaluation
Communication Channels
| Channel | Purpose | Response Expectation |
|---|---|---|
| Discord #skills-over-mcp-wg | Quick questions, coordination, async discussion | Best effort |
| GitHub Discussions | Meeting notes, long-form technical proposals, experimental findings | Weekly triage |
| This repository | The specification, decision log, and design rationale | Updated after meetings |
Coordination with the Agent Skills Spec
The Agent Skills spec is maintained in the agentskills/agentskills repository. For topics that intersect with both this WG and the Agent Skills spec (e.g., protocol design questions, proposed extensions, or alignment on terminology), the recommended channel is Discussions in that repository.
Before opening a discussion, review the Agent Skills contributing guide.
Meetings
Working Session cadence is defined in the charter; the schedule is published on meet.modelcontextprotocol.io. Meeting requirements — advance notice, agendas, and notes — follow MCP group governance.
Notes are published to Meeting Notes — Skills Over MCP WG. Scheduling surveys and between-meeting coordination happen in #skills-over-mcp-wg.
Decision-Making
Scope and per-decision-type authority are defined in the charter. The decision progression (lazy consensus → formal vote → escalation) follows MCP group governance.
Outputs include:
- SEPs we shepherd from proposal through review (Extensions Track and related protocol changes)
- Reference implementations demonstrating skill discovery and consumption
- Documented requirements, evaluated approaches, and experimental findings
Contribution Guidelines
Sharing Implementation Findings
Findings from implementations are shared as GitHub issues rather than as documents in this repository. The pre-v1 findings and their template are frozen in docs/archive/. When reporting a finding:
- Include enough detail for others to reproduce or evaluate
- Note which clients and servers were tested, and the specification revision
- Be explicit about what worked, what didn't, and what remains untested
- Write "Not documented" for missing details instead of inferring them
- Attribute community input with GitHub handles and link to the source where possible
Community Input
When adding quotes or input from community discussions:
- Attribute to the contributor by name and GitHub handle
- Link to the original source (Discord thread, GitHub comment, etc.) where possible
- Present input as blockquotes to distinguish it from editorial content
Decision Log
Significant decisions made during meetings or through async discussion should be recorded in docs/decisions.md using the ADR-lite format defined there. A decision is worth logging when it:
- Chooses one approach over alternatives
- Sets or changes the group's scope
- Establishes a convention or coordination mechanism
Add a new entry after the meeting where the decision was made or when consensus is reached asynchronously. Include context, the decision itself, rationale, and links to relevant issues, PRs, or discussion threads.
Filing Issues
Use GitHub Issues for:
- Proposing new approaches or use cases
- Reporting gaps in documentation
- Tracking action items from meetings