Я всё ещё предпочитаю MCP, а не Skills

Пост Дэвида Мола за апрель 2026 года проводит чёткую границу между двумя механизмами расширения возможностей LLM - MCP (Model Context Protocol) и Skills (внедрение инструкций через markdown-файлы) - и утверждает, что индустрия использует skills там, где место MCP.

Предлагаемое им различие простое: skills нужны для знаний, MCP - для доступа. Skill учит LLM пользоваться инструментом, который уже есть, - git, curl, gcloud, внутренним CLI. Он закрепляет правила рабочих процессов, описывает тонкости и избавляет модель от необходимости заново набивать одни и те же шишки в каждой сессии. MCP-сервер даёт LLM живое подключение к сервису - календарю, браузеру, базе данных, поисковому индексу - через типизированный интерфейс инструментов с полноценной аутентификацией.

Почему это различие важно

Когда инструкции skill'а начинаются со слов "сначала установите этот CLI", по мнению Мола, skill плохо выполняет работу MCP. Проблемы нарастают как снежный ком:

Теряется переносимость. Skills, зависящие от локальных CLI, работают только в вычислительных окружениях - Claude Code, Codex, Perplexity Computer. Стандартный Claude, ChatGPT и мобильные клиенты исполнить их не могут. Удалённый MCP-сервер - это просто URL; он работает везде, где клиент может делать HTTP-запросы.

Фрагментируется развёртывание. Каждому "skill'у как сервису" нужен свой бинарник, свой способ установки (npm, brew, pip, go install), своё управление секретами (.env-файлы, переменные окружения, временные учётные данные). MCP это централизует: аутентификацию берёт на себя сервер (OAuth для удалённых, на уровне процессов для локальных), а клиенту известен только endpoint.

Обновления становятся ручными. Изменился skill - и каждый пользователь должен затянуть к себе новый markdown. Изменился MCP-сервер - и все подключённые клиенты получают обновление при следующем же вызове. Семантика обновлений удалённого MCP совпадает с веб-API, в чём и заключается суть.

Раздувается контекст. Skill загружает файл SKILL.md целиком в окно контекста - инструкции, примеры, краевые случаи, всё подряд, независимо от того, нужно ли это модели прямо сейчас. MCP предоставляет типизированные сигнатуры инструментов (имя, описание, input schema), которые клиент может показывать выборочно. Полная документация о поведении инструмента живёт на сервере, а не в контексте модели.

Две статьи расходов остаются за рамками этой оценки. Определения инструментов встраиваются в начало запроса, поэтому их выборочная подача меняет состав каталога прямо посреди сессии и инвалидирует кэш предшествующего диалога - prompt-caching-in-agents оценивает такой компромисс как выигрыш в пару сотен токенов схем ценой повторного prefill'а десятков тысяч. А типизированный интерфейс инструментов оставляет каждый payload в стенограмме запросов, тогда как скрипт, делающий те же вызовы в песочнице, возвращает один итоговый объект; code-mode-token-savings на реальной нагрузке оценивает это как 26 сырых вызовов против одного.

Где skills всё ещё выигрывают

Skills остаются правильным выбором, когда подключаться не к чему. Научить модель тому, что команда развёртывания в вашей команде - just deploy staging, и что она требует чистого состояния git, - это знание, а не сервис. Задокументировать, что конкретный MCP-сервер использует даты в формате YYYY-MM-DD и ограничивает выдачу 50 результатами, - тоже знание. Стандартизировать внутренний сленг организации, чтобы модель не путала "релиз" (маркетинговое событие) и "релиз" (git-тег), - знание.

Формулировка Мола: skills - это шпаргалки, а не коннекторы. Шпаргалка может снабжать примечаниями MCP, документируя особенности его поведения, но она не должна заменять собой MCP, оборачивая CLI, делающий то, за что должен отвечать сервер.

Гибридный паттерн

На практике Мол использует и то, и другое. MCP-серверы отвечают за живое управление сервисами (DEVONthink через локальный MCP, microfn и Kikuyo через удалённые MCP, MCP Nest для проброса туннелей от локальных MCP к удалённым клиентам). Skills документируют поведение этих MCP - подводные камни в параметрах, требования к форматам, неочевидные имена инструментов. Разделение по слоям получается чистым: MCP даёт саму возможность, skill учит модель грамотно её использовать.

Как это соотносится с инструментами агентов в этой вики

Этот Second Brain активно использует skills для Claude Code - /ingest, /query, /lint, /webfetch представляют собой файлы skills, внедряющие инструкции в диалог. По классификации Мола, это skills уровня знаний (они обучают модель рабочему процессу с помощью инструментов, которые у неё уже есть, - Read, Write, Glob, Grep, WebFetch). Никаких CLI для установки, никаких сервисов для подключения. Это корректное применение skills.

Интеграция с Telegram, напротив, устроена как MCP-сервер - она даёт Claude живое подключение к Telegram Bot API через типизированные инструменты (reply, react, edit_message). Мол назвал бы это правильным применением MCP. Если бы вместо этого кто-то сделал "Telegram skill" с описанием того, как вызывать Bot API через curl, это был бы пример того, как skills плохо выполняют работу MCP.

У botctl есть собственная система SKILL.md с трёхуровневым иерархическим поиском и загрузкой по требованию - структурно такая же, как skills в Claude Code, и с тем же назначением на уровне знаний. Опасение Мола о раздувании контекста из-за загрузки файлов skills целиком в botctl нивелируется подгрузкой по требованию (Claude запрашивает skill, когда он нужен, вместо того чтобы загружать всё на старте). Система skills в Claude Code работает так же.

build-your-own-openclaw рассматривает расширение через skills в Phase 1 (step 2) как механизм обучения агента новым возможностям без изменения кода. Мол сказал бы, что это правильно для внедрения знаний; для доступа же к сервисам в Phase 2 этого руководства (событийная архитектура, мультиплексирование каналов) должны вступать в силу MCP-подобные паттерны.

cli-anything - это готовая реализация гибридного паттерна от начала до конца: плагин HKUDS генерирует обе половины разом для любого GUI-приложения - CLI на Python Click, вызывающий настоящий бэкенд (слой возможностей), и SKILL.md, полученный из собственных Click-декораторов CLI (слой знаний). Ограничение в том, что "сервис" здесь - это локальный подпроцесс, поэтому подход работает только в оснащённых вычислительными ресурсами средах агентов; он не решает проблему переносимости по Молу для мобильных или веб-клиентов, которым всё равно понадобился бы удалённый MCP.

Предложение по терминологии - переименовать skills в LLM_MANUAL.md, а MCP в "Connectors" - не прижилось, но лежащее в основе различие (руководство против коннектора, знание против доступа) достаточно отчётливо, чтобы быть полезным независимо от названий.