MCP. CLI. Skills. Как я провалил курс по MCP и в итоге нашёл CLI и Skills

🎭 Вступление

Сегодня расскажу, что такое MCP, CLI и Skills для работы с AI-агентами. И честно поделюсь опытом и личным фиаско — куда же без него.

Когда я впервые услышал про MCP, я вдохновился. По-настоящему.

Потому что идея выглядела слишком красивой — универсальный протокол, которым можно связать всё со всем.

Не «ещё одна удобная интеграция», а общий язык, на котором AI-агенты наконец смогут нормально друг с другом разговаривать.

Но MCP появился не в вакууме. До него мы использовали два подхода.

Первый — серверный: поднимаешь API, описываешь его через OpenAPI, модель привязывается через tool calling (вызов функций), маппинг (mapping — сопоставление) функций, обвязку.

🫶 Для новичков. API (Application Programming Interface) — набор функций, которые сервис публикует «вовне», контракт, обязательный к соблюдению при корректном доступе. OpenAPI — принятый формат описания API. Маппинг — привязка имени к реализации, например внешнего имени к внутренней функции. Обвязка — весь технический клей вокруг: проверки, обработка ошибок, логирование — скучно, но без этого ничего не работает.

Второй — ещё более ранний: RAG. Модель сама ничего не «делает», она только думает над тем, что ей дали, и максимум подтягивает контекст из базы знаний.

🫶 Для новичков. RAG (Retrieval-Augmented Generation) — это когда AI перед ответом сначала лезет в базу знаний, находит релевантные куски текста и думает уже с ними. Как если бы вы перед ответом быстро загуглили и прочитали пару статей.

Потом появился tool calling (вызов инструментов) — и стало веселее. Модель получила не только контекст, но и возможность действовать. Это был большой сдвиг.

🫶 Для новичков. У AI-агента, грубо говоря, есть два слоя контекста, которые работают одновременно.

Основной контекст — это история переписки, действий и вообще текущей деятельности агента, которая помещается в его «внимание». Как общий стол, на котором лежат все документы, заметки и следы работы.

Оперативный контекст — это то, что происходит «за кулисами». Агент взял задачу, вызвал инструмент, получил результат, подумал, вызвал ещё один. Вы можете этого вообще не видеть, но именно там часто идёт основная работа.

Например, если у модели окно около миллиона токенов, и половину уже занимает история переписки, то остальное уходит на промежуточные шаги, вызовы инструментов и рассуждения. После завершения задачи этот рабочий слой обычно освобождается, поэтому контекст расходуется экономнее.

Но каждую утилиту нужно было аккуратно привязывать (маппить), описывать интерфейсы, объяснять модели, что она умеет, и не утонуть в обвязке.

Поэтому, когда появился MCP, я обрадовался, как дурак.

В моей голове картинка была примерно такая:

🫶 Для новичков. MCP-сервер — это сервис, который поддерживает протокол контекста модели (MCP) от Anthropic. Сервер вывешивает табличку: «Я умею делать вот такие штуки». А AI-клиент (например, Cursor или Claude) читает её и понимает, какие инструменты ему доступны.

Мне казалось: «Ура. Агентная совместимость наступила».

Типа: «хей-хоп-ла-ла-лей, вот вам URL, вот вам протокол — идите знакомьтесь и работайте».

Естественный язык для машинных способностей.

Ага. Ну да. Конечно 😏

В моей голове это выглядело примерно так:

поднимается MCP-сервер;
искусственный интеллект спрашивает: «а что ты умеешь?»;
второй отвечает: «вот это, вот это и вот это»;
первый говорит: «прекрасно, а я умею вот это»;
и дальше они сами разбираются.

И ведь это не фантазия.

К 2026 году вокруг MCP уже выросла большая экосистема: Anthropic пишет о более чем 10 000 активных публичных MCP-серверах, а сам протокол поддержали и развивают OpenAI, Anthropic, Microsoft, Google, AWS, Cloudflare и другие крупные игроки. В декабре 2025 года Anthropic передала MCP в Agentic AI Foundation под эгидой Linux Foundation — почти как получить благословение Папы Римского, только для кода. Кроме того, реальные MCP-коннекторы уже используются для GitHub, Notion, Figma и других рабочих систем.

