Почему я всё ещё выбираю MCP, а не Skills

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 по-прежнему берёт архитектурой.

Claude получает свежие отзывы пользователей из Kikuyo через Kikuyo MCP — без CLI.

Мы перевели эту статью, потому что тема живая — дискуссия про 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?

Codex загружает Skill с чистыми знаниями, чтобы разобраться, как работают Phoenix colocated hooks. Без CLI, без MCP — только контекст.

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

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

1. Возьмём Google Calendar. CLI gcal — нормально. Проблема в 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 с gh CLI.

2. Стандартизировать рабочие процессы. Skills отлично подходят для обучения Claude внутреннему жаргону компании, стилю коммуникации или организационной структуре.

3. Объяснять работу с определёнными типами файлов. Именно так делает Anthropic со своим PDF Skill: объясняет, как работать с PDF через Python.

4. Управление секретами. Skill, который говорит Claude «используй fnox для этого репозитория, вот как это работает» — это разумно. Каждый раз, когда нужны секреты, Claude подтягивает Skill. Это куда лучше, чем строить отдельный MCP только ради get_secret().

Skills прямо в репозитории. LLM подхватывает их автоматически при работе с проектом.

Коннекторы 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 со всеми нюансами, частыми паттернами и исправленными допущениями.

Наткнувшись на подводные камни с бэклинками и форматом дат в NotePlan MCP, я попросил Claude упаковать всё это в Skill. Теперь каждая новая сессия начинается с этими знаниями.

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

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

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

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

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