MCP-сервер теперь может отдавать не только инструменты, но и навыки: спецификация SEP-2640 стала официальным расширением протокола. Разбираем, как это устроено на уровне JSON-RPC, сколько контекста экономит и что проверить перед включением.
До недавнего времени навыки агента и его инструменты жили в двух разных каналах: файлы SKILL.md ставились из репозитория или маркетплейса плагинов, а MCP-серверы подключались отдельно, со своими правами и версиями. Расширение Skills over MCP меняет это: сервер отдаёт навык как обычный MCP-ресурс — вместе с инструментами, в одном канале доставки. Ниже — что именно описано в SEP-2640, какие вызовы делает клиент, как проверяется целостность файлов и где остаются риски.
io.modelcontextprotocol/skills. Сервер объявляет расширение в server/discover, клиент вызывает skills/list и skills/get, а содержимое файлов читает через обычный resources/read. Навык остаётся папкой с SKILL.md по спецификации Agent Skills — меняется только способ доставки.Agent Skills — это формат упаковки процедурных знаний: папка, в которой лежит SKILL.md с YAML-заголовком (name, description) и, при необходимости, вспомогательные файлы, скрипты и шаблоны. Агент читает описание навыка постоянно, а полный текст — только когда задача совпала с описанием. Это и есть progressive disclosure: контекст не тратится на инструкции, которые сейчас не нужны.
MCP (Model Context Protocol) отвечает за другое — за подключение к внешним данным и действиям: инструменты, ресурсы, промпты. Проблема была в том, что знания и доступ шли по разным каналам: навыки ставились плагином, MCP-серверы настраивались отдельно, права и версии тоже жили раздельно. Skills over MCP сводит это в один канал: сервер отдаёт и инструменты, и инструкцию по работе с ними.
| Способ доставки инструкций | Где живёт | Плюсы | Минусы |
|---|---|---|---|
| Навык на MCP-сервере | Рядом с инструментами, один сервер | Один канал, одни права, обновление без переустановки | Требует поддержки расширения клиентом |
| Навык из репозитория / плагина | Локальная папка или маркетплейс | Работает без сервера, версионируется в git | Отдельный канал доставки и отдельные права |
| Инструкции в описании инструмента | Схема tools/list | Ничего не нужно настраивать | Весь текст грузится при подключении, съедает контекст |
| Промпт в чате | Сама сессия | Максимально быстро | Не переиспользуется, теряется между сессиями |
Сервер, который поддерживает расширение, обязан объявить две вещи: возможность resources и само расширение io.modelcontextprotocol/skills в ответе server/discover. Клиент не гадает: он вызывает skills/list и skills/get только после того, как увидел объявление.
{
"capabilities": {
"resources": {},
"extensions": {
"io.modelcontextprotocol/skills": {
"directoryRead": true
}
}
}
}Флаг directoryRead необязательный и по умолчанию false: он разрешает клиенту просматривать папку навыка через resources/directory/read. Пустой объект расширения означает поддержку без чтения каталога. Примеры в документации используют ревизию протокола 2026-07-28 или новее.
{
"jsonrpc": "2.0",
"id": 1,
"method": "skills/list",
"params": {}
}
// ответ (сокращён)
{
"result": {
"resultType": "complete",
"skills": [{
"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}
]
}],
"ttlMs": 300000,
"cacheScope": "public"
}
}В манифесте перечислены все файлы навыка: SKILL.md и каждый вспомогательный файл, с SHA-256-дайджестом и размером в байтах. Вместо манифеста сервер может вернуть строку dynamic, если содержимое генерируется на лету. Список поддерживает пагинацию: при наличии nextCursor клиент передаёт его в params.cursor.
| Поле ответа skills/list | Что означает | Зачем нужно |
|---|---|---|
uri | Адрес SKILL.md навыка | Идентификация вместе с сервером-источником |
frontmatter | Все поля YAML-заголовка без изменений | Клиент не изобретает метаданные заново |
resources | Манифест файлов: URI, digest, size | Проверка целостности до загрузки в контекст |
ttlMs, cacheScope | Свежесть и область кэширования | Кэш не путает навыки разных серверов |
resultType | Всегда complete | Признак, что запись самодостаточна |
skill:// запрещено.Главный аргумент за такой способ доставки — не удобство, а расход контекстного окна. Когда инструкция живёт в описании инструментов, она загружается при каждом подключении. Когда инструкция живёт в навыке, при подключении видны только имя и описание, а полный текст читается по требованию.
Те же цифры фигурируют в разборах progressive discovery: на одном рабочем сценарии переход от «загрузить все определения» к «искать инструменты по мере надобности» сократил расход со 150 000 до 2 000 токенов, а в тесте с пятью серверами и 58 инструментами — снизил стартовые 55 000 токенов примерно на 85% и поднял точность выбора инструмента. Это данные авторов публикаций, а не независимый бенчмарк, и на своём стеке цифры будут другими.
Навык — это исполняемая единица поставки: инструкции могут подтолкнуть агента к опасному действию, а скрипт внутри папки — сделать что угодно в пределах выданных прав. Обзорная работа по экосистеме навыков оценивает долю community-навыков с уязвимостями в 26,1% — это чужие замеры, но порядок проблемы они показывают.
| Риск | Что делает протокол | Что остаётся на стороне хоста |
|---|---|---|
| Подмена файла навыка | SHA-256 digest на каждый файл | Сверить digest до загрузки в контекст |
| Навык с чужого сервера под тем же именем | идентичность = сервер + URI | Хранить сервер в реестрах и подтверждениях |
| Скрытая активация при чтении | чтение ≠ активация | Проводить чтение через путь загрузки с подтверждением |
| Вредные инструкции внутри навыка | не решается протоколом | Ревью текста и скриптов, ограничение прав |
| Полный доступ через инструменты сервера | частично: отзыв прав | Явное согласие человека на опасные операции |
Отдельно стоит правило: чтение SKILL.md через resources/read само по себе навык не активирует. Хост обязан провести чтение через свой путь загрузки навыка, проверить содержимое и, если требуется, запросить подтверждение пользователя. Это важно, потому что иначе любой сервер мог бы «влить» инструкции в контекст одним чтением ресурса.
my-skill/ SKILL.md references/checklist.md scripts/check.py
{"capabilities":{"resources":{},"extensions":{"io.modelcontextprotocol/skills":{}}}}skills/list -> {skills:[{uri, frontmatter, resources}]}resources/read uri=skill://my-skill/SKILL.md
# проверка: в логах клиента есть skills/list и чтение SKILL.md
Косвенный показатель — интерес к самим репозиториям. Публичный репозиторий навыков Anthropic остаётся самым заметным, спецификация MCP — второй по массе, а репозиторий самого расширения пока небольшой: это нормально для спецификации, которой меньше года.
Практический вывод: если вы пишете MCP-сервер и у него есть нетривиальный сценарий работы («сначала найди, потом сверь, потом обнови»), логично положить этот сценарий в навык рядом с инструментами. Если сценарий простой, достаточно описаний инструментов — лишний слой только запутает.
Skills over MCP решает конкретную инженерную задачу: убирает второй канал доставки и привязывает инструкции к тому сервису, который они описывают. Механика небольшая — объявление расширения, два метода, чтение файлов через resources и digest на каждый файл. Основная работа остаётся не в протоколе, а в качестве самих навыков и в дисциплине подтверждений на стороне хоста.