Я настолько в это поверил, что начал рассказывать об этом другим.

Сделал обучающий курс — интенсив по MCP.

И реально думал, что показываю людям кусок будущего.

Но после первого воркшопа не все дожили до второго. Некоторые ушли.

И в этот момент я поймал себя на очень неприятной мысли.

Буквально спросил себя:

«Подожди. Кажется, всё это немного сложнее, чем я думал…
А не завербовался ли я случайно в техно-секту эм-си-пи-шников?»

Ответ оказался неприятным.

Не в том смысле, что MCP — полная хрень.

Нет. Он умный, сильный, во многих местах реально полезный и, по сути, уже стал стандартом де-факто для подключения AI-агентов к данным и инструментам.

Проблема была в другом: я хотел от MCP слишком многого.

Чего именно — об этом в следующей главе.

🧠 Глава 1. MCP

Тот человек, который хоть раз по-настоящему задолбался пришивать одну систему к другой — поймёт, о чём я говорю.

Мне хотелось, чтобы MCP почти автоматически снял боль интеграции.


Чтобы после всей долбежки в рудниках с tools, OpenAPI и функциями я поехал на ... курорт.

А на практике я довольно быстро увидел неприятную вещь: если даже мне, опытному разработчику, которому всё это в целом по кайфу, временами хотелось просто сесть и посмотреть в стену — то для обычных людей, особенно не программистов, это еще труднее.

Я слишком рано поверил, что живу в будущем :)

До MCP выбор был из следущих средств:

— руками пришиваешь инструменты (tools) к модели;
— действуешь через API (программный интерфейс) и OpenAPI (стандарт описания API);
— ограничиваешься RAG (генерация с доступом к данным);
— строишь свою собственную интеграцию под каждый сценарий (иногда кривую, но работающую).

Всё это работало, но примерно так:

«сейчас мы изолентой, функциями и надеждой скрепим интеллект с внешним миром»

MCP казался следующим логичным шагом.

Не: «вот тебе ещё один инструмент, держись»

А: «вот тебе карта, документация — действуй»

Но вдруг стало видно: между мечтой «агенты сами всё поймут друг про друга» и реальностью лежит большое расстояние.

И проблемы.

Проблема 1. Какой MCP - сервер брать для моей задачи?

Вариант 1. “Сделай свой MCP-сервер. Ты же вайб-кодер, ага”

Это тот момент, где тебе как бы подмигивают:

“ну а что такого, напиши свой MCP-сервер под свою задачу”

Идея звучит даже логично. Если у тебя особый сценарий (workflow — рабочий процесс), особые данные, особая логика — ну да, может, и правда проще сделать своё.

Только есть маленькая деталь:

для обычного человека, тем более не программиста, написать свой MCP-сервер — это ни хрена не “просто”

Даже если ты весь такой на вайб-кодинге (vibe coding — кодинг по наитию). Даже если у тебя рядом умный чат-бот или даже Claude Code. Даже если ты уже в хорошем настроении и веришь в технологическое завтра.

Это только кажется, что быстро.

У меня, например, это получилось не за час, а скорее за полтора-два дня — и это при том, что мне всё это в целом нравится, я не боюсь кода и не падаю в обморок от слова “схема”.

Потому что надо:

понять формат; собрать сервер; описать инструменты; проверить, как клиент (client — клиент) их видит; понять, почему он видит их не так; поправить; потестить; потом ещё понять, почему агент вызывает не тот инструмент; потом ещё разобраться, где косяк — в описании, в логике или в твоих ожиданиях от жизни.

И вот тут первая честная правда:

MCP-сервер — это не “сейчас я наколдую 20 строк”

Это уже маленькая инженерная штука со своей жизнью, обвязкой и характером.

🫶 Для новичков. MCP-сервер — это не “одна функция”. Это мини-программа (service — сервис), которая должна жить, отвечать клиенту, правильно описывать свои возможности и не рассыпаться, когда к ней реально подключаются.

И тут я впервые очень ясно понял:

если даже мне это не удалось сделать по-быстрому, то продавать это как “лёгкий вход для обычных людей” — ну такое.

Вариант 2. “Просто скачай готовый сервер с GitHub” — ага, конечно

Это второй “очевидный” совет.

Типа не хочешь писать свой? Не вопрос.

