AI-сообщество активно продвигает Skills как новый стандарт для расширения возможностей LLM. Я с этим не согласен. Skills отлично работают как чистая передача знаний — когда нужно объяснить модели, как использовать уже установленный инструмент. Но для подключения к реальным сервисам Model Context Protocol остаётся более правильным архитектурным решением. Нам нужно строить коннекторы, а не плодить CLI.

В последнее время повсюду звучит: «MCP умер», «Skills — новый стандарт». Куда ни посмотри — кто-то торжественно хоронит MCP и добавляет SKILL.md в репозиторий. Но я — активный пользователь AI, и мне Skills не подходят. Мир, где каждая интеграция — это отдельный CLI и markdown-инструкция, меня не привлекает.

Объясню, почему универсальная ставка на Skills — это шаг назад, и почему MCP по-прежнему выигрывает по архитектуре.

Что хорошо в MCP

Суть MCP проста: это API-абстракция. LLM не нужно знать, как работает сервис — достаточно знать, что можно сделать. Хочешь взаимодействовать с DEVONthink — вызываешь devonthink.do_x(), а MCP-сервер разбирается с деталями.

Из этого разделения ответственности вытекают практические преимущества:

1. Нет установки для удалённых серверов. Укажи клиенту URL — и всё работает.
2. Бесшовные обновления. Когда MCP-сервер обновляется, все клиенты получают новые инструменты мгновенно. Без переустановок и обновления бинарников.
3. Нормальная аутентификация. Auth через OAuth на уровне протокола. Клиент завершил handshake — и может делать запросы. Без токенов в plain text.
4. Настоящая совместимость. Удалённые MCP работают откуда угодно: Mac, телефон, браузер.
5. Изолированность. MCP выставляют контролируемый интерфейс, а не дают LLM прямой доступ к локальной среде.
6. Умная загрузка инструментов. Современные клиенты (ChatGPT, Claude и другие) загружают инструменты только при необходимости — контекст не засоряется.
7. Автообновление без усилий. Даже локальные MCP, установленные через npx -y или uv, могут обновляться при каждом запуске.

Что не так со Skills

Skills хороши, когда передают чистые знания: формат коммитов, стиль тестов, внутренний жаргон. Проблемы начинаются, когда Skill требует CLI для реальных действий.

Главная проблема: Skills предполагают, что в любой среде можно запустить произвольный CLI. Но ChatGPT не умеет этого. Perplexity — тоже. Стандартный веб-Claude — нет. Если вы не в Codex, Claude Code или Perplexity Computer, CLI-зависимый Skill мертворождённый.

Отсюда — каскад проблем:

1. Деплой. CLI нужно публиковать, управлять версиями, устанавливать через бинарники, NPM, uv и т.д.
2. Управление секретами. Куда класть API-токены? Если повезёт, среда поддерживает .env. Но в эфемерных окружениях секреты могут исчезнуть после перезапуска.
3. Фрагментация экосистемы. Нет единого стандарта. npx skills работает в Codex и Claude Code, но не в Claude Cowork. У кого-то есть маркетплейс Skills, у кого-то — нет. Установка с GitHub — не везде поддерживается. Один Skill может сломаться из-за несовпадения полей в YAML.
4. Раздутый контекст. Часто приходится загружать весь SKILL.md вместо одной сигнатуры. Как если бы человеку пришлось читать всё руководство по машине, чтобы включить car.turn_on().

Если инструкция начинается с «сначала установи CLI» — вы добавили лишний слой и шаги. Зачем, если можно использовать удалённый MCP?

Когда что использовать

MCP должен быть стандартом, когда нужно дать LLM интерфейс к сервису: сайту, приложению, базе. Сервис должен сам диктовать, какой интерфейс он выставляет.

• Google Calendar: CLI gcal — нормально, но Skill, который учит устанавливать его и управлять токенами, — плох. Удалённый OAuth-backed MCP от Google решает это на уровне протокола и работает в любом клиенте.
• Управление Chrome: браузер должен выставлять MCP-эндпоинт, а не полагаться на chrome-cli.
• Отладка в Hopper: встроенный MCP с step() лучше отдельного hopper-cli.
• Xcode: должен поставляться со встроенным MCP и нормальным auth при подключении LLM.
• Notion: правильно запустил mcp.notion.so/mcp — без необходимости ставить notion-cli и управлять auth вручную.

