При традиционной схеме MCP-клиент может передавать LLM описания всех подключенных инструментов. У каждого метода есть имя, назначение и схема параметров, и весь этот справочник уходит в промпт раньше, чем модель дочитает до сути задачи. Пока методов десять, накладные расходы незаметны. Когда их сотни, справочник становится главным содержимым запроса.
Skills + Code Mode MCP решают эту проблему двумя элементами. Краткий Skill описывает маршрут: какие MCP-серверы и методы нужны и в каком порядке. Code Mode MCP оставляет агенту два инструмента: search() ищет методы и отдаёт их сигнатуры по запросу, execute() выполняет JavaScript-код с вызовами этих методов и может объединить несколько операций в один заход без обращения к LLM между ними.
Схема выросла из конкретной боли. Автор разбора настраивал личного ИИ-агента Nanabot и параллельно писал MCP-сервер для управления продуктами компании. Каталог методов рос, описания съедали окно, а после их сокрытия за Code Mode агент перестал замечать целые группы операций. Skills появились как ответ на вторую проблему.
В чём проблема: почему MCP-инструменты съедают контекст LLM
Описание инструмента занимает место в контексте на каждом шаге диалога, а не один раз при подключении. Модель видит его при каждом обращении и тратит на него и токены, и внимание. У Cloudflare более 2500 API-методов, и, по оценке компании, полное представление этих методов в виде MCP-инструментов потребовало бы около 1,17 миллиона токенов (разбор кейса на Хабре).
Как MCP-клиент передаёт описания инструментов
Описания инструментов попадают в промпт как обычный текст: имя, назначение, JSON-схема входных параметров. Клиент может передать их все сразу, и тогда модель выбирает метод из готового списка. Такой подход предсказуем и хорошо работает на коротком каталоге, потому что модели не нужно ничего искать.
Раздувание контекста бьёт по трём местам сразу. Растёт стоимость запроса. Остаётся меньше места под саму задачу, логи и результаты вызовов. И падает точность выбора: когда в промпте сотни похожих описаний, модель чаще цепляется за нерелевантный метод, а ошибка стоит ещё одного круга вызовов.
Почему сокрытие методов за Code Mode само по себе не спасает
Логичный следующий шаг: убрать описания из контекста и дать агенту возможность найти их самостоятельно. Здесь и появляется вторая проблема. Если методы спрятать за Code Mode MCP, LLM иногда при поиске подходящего метода не находит то, что нужно, или вообще не догадывается, что методы надо поискать (источник).
Агент идёт к цели через те инструменты, которые помнит, вместо того чтобы искать новые. В кейсе Nanabot это выглядело именно так: описанные методы вызывались, а новые оставались невидимыми, пока кто-то не подсказывал, что их стоит поискать.
Что такое Code Mode MCP: два инструмента вместо тысяч
Cloudflare предложила Code Mode MCP: вместо тысяч инструментов агент получает два. search() находит необходимые API-методы и получает их сигнатуры по запросу, execute() позволяет выполнять JavaScript-код, вызывающий эти методы (описание подхода).
search(): поиск методов и сигнатур по запросу
Ключевые слова здесь «по запросу». Полное описание метода попадает в контекст в момент, когда агент действительно собирается его вызвать, и только для этого метода. Справочник на 2500 позиций остаётся снаружи и не занимает окно.
Запрос формулируется обычным текстом: «получить описание тикета», «загрузить файл лога», «создать коммит». Реализации search() различаются. В одном из разборов показан агрегатор, который фильтрует массив tools по вхождению подстроки в имя инструмента и возвращает name, description и inputSchema, а запрос вида «сделай скриншот страницы» раскладывается на поиск по словам screenshot и navigate. Это иллюстрация идеи, а не универсальный синтаксис: search() у Cloudflare ищет операции в OpenAPI-спецификации. Ориентироваться стоит на принцип «найти и отдать сигнатуру», а не на конкретную реализацию.
execute(): JavaScript-код с вызовами методов
Смысл не в JavaScript как таковом. Один вызов execute() может объединить несколько вызовов MCP-методов и вернуть итоговый результат, не обращаясь к LLM между каждой операцией (детали).
Разница видна на арифметике раундов. В классической схеме модель вызывает метод, получает ответ, думает, вызывает следующий: пять операций означают пять обращений к модели, и каждое тащит весь предыдущий контекст. В Code Mode агент пишет один скрипт, где пять вызовов идут подряд, а модель получает только финальный результат.
Экономия не бесплатна. Не все операции получится объединить в один вызов: иногда агенту необходимо проанализировать промежуточный результат и принять новое решение. Такие места остаются точками возврата к модели.
Сколько это экономит на самом деле
Точных замеров в кейсе нет, и это честный ответ. Повторные поиски и загрузка сигнатур тоже расходуют токены, поэтому размер экономии зависит от объёма каталога, частоты поисков и количества вызовов (оценка автора).
Ориентир Cloudflare, 2500+ методов и около 1,17 млн токенов при полном представлении, показывает масштаб проблемы, а не обещанную экономию. Если у вас восемь инструментов, схема ничего не даст. Если восемьсот и агент каждый день собирает данные из четырёх систем, считать нужно на своих задачах.
Зачем нужны Skills и как они дополняют Code Mode
Skill содержит алгоритм работы, названия необходимых MCP-серверов и методов, но не их полные сигнатуры. В связке Skill подсказывает, что искать и как использовать, а Code Mode находит полные сигнатуры и выполняет операции (разбор схемы).
Что кладут в Skill, а что оставляют в Code Mode
В Skill идут цель процесса, порядок шагов, имена серверов и методов, условия перехода между шагами и критерий завершения. В Code Mode остаются сигнатуры параметров, типы, обязательность полей и само исполнение.
Полные сигнатуры в Skill класть не нужно: они вернут раздувание контекста, от которого схема и спасает. Примерная структура навыка для процесса «Исправление багов по тикету» выглядит так:
Цель: исправить баг по тикету и закрыть его с отчётом.
Шаги:
1. ticket_mcp: описание задачи, комментарии, вложения.
2. samba_mcp и filesystem_mcp: логи и файлы по тикету.
3. git_mcp: ветка и коммит с исправлением.
4. codex_mcp: запуск Codex для правки кода.
5. jenkins_mcp: проверочная сборка.
6. ticket_mcp: смена статуса, затем отчёт.
Сигнатуры методов не хранить, запрашивать через search().Такой текст занимает десятки строк, а не десятки тысяч токенов, и при этом отвечает на вопрос «с чего начать».
Почему краткое описание навыка работает лучше полного каталога
Агенту не нужно держать в контексте подробные описания всех доступных MCP-инструментов. Вместо этого он получает краткую инструкцию по конкретному процессу и загружает полные сведения о методах только тогда, когда они действительно понадобятся (формулировка автора).
Практический эффект в том, что Skill закрывает провал, из-за которого чистый Code Mode нестабилен. Модель не «забывает» про поиск: в навыке прямым текстом сказано, что следующий шаг выполняется методом ticket_mcp, а сигнатуру надо взять через search(). Указание на конкретный сервер и метод работает как якорь, и вероятность, что агент полезет искать наугад, падает.
Второй эффект: предсказуемость порядка. Полный каталог описаний перечисляет возможности, но не задаёт последовательность. Skill задаёт именно её, и агент реже переставляет шаги, которые зависят друг от друга.
Практический кейс: исправление бага по тикету от начала до отчёта
Навык «Исправление багов по тикету» собирает описание задачи, комментарии, вложения и связанные логи, организует работу над исправлением, фиксирует результат и запускает проверочную сборку (кейс). Ниже цепочка серверов и точки, где реально экономится контекст.
Сбор материалов: ticket_mcp, samba_mcp, filesystem_mcp
Первый блок отвечает за данные. ticket_mcp отдаёт описание задачи, комментарии и список вложений. samba_mcp добирается до сетевых шар, filesystem_mcp читает локальные файлы и логи. Все три шага укладываются в один execute(): агенту не нужно принимать решений между «прочитать тикет» и «прочитать лог».
Здесь экономия заметнее всего. В традиционной схеме каждый вызов идёт отдельным раундом с передачей всего накопленного контекста. В Code Mode модель получает один сводный результат: текст задачи, комментарии и нужные фрагменты логов.
Деталь, которую легко упустить: Skill задаёт порядок и названия методов, но не содержимое вызовов. Если в тикете другой набор вложений, агент подставит другие параметры, не переписывая навык.
Работа с кодом: git_mcp и codex_mcp
git_mcp отвечает за ветку и коммиты, codex_mcp запускает Codex для правки кода. Эта часть редко укладывается в один скрипт целиком: результат правки нужно прочитать и оценить. Не все операции получится объединить в один вызов, иногда агенту необходимо проанализировать промежуточный результат и принять новое решение.
Практический вывод: объединять стоит подготовку (создание ветки, чтение файлов) и фиксацию (коммит с сообщением), а саму правку оставлять точкой возврата к модели.
Проверка и закрытие: jenkins_mcp, смена статуса тикета, отчёт
jenkins_mcp запускает проверочную сборку. Дальше агент ждёт результат и смотрит на статус: упавшая сборка возвращает к правке, успешная открывает путь к закрытию. После этого ticket_mcp меняет статус, а агент готовит отчёт по сделанному.
Запуск сборки и ожидание результата остаются точкой, где агент возвращается к LLM. Склеить запуск и опрос статуса в один execute() можно, а решение «что делать с красной сборкой» принимает модель.
Похожие цепочки уже собирают вокруг трекеров: в разборе про виртуальных исполнителей в Jira видно, как агенту передают контекст из Confluence и GitLab, а ревью оставляют человеку. Skills + Code Mode решают другую часть той же задачи: как не утонуть в описаниях инструментов, когда интеграций много.
Ограничения схемы: где Skills + Code Mode ломаются
Схема не даёт стопроцентной гарантии. LLM всё ещё может не выбрать нужный Skill, ошибиться при поиске метода или неправильно сформировать JavaScript.
Ошибки выбора Skill и поиска метода
Модель может пройти мимо навыка, если его описание в списке доступных сформулировано расплывчато. Может найти метод по имени, но не понять, что он делает. Отсюда правило: в Skill нужны явные названия MCP-серверов и методов, а формулировки шагов должны совпадать с лексикой, которой агент пользуется при поиске.
Проверять стоит на конкретных задачах. Дайте агенту тикет и посмотрите, вызвал ли он search() с осмысленным запросом или пошёл по памяти. Отсутствие вызова search() на незнакомой задаче сигнализирует, что Skill слишком абстрактный.
Ошибки в JavaScript и предел объединения операций
Сгенерированный код может не собраться: опечатка в имени метода, неверный тип аргумента, забытый await. Чем длиннее скрипт в execute(), тем больше в нём мест для такой ошибки и тем дороже отладка, потому что модель видит только текст исключения.
Второй предел связан с характером задач. Правки Codex и результат сборки Jenkins требуют оценки перед следующим шагом, и это нормальная граница автоматизации в одном вызове. Схема ускоряет рутину и не заменяет решения.
Отдельный риск в последствиях вызовов. Когда один скрипт делает несколько операций подряд, ошибка в середине обходится дороже, чем при пошаговом выполнении с проверкой. Разбор кейса с read-only агентом, изменившим запись, показывает, почему границы прав проверяют на уровне исполнения, а не на уровне формулировок в промпте.
Когда схема оправдана, а когда хватит обычного MCP
Схема имеет смысл при большом каталоге методов, частых поисках и цепочках вызовов, которые можно объединить в один скрипт. При небольшом числе инструментов и задачах, где почти каждый шаг требует анализа промежуточного результата, выгода падает: поиски и загрузка сигнатур сами расходуют токены.
Сравнение трёх подходов
| Подход | Что в контексте | Как находится метод | Где экономия | Где риск |
|---|---|---|---|---|
| Традиционная схема MCP | Описания всех подключенных инструментов | Модель выбирает из готового списка | Поиска нет, всё под рукой | Контекст растёт вместе с каталогом, выбор ухудшается |
| Чистый Code Mode MCP | Два инструмента: search() и execute() | Модель сама решает вызвать search() | Описания не висят в окне постоянно | Агент иногда не ищет методы вовсе |
| Skills + Code Mode | Краткий Skill и те же два инструмента | Skill задаёт направление, search() отдаёт сигнатуры | Экономия на каталоге и на раундах вызовов | Ошибки выбора Skill, поиска метода, JavaScript |
С чего начать внедрение
Брать один процесс, а не весь каталог. Исправление бага по тикету подходит: у него понятные шаги и известный набор серверов. Дальше напишите Skill с алгоритмом и названиями методов, без сигнатур. Потом проверьте, что агент вызывает search() перед незнакомым методом и складывает подготовительные шаги в execute().
Если MCP-сервер только предстоит писать, каталог методов стоит продумать заранее: имена, по которым search() будет находить нужное, группировка по задачам, минимальные сигнатуры. На практике решения о составе и видимости инструментов занимают больше времени, чем сам код сервера. Примеры такой архитектуры разбираются в материале про MCP-инструменты в Gateway на Amazon Bedrock AgentCore.
Для агентов, которые работают между сессиями, важна и вторая половина задачи: где хранить состояние процесса. Later Bender даёт пример внешнего слоя с задачами и runbook'ами, который подключается к разным моделям через MCP: Skill описывает шаги, а состояние остаётся в хранилище.
Вывод: что даёт Skills + Code Mode и чего не даёт
Схема снимает основную боль. Подробные описания методов перестают висеть в контексте, агент получает краткий Skill с маршрутом и два инструмента, search() и execute(). Один вызов execute() объединяет несколько операций без обращения к LLM между ними, а полные сигнатуры подгружаются по необходимости.
Гарантии схема не даёт. Модель может не выбрать Skill, ошибиться в поиске метода или в JavaScript, а часть шагов придётся возвращать к LLM, потому что результат нужно оценить. Экономия токенов зависит от объёма каталога и характера задач, и посчитать её можно только на своих сценариях.
Первый шаг конкретный. Возьмите один повторяющийся процесс, опишите его как Skill с именами MCP-серверов и методов и посмотрите, как агент справится с поиском сигнатур. Если он стабильно вызывает search() и укладывает рутину в execute(), каталог можно расширять дальше.