“Возьми готовый MCP-сервер с GitHub (платформа для хранения кода), подключи и пользуйся”

И в этот момент где-то тихо смеётся дьявол.

Потому что для разработчика это ещё может звучать как нормальный путь. А для обычного человека это внезапно превращается в набор странных ритуалов:

- найти нормальный репозиторий (repository), а не дохлую поделку;
- понять, живой он вообще или его последний раз трогали во времена динозавров;
- скачать (clone — клонировать);
- поставить Node.js (среда выполнения JavaScript), если его нет; понять, какую версию Node вообще надо;
- установить зависимости (dependencies);
- не умереть от ошибок npm (менеджер пакетов);
- потом ещё как-то объяснить Claude Code (инструмент разработки от Anthropic), что вот это добро теперь существует и его надо использовать.

И это я ещё даже не дошел до самого адового места.

Весёлое место в том, что такой суп нормально поддерживается не всеми подряд клиентами, а в первую очередь оригинальным Claude Code и его экосистемой (ecosystem — экосистема).

А дальше начинается следующий прикол:

многие люди используют Claude Code не строго “как задумал Anthropic”, а с кастомными моделями (custom models), через прокси (proxy), маршруты (routing), OpenRouter (сервис маршрутизации моделей) и подобные и всё такое весёлое.

И вот там магия “просто подключил MCP-сервер” внезапно перестаёт быть магией.

Потому что в части таких конфигураций это работало уже не так гладко, как обещала реклама. А иногда и не работало вовсе.

То есть на словах тебе говорят:

“Зоопарк готов. Пора выгуливать слонов”

А по факту:

“скачай с GitHub, поставь Node, настрой окружение (environment — окружение), разберись с Claude Code — а потом ещё молись, что твоя конкретная связка вообще взлетит”

И тут уже хочется спросить:

простите, а где в вашем курорте ... солярий?

То есть, на каком именно этапе интеграции начинается обещанная лёгкость?

🫶 Для новичков. GitHub-репозиторий — это просто папка с кодом проекта в интернете. Но “скачать проект” — не значит “он сразу работает”. Очень часто нужно ещё установить зависимости, правильную среду, версии библиотек и понять инструкцию, написанную человеком, который был уверен, что “ну это же очевидно”.

Я понял, что солярий на курорт еще не завезли, как и хаммам.

Вариант 3. “Подключись к готовому сервису” — OAuth, токены и лёгкая ненависть

Ладно, думаешь ты. Не хочу писать сам.

Не хочу качать с GitHub чужой зоопарк. Хочу открыть готовый сервис, подключиться и поехать. Например, что-то вроде mcp.pipedream.com и похожих историй.

И вот тут вроде бы должен быть happy end. Сервис же. Готовый. Всё уже настроено. Красота. Тысяча интеграций в кармане (как обещают).

Но не тут-то было.

Потому что как только ты лезешь в готовые HTTP-сервисы (веб-сервисы), тебя часто встречает старый знакомый — аутентификация (authentication ).

Если это просто токен (token — ключ доступа) — ещё ладно. Токен я уважаю. Токен — это почти человечно:

взял ключ, вставил в JSON, поехали.

Но многие такие сервисы любят не токен, а OAuth (OAuth — протокол авторизации).

Мама.

И вот тут вся история “для обычных людей” начинает звучать особенно издевательски.

Потому что OAuth на практике — это часто:

- зарегистрируй приложение (app registration — регистрация приложения);
- получи client id;
- получи secret;
- настрой redirect URI;
- пойми, куда тебя перекидывает;
- пойми, почему тебя не пускает;
- пойми, где именно отвалилась авторизация (auth flow — поток авторизации);
- потом ещё обновляй токены (token refresh — обновление токена) или следи, как это делает платформа.

И всё это ради того, чтобы…

просто подключить один AI-инструмент к другому.

Я не говорю, что OAuth плохой. Он для своих задач нормальный.

Но в контексте обучения и быстрого старта это очень часто выглядит как:

“добро пожаловать в будущее, сначала заполните пять бумажек и подтвердите личность через три круга ада”

А сверху тебя ещё могут нежно приобнять бизнес-моделью (business model — бизнес-модель).

Потому что многие такие сервисы прекрасны в демо-режиме (demo — демонстрация):