Skills должны быть «чистыми» — только знания и контекст:

• Объяснять уже установленные инструменты. Папка .claude/skills, которая учит LLM использовать curl, git, gh, gcloud — отличный сценарий. «curl MCP» не нужен. Нужно просто научить LLM строить команды.
• Стандартизировать рабочие процессы. Skills хороши для обучения Claude внутреннему жаргону, стилю общения или структуре компании.
• Работа с файлами. Как у Anthropic с PDF Skill: объясняет, как работать с PDF через Python.
• Управление секретами. Skill, который говорит Claude: «используй fnox для этого репозитория, вот как» — разумно. Лучше, чем строить отдельный MCP ради get_secret().

Коннекторы vs инструкции

Может, дело в терминологии? Skills стоило бы назвать LLM_MANUAL.md, а MCP — Connectors.

У обоих есть место. В своих проектах я делаю так:

• mcp-server-devonthink — локальный MCP-сервер для управления DEVONthink. Без CLI-обёрток, чистый инструментальный интерфейс.
• microfn — удалённый MCP на mcp.microfn.dev, доступен любому совместимому клиенту.
• Kikuyo — то же самое, mcp.kikuyo.dev.
• MCP Nest — туннелирует локальные MCP через облако, делая их доступными по mcp.mcpnest.dev/mcp. Сделано для удалённого доступа без открытия своей машины.

Для microfn и Kikuyo я публиковал Skills — но они описывали CLI, а не MCP. Однако написание этой статьи помогло понять: Skill, объясняющий, как использовать MCP-сервер, имеет смысл. Не вместо MCP, а как слой знаний поверх коннектора.

Это — паттерн, который я всё чаще использую. При работе с MCP-сервером возникают неочевидности: дата в формате YYYY-MM-DD, а не YYYYMMDD; поиск обрезает результаты без параметра; инструмент называется неожиданно. Вместо того чтобы проходить это каждый раз, я прошу Claude упаковать нюансы в Skill. LLM уже знает контекст — и пишет точную шпаргалку.

Получается: Skill как шпаргалка к MCP, а не его замена. MCP отвечает за соединение и выполнение. Skill — за то, чтобы LLM не наступал на те же грабли. Их комбинация делает работу плавной.

Я продолжу поддерживать репозиторий dotfiles с Skills для частых процессов и класть .claude/skills в репозитории, чтобы направлять поведение AI.

Надеюсь, индустрия не забросит Model Context Protocol. Мечта о бесшовной AI-интеграции строится на стандартизированных интерфейсах — не на россыпи самодельных CLI. Всё ещё жду официальных MCP от Skyscanner, Booking.com, Trip.com и Agoda.

Это моё личное мнение.

AI-сообщество активно продвигает Skills как новый стандарт для расширения возможностей LLM. Я с этим не согласен. Skills отлично работают как чистая передача знаний — когда нужно объяснить модели, как использовать уже установленный инструмент. Но для подключения к реальным сервисам Model Context Protocol остаётся более правильным архитектурным решением. Нам нужно строить коннекторы, а не плодить CLI.

Не знаю, влияние ли это постоянного нахождения в соц.сетях, но в последнее время мне активно внушают, что «MCP умер» и «Skills — новый стандарт». Куда ни посмотри — кто-то торжественно хоронит MCP и кидаетSKILL.mdв свой репозиторий.

Я — очень активный пользователь AI. Для кода использую Claude Code, Codex и Gemini. Для всего остального — ChatGPT, Claude и Perplexity почти каждый день: заметки в Notion, базы в DEVONthink, почта.

Так вот: Skills мне не нравятся. Очень надеюсь, что MCP никуда не денется. Мир, где каждая интеграция — это отдельный CLI и markdown-инструкция к нему, меня совсем не привлекает.

Объясню, почему универсальная ставка на Skills — это шаг назад, и почему MCP по-прежнему берёт архитектурой.

Мы перевели эту статью, потому что тема живая — дискуссия про MCP vs Skills сейчас слышна много откуда. Сами бы мы не стали делать такое жёсткое противопоставление: у каждого подхода есть своя ниша.Для Java/Kotlin/Spring разработчиков у нас уже есть и готовыеMCP, иSkills— если хотите усилить своего агента, всё в ваших руках. А скоро покажемSpring Agent Toolkit, который объединяет оба подхода.

