* 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>
12 KiB
Use Cases
1. Complex Workflow Orchestration
Skills that teach agents how to perform multi-step workflows that they wouldn't know how to execute from tool descriptions alone.
Example: Bob Dickinson's mcpGraph toolkit requires a skill file of 875+ lines to instruct agents on building directed graphs of MCP nodes. This orchestration logic is "way more than you'd want to put in instructions."
Community input:
"Skills may define how to use tools, possibly from different servers, to accomplish complex workflows requiring contextual reasoning that could not be coded with MCP tools." — Daniele Martinoli
2. Conditional Workflows
Workflows that reference tools conditionally based on context, requiring rich structured instructions that can be dynamically loaded.
Example: A skill that guides an agent through different branches of a debugging workflow depending on the type of error encountered, loading relevant sub-instructions only when needed.
3. Multi-Server Composition
Skills that leverage tools from multiple off-the-shelf servers where you can't (or don't want to) modify their individual instructions. Skills can also make it more natural to translate ad-hoc tool-call-based workflows into scripted workflows, without fundamentally changing the content of the skill.
Related: agentskills/agentskills#110 — Skill dependency declaration
Community input:
"I think there might also be a subtle difference between the kind of skill that allows you to orchestrate a set of tools, possibly from different servers, to do something the agent wouldn't have necessarily known how to do without the skill (more of a skill registry issue), and the 'you're pretty much going to need this skill to make use of this server at all' (an MCP server registry issue, maybe)." — Bob Dickinson
"The ecosystem has been too focused on the server being the main deliverable in some ways, and actually there's a lot that can be done in terms of composition that we miss by people generally imagining their code as being the server boundary and not providing functionality more as a library." — Sam Morrow
Beyond multi-server tool orchestration, skills themselves may be composable — one skill depending on another skill's output or behavior. This extends the dependency model beyond tool availability to skill availability, and raises questions about declarative dependency metadata. See Open Question 4 for the emerging proposal on host-mediated dependency resolution.
See also: #39 — Skill dependency declaration, #45 — Worked examples for multi-server composition
4. Progressive Disclosure
Skills broken into linked sets of files for effective context management, loaded progressively as the agent needs them rather than all at once.
Community input:
"Especially mimicking progressive disclosure via resources and dynamically adding new ones as the agent reads pieces of the skill has been quite handy!" — Ozz / Juan Antonio Osorio
Practical limitation: In non-visual execution environments (CLI agents, headless), skills lack the "collapse" mechanism of UI-based progressive disclosure. Without a UI affordance to hide/show content, all disclosed context remains in the model's context window, contributing to the adherence decay problem (see Skill Reliability and Adherence). Tool-based expansion partially addresses this, since pruning a tool call also collapses the context, but this is not a general solution.
At scale: A server may expose hundreds or thousands of skills, but a client may only need a handful. This reinforces the need for selective loading via progressive disclosure rather than loading all skill content at once.
"A server can contain 100s or 1000s of skills as an extreme but a client might only need handful of them." — Kaxil Naik (Astronomer), via Discord
Related: Anthropic's guidance on progressive disclosure
See also: #45 — Worked examples for progressive disclosure, #40 — Client-side reference implementation for model-driven resource loading
5. Server-Skill Pairing
Servers that are difficult or impossible to use effectively without an accompanying skill.
Community input:
"Clients of the registry presumably understand MCP, but there is no guarantee that they understand skills. So if it is going to be hard for an agent to use the server without the 'skill' then doesn't it make sense for the MCP server to contain all the instructions necessary to use it?" — Cliff Hall
Example: chrome-devtools-mcp ships with a skills/ folder that requires a separate install path from the MCP server itself.
6. Skill Versioning and Updates
Skills that evolve over time and need version-aware distribution.
Community input:
"I'd like for skills over MCP to enable the client to make use of the version attribute... If a skill stored locally has an older version than the skill seen on the MCP server, the client can download the latest skill on the spot." — woweow
7. Enterprise Integration
Organizations building official MCP servers for established platforms are looking to skills as a distribution mechanism for domain-specific workflow guidance.
Community input:
"As part of Apache Airflow community, we are planning to build our official MCP Server... and I am specifically interested in integrating Skills as part of the MCP protocol." — Kaxil Naik
Related: Apache Airflow AIP-91 (MCP integration)
8. Version-Adaptive Skill Content
Skills whose instructions and examples dynamically adapt based on the platform or framework version in use, rather than versioning the skill artifact itself.
Example: Apache Airflow 2.x and 3.x have substantially different APIs, operators, and recommended patterns. A version-adaptive skill detects which Airflow version is running and returns only the relevant guidance — e.g., TaskFlow decorators in 2.x vs. updated Asset-based patterns in 3.x — so the agent never suggests deprecated or unavailable APIs.
Community input:
"As a SaaS company (Astronomer) building on Airflow, we need skills that adapt their content based on the Airflow version the customer is running. A skill that returns Airflow 2.x guidance to an Airflow 3.x user is worse than no skill at all. While skill reference files are valuable, a single version-aware skill that delivers tailored guidance is far more useful than hundreds of reference files where Airflow 2 and 3 diverge — best practices, recommended operators, and even DAG authoring patterns look fundamentally different between the two." — Kaxil Naik
9. Commercial Multi-Tenant Skills
SaaS companies serving per-user skill content that varies by subscription tier, role, or tenant — with auditing, logging, and RBAC governing what each user can access.
Example: A SaaS platform exposes the same MCP server endpoint to all customers, but a free-tier user receives basic workflow guidance while an enterprise user gets advanced optimization skills, custom operator libraries, and tenant-specific configuration — all controlled through RBAC policies and audit-logged per request.
Community input:
"At Astronomer we need to serve different skill content to different customers based on their subscription tier and role, with full audit logging. This goes beyond enterprise adoption — it's about multi-tenant commercial delivery of skills with fine-grained access control." — Kaxil Naik
10. Documentation as MCP Server
MCP servers whose primary function is serving documentation through a small set of tools — typically a search tool (with a local or remote index) and a fetch tool (returning specific markdown pages). This pattern applies progressive disclosure to documentation: the model receives a list of available topics and selectively loads content as needed.
Examples:
- Strands Agents MCP server uses a local TF-IDF index for search and on-demand fetching of individual doc pages
- AWS Knowledge MCP server is a fully managed remote MCP server that indexes AWS documentation, code samples, and regional availability
- MCPDoc serves documentation via the llms.txt convention — listing titles so the model can selectively enable content
- Mintlify auto-generates MCP endpoints for public documentation sites (e.g., modelcontextprotocol.io/mcp, agentclientprotocol.com/mcp)
Skills connection: These doc servers often pair with skill-like instruction files that provide quick code samples and direct the agent to use the MCP server for deeper information. For example, the Strands Kiro powers bundle starter instructions alongside the MCP server.
Community input:
"I'm seeing a common pattern of MCP servers with two tools:
search_docs,fetch_doc.search_docshas either a local index or a remote index, andfetch_docsgenerally is just a web fetch of a specific markdown documentation page." — Clare Liguori (AWS), via Discord
11. Skills + MCP Server Plugins
Coding assistants are converging on plugin capabilities that let users one-click install a combination of skills and MCP servers. The skill files within these plugins serve different roles — some describe how to use the remote MCP server, while others describe how to use local CLIs or tools — but they're bundled and distributed as a single installable unit.
This is related to but distinct from Server-Skill Pairing: that use case focuses on servers that need skills to function; this one focuses on the distribution and composition mechanism that bundles skills with servers (and other tools) into a cohesive plugin.
Examples:
- Kiro uses "powers" and "steering files" — functionally the same as plugins + skills
- Supabase Kiro powers bundle skill files that describe both how to use the remote MCP server and how to use the Supabase CLI
- The AWS MCP server provides
retrieve_agent_sopandcall_awstools — the Agent SOPs are effectively skills that guide multi-step workflows through thecall_awstool
Community input:
"Several coding assistants incl Claude Code now have plugin capabilities that let you one-click install a combination of skills and MCP servers. Kiro calls them powers and steering files, but if you squint it's the same as plugins + skills." — Clare Liguori (AWS), via Discord