вот тебе красиво; вот тебе пара тестовых вызовов (test calls — тестовые запросы); вот тебе ощущение, что сейчас всё полетит;

А потом ты хочешь использовать это не понарошку (production — боевое использование), и тебе говорят:

“ну отлично, а теперь с тебя денежки за интеграцию (integration — интеграция)”

И я их даже не осуждаю — люди строят бизнес.

Вопрос в другом:

где именно здесь лёгкий путь для обычного пользователя?

Потому что на выходе у нас не “подключись за 5 минут”, а:

либо пиши свой сервер; либо качай чужой код и молись; либо проходи через OAuth, токены, настройки и платные лимиты.

🫶 Для новичков. OAuth — это способ, при котором доступ даётся не через один ключ, а через процедуру согласования между сервисами. Это безопасно, но для новичка ощущается как “я просто хотел открыть дверь, а мне выдали анкету, бейдж и инструктаж на 40 минут”.

А проблемы только начинались...

Проблема 2. Ожидание, что агент сам разберётся в чужих возможностях

Еще одна романтическая ошибка.

Мне правда казалось, что если один агент или AI-клиент видит MCP-сервер, а сервер честно и красиво описывает свои возможности, дальше всё будет почти по-взрослому.

Ну то есть примерно так:

— Я умею искать по базе, читать документы, создавать задачи и работать с календарём.
— Отлично. Тогда я сейчас вызову тебя вот так, потом вот так, и соберу из этого workflow.

Красиво же?

Как будто системы реально знакомятся друг с другом.
Как будто у них вежливый технический нетворкинг, а не драка двух слепых сантехников в сыром подвале.

Но довольно быстро выяснилось неприятное:

описание возможностей — это ещё не понимание возможностей

Агент видит список инструментов (от MCP - сервера) — да

Но дальше начинается цирк ..

Допустим, сервер показывает такой набор:

• search_documents
• search_notes
• find_records
• lookup_context
• query_archive

И вот приходит пользователь с простым вопросом:

“Найди мне свежий договор с Ивановым и покажи последние правки”

Человек ещё как-то может интуитивно догадаться:

• договор — наверное, документы;
• свежий — не архив;
• последние правки — возможно, отдельная версия или заметки.

А агент очень часто начинает плавать.

Потому что для него это не “очевидно”, а что-то вроде:

“Так… договор — это document? Но правки могли уйти в notes.
А lookup_context звучит тоже умно.
А find_records вообще как будто универсально.
А query_archive вдруг тоже может вернуть старую версию…”

И всё.
Начинается интеллектуальная рулетка.

Он не тупой. Правда.
Он просто не знает, что именно имел в виду разработчик, когда делал эти инструменты.

Сегодня один их рабочих подходов, чтобы AI - агент быстро и точно разобрался, что к чему используют навыки (skills), но я долгое время пытался обойтись без него.. О Skills я расскажу в главе 3.

То есть сервер как бы говорит:

“я умею вот это, вот это и вот это”

Но он не говорит достаточно ясно:

“брат, если нужен свежий рабочий документ — бери search_documents;
если нужен архив — лезь в query_archive;
если нужен контекст обсуждения — это уже search_notes;
а find_records не трогай без фильтров, а то потом сам же и заплачешь”

И вот тут моя красивая картина про “агент сам разберётся” начала тихо осыпаться.

Потому что выяснилось:
MCP не отменяет проблему хорошего дизайна инструментов.

Он не делает мутные интерфейсы автоматически понятными.
Он не превращает пересекающиеся по смыслу функции в ясную иерархию.

Он просто даёт новый способ всё это описать.

А если ты описал плохо — агент не становится волшебно умнее только потому, что это теперь “по протоколу”.

🫶 Для новичков. Тут проблема не в том, что AI “не умеет читать”. Проблема в другом: список возможностей — это не инструкция по правильному выбору. Это как дать человеку меню на 25 страниц и ждать, что он безошибочно угадает, какое блюдо тут реально стоит брать, а какое просто красиво называется.

И это был мой первый холодный душ.

Я вдруг увидел, что за красивой идеей “агенты будут понимать друг друга” всё ещё прячется старая добрая инженерная реальность:

• назови инструменты плохо — и будет боль;
• сделай описания слишком общими — и будет боль;
• наплодишь функций “на вырост” — и будет боль;
• надеешься, что модель сама догадается — будет боль с элементами мистики.

Проблема 3. Перегруз контекста описаниями инструментов

Вот здесь становилось по-настоящему весело. До меня дошло:

каждый новый MCP-сервер — это не только “о, новые возможности”,
но ещё и новый слой шума в контексте

А контекст у модели, как бы его ни расширяли, не резиновый. И, что трогательно, не бесплатный.

Каждый инструмент надо описать:

• как он называется;
• что принимает;
• что возвращает;
• какие там параметры;
• какие типы;
• какие ограничения;
• иногда ещё примеры;
• иногда ещё вложенные схемы;
• иногда ещё особые условия вызова.

Если инструмент один-два — ладно.
Можно жить.

Но как только у тебя нормальный сервер, не игрушечный, начинается веселье.

Представь, что ты подключил условный богатый сервер с десятками возможностей. Или GitHub-подобную историю, где инструментов уже целое стадо.

И внешне это выглядит как праздник:

“Вау, сколько всего умеет система!”

А внутри это часто выглядит так:

“вау, сколько всего агенту надо держать в голове, прежде чем сделать один несчастный шаг”

Вот, например, простой сценарий.

Пользователь говорит:

“Покажи мне последние issue по проекту, где упоминается auth”

В мире мечты агент такой:

“ага, берём нужный инструмент, делаем запрос, приносим ответ”

В мире перегруженного контекста агент сначала должен продраться через кучу похожего:

• list_issues
• search_issues
• query_repo
• search_code
• find_mentions
• lookup_project_context
• get_recent_activity

И на это накладываются ещё описания параметров, вложенные поля, фильтры, опции сортировки, типы ответа.

Получается , что каждый MCP-сервер:

• радостно тащит в промпт километровые JSON-схемы
• описывает каждый чих инструментов
• и всё это летит в контекстное окно LLM

То есть у AI - агента в голове уже не “задача пользователя”, а долгая, тяжелая и занудная вечеринка интерфейсов.

И в какой-то момент ты ловишь странное чувство:

агент тратит очень много умственной энергии на проматывание лишнего

И самое худшее в этом... когнитивная грязь.

Когда в описаниях много всего, агент:

• дольше выбирает;
• чаще цепляется за неправильные совпадения по словам;
• может вызвать “почти тот” инструмент, но не тот :)
• может начать слишком умничать, ходить петлями, вместо того, чтобы просто сделать шаг;
• может утонуть в вариантах, где человек бы просто ткнул пальцем и пошёл дальше.
• просто тупо думает хуже

И вот тут я впервые по-настоящему подумал:

“слушай, а мы точно на курорте или все еще в рудниках?"

🫶 Для новичков. Контекст — это всё, что модель держит “в голове” прямо сейчас. Если ты запихнул туда слишком много описаний инструментов, это примерно как заставить человека решать задачу, пока у него на столе лежат 60 инструкций, 14 меню, 8 паспортов и тостер. Он, возможно, справится. Но красиво — уже не обещаю.

Проблема 4. Сложность серверной и схемной обвязки

Вот здесь романтика окончательно уходит курить.

Потому что в рекламе MCP очень легко звучит как:

> “единый протокол, единый способ, пожелай-и-твори”

Знаю, сам писал :)

А в реальной жизни приходишь в старый добрый интеграционный ад.

Просто теперь он оформлен чуть культурнее.

Надо:

- поднять MCP - сервер;
- описать схемы;
- продумать доступы, настроить аутентификацию;
- определить, что именно возвращает каждый инструмент;
- решить, как обрабатывать ошибки;
- тестировать;
- логировать;
- следить, чтобы одна правка не разнесла половину цепочки.

То есть в сухом остатке ты всё равно строишь интеграционный слой.

Не исчез он. Не растворился.

Он просто чуть более цивильным.

И это не плохо. Может быть чуть лучше, чем просто API.

Но я, если честно, где-то внутри надеялся на почти неприличное чудо.

Что будет примерно так:

“я просто сказал, что хочу, а дальше ветер экосистемы мягко подхватил меня, как героя эпохи”

Например, хочу я сделать красивый MCP-сервер для работы с внутренними документами компании.