Что хорошо в MCP

Суть MCP простая: это API-абстракция. LLM не нужно знатькакработает сервис — достаточно знатьчтоможно сделать. Хочешь взаимодействовать с DEVONthink — вызываешьdevonthink.do_x(), а MCP-сервер разбирается с деталями.

Из этого разделения ответственности вытекает несколько практических преимуществ.

1. Нет установки для удалённых серверов.Просто указываешь клиенту URL — и всё работает.
2. Бесшовные обновления.Когда удалённый MCP-сервер обновляется с новыми инструментами, все клиенты получают их мгновенно. Никаких переустановок пакетов и обновлений бинарников.
3. Нормальная аутентификация.Auth решается через OAuth на уровне протокола. Клиент завершил handshake — и может делать запросы. Никаких токенов в plain text.
4. Настоящая совместимость.Удалённые MCP работают откуда угодно: Mac, телефон, браузер.
5. Изолированность.Удалённые MCP естественно изолированы: они выставляют контролируемый интерфейс, а не дают LLM прямой доступ к исполнению в локальной среде.
6. Умная загрузка инструментов.Современные клиенты (ChatGPT, Claude и другие) ищут и загружают инструменты только тогда, когда они реально нужны, — контекстное окно не засоряется.
7. Автообновление без усилий.Даже для локальных серверов MCP, установленный черезnpx -yилиuv, может обновляться при каждом запуске автоматически.

Что не так со Skills

Не все Skills одинаково плохи. Если Skill передаёт чистые знания — учит модель форматировать коммиты, писать тесты в определённом стиле или работать с внутренним жаргоном — это работает хорошо. Проблемы начинаются, когда Skill требует CLI для реального действия.

Моя главная претензия: Skills исходят из допущения, что в любой среде можно запустить произвольный CLI. ChatGPT не умеет запускать CLI. Perplexity тоже. Стандартный веб-Claude — тоже. Если только вы не работаете в полноценной вычислительной среде вроде Perplexity Computer, Claude Cowork, Claude Code или Codex, любой Skill, завязанный на CLI, мертворождённый.

Отсюда каскад проблем.

1. Деплой.CLI нужно публиковать, управлять версиями и устанавливать через бинарники, NPM, uv и так далее.
2. Управление секретами.Куда класть API-токены? Если повезёт, среда поддерживает.env. Некоторые эфемерные окружения очищаются сами — сегодня CLI работает, завтра не помнит секретов.
3. Фрагментация экосистемы.Менеджмент Skills сейчас — дикий запад. При обновлении нужно переустанавливать вручную.npx skillsработает только в Codex и Claude Code, но не в Claude Cowork и обычном Claude. У одних инструментов есть маркетплейс Skills, у других нет. Одни умеют устанавливать с GitHub, другие нет. Я пытался поставить один OpenClaw Skill в Claude — вылетело с ошибкой YAML-парсинга из-за несовпадающих полей метаданных.
4. Раздутый контекст.Использование Skill часто требует загрузить весьSKILL.mdв контекст — вместо того чтобы просто показать нужную сигнатуру инструмента. Как если бы человека заставляли читать всё руководство по эксплуатации машины, когда ему нужен толькоcar.turn_on().

Если инструкции в Skill начинаются с «сначала установи этот CLI» — ты только что добавил лишний слой абстракции и лишние шаги. Зачем, если можно просто использовать удалённый MCP?

Когда что использовать

MCP должен быть стандартом, когда нужно дать LLM интерфейс для подключения к чему-либо: сайту, сервису, приложению. Сам сервис должен диктовать, какой интерфейс он выставляет.

1. Возьмём Google Calendar. CLIgcal— нормально. Проблема в Skill, который говорит LLM: «установи его, управляй токенами, вызывай через shell». OAuth-backed удалённый MCP от Google решает это на уровне протокола и работает из любого клиента без настройки.
2. Управление Chrome — браузер должен выставлять MCP-эндпоинт для stateful-управления, а не полагаться наchrome-cli.
3. Отладка в Hopper — встроенный MCP, который позволяет LLM вызыватьstep(), бесконечно лучше отдельногоhopper-cli.
4. Xcode должен поставляться со встроенным MCP с нормальным auth при подключении LLM к проекту.
5. Notion правильно сделал, запустивmcp.notion.so/mcp— вместо того чтобы заставлять ставитьnotion-cliи управлять состоянием auth вручную.

