ext-skills holds the MCP Skills extension spec, and that is the whole product

This repository is a specification, not an installable package

The first thing to understand about modelcontextprotocol/ext-skills is that it holds no runtime code for you to depend on. It is the home of the official Skills extension for the Model Context Protocol, and the extension itself is identified by the identifier io.modelcontextprotocol/skills. The extension is based on SEP-2640, and the repository is maintained by the Skills Over MCP Working Group. Everything you would use at runtime lives elsewhere: the specification document, the working group's notes, and a documentation site. That makes the audience narrow and specific. If you are writing an MCP server that serves skills, an MCP client that consumes them, or a reviewer deciding whether a proposed extension conforms, this repository is where the normative text lives. If you are looking for a package to add to your requirements file, there is nothing here to add.

SEP-2640 turned the Skills extension into an accepted protocol change

The extension exists as protocol text because a formal proposal went through the Model Context Protocol process. SEP-2640, the Skills Extension, is listed with a status of Final, and the accepted pull request was merged on 2026-09-13. The specification document is written against a specific base protocol revision, 2026-07-28, and that pairing matters for anyone implementing it: the extension assumes the primitives and semantics of that base revision, so an implementation against a different revision is not automatically conformant. Two further pointers sit next to the spec in the documentation table. One is the condensed official overview with examples and message flow, and the other is the extension client matrix, which records which clients implement the extension. For an adopter, that matrix is the closest thing to a support statement.

The stable spec is frozen, so changes travel through the decision log

The repository makes a deliberate choice about how a released specification may be edited: the stable specification is a released copy and is not edited in place. Changes are proposed as dated entries in the decision log at docs/decisions.md, following the process described in AGENTS.md, and once a change is accepted it lands in a draft revision of the specification that ships as a new release. The practical effect is that the file at specification/stable/skills.mdx will not grow new clauses under you, and a reader can treat it as a fixed point in time. The cost is that adopting a new behaviour means waiting for a new release rather than pulling master and reading a changed paragraph. The repository has no GitHub releases, so the release rhythm of the extension itself is not visible from the repository listing, and the last push was on 2026-10-16.

docs/ separates working documents from the specification

The docs directory holds three current documents and one frozen archive, and the README is explicit that none of the contents of docs/ are part of the specification. docs/decisions.md is described as an ADR-lite record of the group's decisions and the vehicle for proposing changes to the specification. docs/rationale.md carries the design rationale for the Resources-based extension, which tells you the shape of the design without making you infer it from the normative text. docs/implementations.md lists servers, SDKs, and hosts that serve or consume skills over MCP, so it is the closest thing to an ecosystem directory. docs/archive/ holds earlier design documents, findings, and trackers, frozen when SEP-2640 was marked Final. Treat the archive as history rather than guidance; a document in there may contradict the stable spec, and the spec wins.

The documentation site is VitePress with a mermaid plugin

The site is a VitePress project driven by npm scripts, and the whole configuration sits in the package.json at the repository root:

  "engines": {
    "node": ">=22"
  },
  "scripts": {
    "docs:dev": "vitepress dev",
    "docs:build": "vitepress build",
    "docs:preview": "vitepress preview"
  },

Installing the dev dependencies and running the docs:dev script gives you a local preview with hot reload, docs:build produces the static site, and docs:preview serves the built output for a last check before publishing. The site build needs Node 22 or newer, because that is the engines constraint declared in the same file. The rendering stack is small and specific:

  "devDependencies": {
    "mermaid": "^11.17.0",
    "vitepress": "^1.6.4",
    "vitepress-plugin-mermaid": "^2.0.17"
  }

The mermaid plugin is the notable part: protocol extensions are usually explained with message flow diagrams, and this setup lets those diagrams live in the same MDX pages as the text. The project is marked private with version 0.1.0 and the description states that it is documentation for the MCP Skills extension.

Adoption depends on client support listed somewhere else

Here is the practical gap in this repository. The specification tells you what a conformant Skills extension looks like, but it cannot tell you whether the client on your user's machine will understand it. Support information is spread across several places: the extension client matrix on the protocol site for which clients implement the extension, docs/implementations.md inside the repository for servers, SDKs and hosts, the official overview for examples and message flow, and the Motivation section of SEP-2640 for the case for serving skills over MCP at all. The working group also keeps a charter page with mission, scope, membership, active work items and success criteria, a project board, meeting notes in the protocol discussions, a Discord channel, and an invitation for pull requests and issues. None of that is packaged as a machine readable capability list, so checking client support is still a manual lookup.

Apache-2.0, no releases, and a repository that is mostly text

The licence is Apache-2.0, stated in the package.json metadata and backed by a LICENSE file at the repository root. For a specification that implementers may copy clauses or code fragments from, that is the relevant detail: Apache-2.0 carries an explicit patent grant and an attribution requirement, which is a different posture from a permissive MIT-style notice, and you should read the terms yourself rather than treat the label as a summary. On maintenance, the repository is not archived and the last push was on 2026-10-16, so the working group is still moving. There are no GitHub releases, so the stable specification is versioned by release rather than by tag in this repository, and the top level contains only documentation infrastructure: docs/, specification/, public/, index.md, a .vitepress directory, AGENTS.md, CLAUDE.md, CONTRIBUTING.md, SECURITY.md and a package-lock.json.

Editorial conclusion

Use ext-skills when you are implementing or reviewing a Skills extension for MCP and need the exact wording of the stable specification, the base protocol revision it was written against, and the dated decision entries behind each clause. Do not expect a package, a server or a runtime dependency from it: the package.json is marked private, the repository has no GitHub releases, and nothing here is installable by an application. Before building against it, confirm that your client appears in the extension client matrix, and read the decision log entries for the revision you are targeting rather than assuming the stable file still reflects the latest working group discussion.

Frequently asked questions

Official sources

1. Issues
2. License: Apache-2.0
3. modelcontextprotocol/ext-skills on GitHub
4. README