На словах идея простая:

- читать документы;
- искать по ним;
- доставать версии;
- смотреть метаданные.

Красота.

Но начинаем думать:

- как назвать инструменты, чтобы они не пересекались по смыслу;
- как не сделать один инструмент слишком общим, а другой — слишком узким;
- как оформить схему и параметры;
- как не раздуть ответ на полконтекста;
- как обработать ситуацию, когда документ не найден;
- как отдать ошибку так, чтобы агент не сошёл с ума;
- как не протащить в ответ лишние данные;
- как потом это всё отлаживать.

И вот в какой-то момент ты сидишь и понимаешь:

да, протокол хороший но думать все равно приходится

Это как если бы тебе выдали дорогой набор хирургических инструментов и сказали:

> “ну теперь операция будет удобнее”

Да. Удобнее.

Но ты всё ещё, мать его, делаешь операцию.

🫶 Для новичков. Схема — это описание того, какие данные инструмент принимает и возвращает. Как бланк: какие поля есть, что обязательно, что необязательно.

Особенно неприятно это ощущается, когда ты хочешь быстро показать людям:

“смотри, какая красота”

А вместо этого начинаешь объяснять:

- почему тут такой параметр;
- почему без этого JSON ничего не вызывается;
- почему ошибка вообще не в модели, а в схеме;
- почему “оно же должно было само понять” — часто не работает.

И вот тогда я понял очень простую, но неприятную вещь:

MCP не отменяет интеграционную работу.

Он делает её более культурной. Но не лёгкой. И уж точно не бесплатной по усилиям.

И под конец, осталась самая сложная ...

Проблема 5. Как обучить MCP тех, кто не программирует?

Мда, в анонсе курса я написал "MCP - это легко". Я никогда так не ошибался.

Мне пришло в голову, что передать весь объем MCP - это как прочесть еще один курс программированию в универе.

И еще одна странная мысль: неужели никто не придумает, как уехать из этого болота рутины, ведь у нас столько интеллекта?

Потому что одно дело — когда ты сам ночью сидишь, ковыряешься, психуешь, но тебе, в каком-то извращённом смысле, даже нравится. Ты инженерный мазохист. Тебе можно.

Совсем другое — когда ты пытаешься передать это другим людям.

Не разработчикам, которые уже по запаху отличают “сломалась схема” от “не доехал контекст”.

А обычным умным людям:

- предпринимателям;
- авторам;
- аналитикам;
- всем тем, кто хочет понять, куда движется AI, но не собирается провести субботу, выбирая между npm, OAuth и описанием параметров.

На словах MCP звучит вкусно:

> “агенты смогут подключаться к инструментам через единый протокол”

Очень секси. Очень в тему 2020-х.

А потом человек задаёт самый честный вопрос на земле:

“Класс. А что мне для этого реально надо сделать?”

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

- сервер;
- схемы;
- описания инструментов;
- клиент;
- ограничения контекста;
- иногда доступы;
- иногда локальный запуск;
- иногда настройка окружения;
- иногда отладка;
- иногда ещё и разбор, почему оно в этой конкретной связке не работает, хотя “по идее должно”.

И ты прямо видишь, как у cтудента внутри медленно гаснет огонёк.

Некоторые уходят курить, а некоторые уезжают в настоящий отпуск, потому что уже поднадоел AI - хайп.

И я понял:

> MCP это не чат-боты и на практике сложнее, чем JSON

Хотелось дать людям что-то, что они смогут взять и реально понести дальше.

Но не вышло и я ушел курить:

“А… ну понятно. Значит, опять не оно.”

Но похоронить мечту не вышло. На реддите писали: “MCP провалился, да здравствует CLI”

И я заново открыл два других подхода для интеграции.

Один назывался CLI. Второй — Skills.

Я вернул себе ощущение, что из всего этого AI - добра можно собрать что-то прикольное.

И в чем прикол: и СLI и Skills я интуитивно сам давно открыл и начал применять, но почитав литературу, я понял, что они намного круче, чем я о них думал и возможностей у них больше.

Об каждом из этих подходов я расскажу в отдельной главе с примерами.

ПРОДОЛЖЕНИЕ СЛЕДУЕТ.

Я работал всю ночь, не дописал статью, сорри :)