Skills должны быть «чистыми» — только знания и контекст.

1. Объяснять уже установленные инструменты. Отличный сценарий — папка.claude/skills, которая учит LLM использовать инструменты, которые у тебя уже стоят. Skill проcurl,git,ghилиgcloud— полностью оправдан. «curl MCP» не нужен. Нужно просто научить LLM строить хорошиеcurl-команды. При этом для управления issues в GitHub удалённый MCP всё равно разумнее, чем Skill сghCLI.
2. Стандартизировать рабочие процессы. Skills отлично подходят для обучения Claude внутреннему жаргону компании, стилю коммуникации или организационной структуре.
3. Объяснять работу с определёнными типами файлов. Именно так делает Anthropic со своимPDF Skill: объясняет, как работать с PDF через Python.
4. Управление секретами. Skill, который говорит Claude «используйfnoxдля этого репозитория, вот как это работает» — это разумно. Каждый раз, когда нужны секреты, Claude подтягивает Skill. Это куда лучше, чем строить отдельный MCP только радиget_secret().

Коннекторы vs инструкции

Мысль из душа: может, дело в терминологии? Skills стоило бы назватьLLM_MANUAL.md, а MCP — Connectors.

У обоих есть своё место.

Для сервисов, которые я сам разрабатываю, я уже делаю именно так:

• mcp-server-devonthink— локальный MCP-сервер, который даёт любому LLM прямое управление DEVONthink. Без CLI-обёрток, чистый инструментальный интерфейс.
• microfn— выставляет удалённый MCP по адресуmcp.microfn.dev, любой MCP-совместимый клиент может использовать его из коробки.
• Kikuyo— то же самое, удалённый MCP наmcp.kikuyo.dev.
• MCP Nest— туннелирует локальные MCP-серверы через облако, делая их доступными удалённо по адресуmcp.mcpnest.dev/mcp. Сделал это, потому что постоянно хотел удалённого доступа к локальным MCP без прямого открытия своей машины.

Для microfn и Kikuyo я тоже публиковал Skills — но они описывают CLI, а не MCP. Впрочем, написание этой статьи заставило меня осознать: Skill, объясняющий, как использовать MCP-сервер, на самом деле имеет смысл. Не вместо MCP, а чтобы дать LLM контекст перед тем, как он начнёт вызывать инструменты. Что делает сервис, как связаны инструменты, когда использовать какой из них. Слой знаний поверх слоя коннектора. Вот комбинация, которую я хотел бы видеть.

И это паттерн, который я всё чаще использую на практике. Когда работаешь с MCP-сервером, неизбежно натыкаешься на неочевидные вещи: дата должна быть в форматеYYYY-MM-DD, а неYYYYMMDD; функция поиска обрезает результаты, если не поднять один параметр; инструмент называется не так, как ожидаешь. Вместо того чтобы заново открывать это каждую сессию, я прошу Claude упаковать всё найденное в Skill. LLM уже держит весь контекст разговора, поэтому пишет Skill со всеми нюансами, частыми паттернами и исправленными допущениями.

Получается Skill как шпаргалка к MCP, а не его замена. MCP по-прежнему отвечает за соединение и выполнение инструментов. Skill просто гарантирует, что LLM не потратит токены на те же грабли, которые я уже прошёл. Именно их комбинация делает работу плавной.

При этом я продолжу поддерживать репозиторий dotfiles с Skills для процессов, которые использую часто, и буду класть.claude/skillsв свои репозитории, чтобы направлять поведение AI.

Я просто надеюсь, что индустрия не забросит Model Context Protocol. Мечта о бесшовной AI-интеграции строится на стандартизированных интерфейсах — не на россыпи самодельных CLI. Всё ещё жду официальных MCP от Skyscanner, Booking.com, Trip.com и Agoda.

Это моё личное мнение.

Актуальные новости о продукте проще всего получать, подписавшись на наштелеграм канал. Получить актуальную версиюAmplicodeможно нанашем сайте.