MCP 的 Skills 扩展定稿，SKILL.md 可以从服务器按需下发

MCP 原来只有两层：Tools 回答”能做什么”，Resources 回答”能访问什么”。缺的第三层——怎么把工具和资源组合成一套可复用、可分发的工作流——现在补上了。

定稿的是什么

Skills 扩展（SEP-2640）已标记为 Final，官方扩展标识是 io.modelcontextprotocol/skills。一个技能就是一个含 SKILL.md 加可选附属文件的目录，沿用 Agent Skills 规范；这个扩展只定义”怎么发现和取回”，没有发明新传输机制，全部搭在既有的 Resources 原语上。

服务器侧要做的：

{
  "capabilities": {
    "resources": {},
    "extensions": {
      "io.modelcontextprotocol/skills": { "directoryRead": true }
    }
  }
}

声明了就必须实现 skills/list 和 skills/get，文件通过 resources/read 提供。directoryRead 是可选的目录浏览，默认 false。

清单长什么样

skills/list 返回的每个条目是完整的，客户端不需要再为元数据补一次 skills/get：

{
  "uri": "skill://code-review/SKILL.md",
  "frontmatter": {
    "name": "code-review",
    "description": "Review code using the team's checklist."
  },
  "resources": [
    { "uri": "skill://code-review/SKILL.md", "digest": "sha256:d2489d6c...", "size": 149 },
    { "uri": "skill://code-review/references/checklist.md", "digest": "sha256:dbab2de7...", "size": 65 }
  ]
}

frontmatter 是完整 YAML 头信息原样转 JSON，不做字段裁剪；resources 要么是全量文件清单（每个文件带 URI、SHA-256 摘要、字节数），要么是字符串 "dynamic"（内容按需生成、没有稳定摘要时用）。URI 约定是 skill://<name>/<file>，最后一段必须等于技能名，前面允许加组织前缀。列表与单取的响应都要带 resultType、ttlMs、cacheScope。

关键的一条：读了不等于激活了

官方文档特意写清楚——通过 resources/read 读 SKILL.md 本身不激活技能。要加载，得由宿主走它自己的技能加载路径：校验内容、套用需要的用户批准、记录来源，然后才进模型上下文。换句话说，完整性闸门在宿主那一侧，不在传输层。

对做产品的人意味着什么

以前一套技能分发出去，就是让人复制目录。服务端改一版，所有客户端都得重装一遍。现在服务端改完，客户端下次 skills/list 就拿到新摘要，宿主发现文件变了会重新走批准流程。“改了要通知所有人重新装”这个环节消失了。

如果你的产品里有一堆”我们总结出来的最佳实践”现在只能写在帮助文档里，这条路值得看一眼：它们可以变成带指纹、可校验、按需拉取的对象。

泼冷水

官方页面上有一句不能漏：SDK 与宿主支持仍在实现中（“SDK and host support is still being implemented”）。也就是说现在还没有端到端跑通的主流实现，你要么自己写服务端，要么等。规范定稿和实现可用之间通常隔着两三个季度。

另外，摘要校验解决的是”文件有没有被篡改”，不解决”这份技能本身是不是恶意的”。宿主那道用户批准才是真正的闸门——别因为有了 SHA-256 就自动放行。

原文：https://modelcontextprotocol.io/extensions/skills/overview