Когда работаешь с ИИ‑агентом каждый день, важно не только качество постановки задачи, но и эффективность расходования ресурсов. Контекстное окно ограничено, а токены тратятся не только на решение самой задачи, но и на служебные данные: описания инструментов, параметры вызовов и промежуточные результаты. Чем выше эти накладные расходы, тем меньше ресурса остаётся на полезную работу. Нам захотелось разобраться, как делать больше, а расходовать меньше.

Для этого мы сравнили два способа «подружить» ИИ‑агента с внутренними API — MCP и CLI + Skill. Взяли гипотезу из внешних исследований, собрали бенчмарк на 14 сценариях и двух моделях, прогнали больше 400 запросов на реальных внутренних инструментах. И в какой‑то момент всё, что работало, сломалось — и это оказалось самым интересным. Пришлось разбираться почему.

Привет, меня зовут Даниил Михайлов, я из команды разработки партнёрских продуктов Городских сервисов Яндекса. В статье расскажу, что именно мы измеряли, как ломали свои же результаты и к каким выводам в итоге пришли. В конце статьи — дерево решений: когда какой подход использовать.

Далее по тексту будет встречается много терминов — для удобства собрал их в одном месте.

Стартовая точка

Итак, сначала поговорим про то, что у нас получилось.

Мы написали CLI‑обёртки над внутренними API: Tracker (трекер задач), Arcanum (код‑хостинг) и Intrasearch (внутренний поиск), подключили их к агенту через компактную markdown‑документацию в SKILL.md и сравнили с MCP по расходу контекста, токенов и числу API‑вызовов. Качество ответов при этом оказалось сопоставимым во всех режимах: агент в каждом случае справлялся с задачей. Нас интересовало не качество как таковое, а стоимость решения: сколько контекста и токенов уходит на один и тот же класс задач.

Контекст здесь — это всё, что модель «видит» одновременно: системный промпт, описания инструментов, история диалога, ваш код. Это ограниченный ресурс: чем больше в нём занято описаниями инструментов, тем меньше остаётся на код и, собственно, на задачу пользователя.

Однозначного победителя нет, всё зависит от типа задачи. На простых запросах вроде «покажи статус пул‑реквеста» выигрывает MCP с lazy loading: один вызов, минимум накладных расходов. На типовых рабочих задачах — «покажи задачу и упавшие проверки в CI» — оптимизированный CLI + Skill экономит 30–50% ресурсов: компактная документация и контроль вывода окупаются. На сложных сценариях вроде «спланируй реализацию фичи по задаче» CLI + Skill в 5,5 раза экономичнее MCP, потому что полная документация избавляет агента от лишних шагов на поиск нужных инструментов. А вот на тяжёлых данных — например, diff на 50+ файлов — MCP с полной загрузкой снова выгоднее: все описания тулов уже в контексте, добирать нечего.

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

Если совсем коротко, получается так: 

• типовые ежедневные задачи — CLI + Skill с оптимизированной документацией;

• сложные многошаговые сценарии — CLI + Skill с полной документацией; 

• если ваш агент использует eager loading — CLI + Skill чаще оказывается выгоднее; 

• если нужны специфичные для MCP вещи (стриминг, подписки, OAuth) — берите MCP. 

Дальше расскажу, как мы к этому пришли.

MCP vs CLI + Skill: в чём вообще разница

Оба подхода решают одну задачу: дают ИИ‑агенту доступ к внешним инструментам — в нашем случае к Tracker, Arcanum и Intrasearch.

У MCP главный плюс — Plug‑and‑Play: подключили сервер и поехали. Главный минус — размер описаний тулов и формат вывода контролирует сервер, а не вы.

У CLI + Skill главное преимущество в том, что вы полностью контролируете и размер документации, и формат вывода. Цена за это — необходимость написать CLI‑обёртку и markdown‑документацию, а также зависимость от среды, в которой агенту разрешён запуск shell‑команд.

Вот как это выглядит в виде схемы. Слева — MCP: агент и сервер общаются по JSON‑RPC, сервер отдаёт schemas всех тулов, агент вызывает нужную. Справа — CLI + Skill: агент читает SKILL.md, выбирает подходящую команду, запускает shell‑обёртку и получает её вывод.

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

Гипотеза: CLI + Skill должен быть экономнее

Мы не первые, кто задумался. На момент старта эксперимента уже были опубликованы внешние разборы, указывающие, что CLI‑подход может быть заметно эффективнее MCP по расходу контекста и токенов.

ScaleKit прогнали 75 запусков на одной из популярных моделей: CLI оказался экономнее MCP в 10–32 раза по расходу ресурсов. Надёжность тоже разошлась: у CLI — 100%, у MCP из 25 прогонов 7 упали по ConnectTimeout. Причина знакомая: GitHub MCP server выставляет 43 тула, и все schemas летят в каждый запрос.

Reinhard посчитал то же самое с другой стороны. GitHub MCP с 93 тулами — это ~55 тыс. токенов ещё до первого вопроса. На реальной задаче CLI у него получился экономичнее в 35 раз.

Perplexity в марте 2026 года отказались от MCP. Их технический директор тогда сказал, что MCP потребляет в 15–20 раз больше токенов без улучшения качества.

Но была и другая точка зрения, которая нас немного насторожила. Port of Context на сложных задачах показали обратное: MCP может быть эффективнее CLI. Их вывод звучал осторожнее, чем у остальных: «MCP — это транспортный примитив, реализация важнее протокола».

С этими вводными мы и начали измерения.

Почему мы начали с CLI

Когда мы писали первые CLI‑обёртки, контекст был такой: большинство популярных IDE и ИИ‑агентов использовали eager loading для MCP. Каждый MCP‑тул со своей JSON Schema попадал в контекст при каждом запросе. Мы замерили, сколько это стоит:

~39 тыс. токенов — это ~20% от 200 тыс. контекстного окна у современных моделей этого класса. Просто на описание того, что агент может делать, ещё до того, как он сделал хоть что‑то полезное.

Если посмотреть по конкретным инструментам — разница особенно заметна на Arcanum и Tracker:

Мотивация была простой: написать bash‑обёртки с компактной документацией — примерно 1 тыс. токенов вместо 39 тыс. — и сэкономить контекст.

Мы написали CLI + Skill, первые бенчмарки показали отличные результаты — CLI оказался экономичнее в разы. Казалось, дело закрыто: MCP с его 39K просто не может конкурировать с 1 тыс. документации.

А потом всё изменилось.

Индустрия переходит на lazy loading

Мы начали мерить дальше и заметили, что в одном из используемых нами ИИ‑агентов MCP больше не работает через полную предварительную загрузку всех описаний инструментов. Оказалось, разработчики добавили механизм lazy loading для MCP. Вместо всех 86 схем при каждом запросе в контексте хранятся только имена тулов — около 200 токенов. Когда модели нужен конкретный тул, агент сначала выполняет служебный шаг выбора или получения его схемы, а затем уже делает обычный tool call.

Мы решили проверить, как другие ИИ‑агенты обрабатывают MCP:

• Lazy loading. В контексте — только имена тулов (~200 токенов). При первом вызове подгружается схема (+850 токенов). Далее тул вызывается напрямую.

• Файловый подход. При старте IDE все описания тулов записываются на диск как JSON‑файлы. В контексте — только generic‑обёртка call_mcp_tool (~300 токенов). Когда нужен тул, модель читает соответствующий JSON‑файл, а затем использует его для вызова.

На момент написания статьи в одном из ИИ‑агентов, которые мы используем внутри, по‑прежнему используется eager loading. Мы убедились в этом, попросив модель: «Покажи точную JSON Schema для GetIssues» — она выдала полную схему со всеми полями без единого tool_call. Это возможно только в том случае, если схема уже была в контексте.

Так это выглядит в коде, все tools сразу сериализуются в список функций для модели:

function getMcpServerTools(mcpHub?: McpHub) {
    for (const server of mcpHub.getServers()) {
        for (const tool of server.tools) {
            tools.push({
                type: "function",
                function: { name: buildMcpToolName(server.name, tool.name),
                            description: tool.description,
                            parameters: tool.inputSchema }
            })
        }
    }
}

С lazy loading overhead MCP в агентах, которые его поддерживают, снизился на порядок. Но возник вопрос: стоит ли CLI‑подход того, если MCP стал настолько экономичнее? Нужны бенчмарки.

Eager vs lazy: замеряем разницу

Чтобы понять, насколько lazy loading меняет расклад, мы прогнали одинаковые сценарии в двух режимах — с eager и lazy. Всё остальное — модель, задачи, промпты — оставили без изменений.

На графике стоимости видна разница: на PR status у eager расход в 2,3 раза выше, чем у lazy. На графике контекста причина видна ещё лучше: eager увеличивает объём контекста до 246 тыс. против 76 тыс. у lazy — все 87 tool schemas загружаются при каждом запросе, даже если реально нужен всего один тул.

Интересное исключение — Ticket и Intrasearch: здесь разница минимальна. Задачи настолько простые, что агент решает их за несколько действий, и накладные расходы на лишние описания инструментов почти не успевают накопиться.

Для multi‑tool‑сценария (Ticket + PR) у eager снова расход в 1,6 раза выше, а контекст вырастает с 112 тыс. до 265 тыс.

Оптимизация: от 19 тыс. до 4 тыс. символов

Когда MCP стал заметно экономичнее за счёт lazy loading, стало ясно, что нам тоже нужно оптимизировать свою сторону — прежде всего, skill‑документацию. Мы посмотрели на исходные 19 тыс. символов и быстро поняли: значительную часть этого объёма можно сократить без потери полезного сигнала для агента.

Когда MCP стал заметно экономичнее за счёт lazy loading, стало ясно, что нам тоже нужно оптимизировать свою сторону — прежде всего, skill‑документацию. Мы посмотрели на исходные 19 тыс. символов и быстро поняли: значительную часть этого объёма можно сократить без потери полезного сигнала для агента.

Мы сделали три версии документации разной степени детализации:

• Original — полная версия: все команды, основные опции, примеры вызова и синтаксис языка запросов.

• Medium — компактный список команд с однострочным описанием. Мы убрали примеры и второстепенные детали, оставив только то, что помогает агенту выбрать нужную команду и понять её базовый синтаксис.

Optimized — минимальная версия с ключевыми командами и почти без пояснений. Этот вариант оказался слишком агрессивным: в части сценариев агенту не хватало информации, чтобы выбрать правильную команду.

### show -- Show ticket details
  tracker-cli.sh show QUEUE-1234
  tracker-cli.sh show QUEUE-1234 --json --fields project, priority
Returns: key, summary, status, priority, queue, assignee, dates, description.
Options: --json (raw JSON), --fields f1, f2 (specific fields)
...ещё 20+ команд в таком же формате

Commands:
  show TICKET [--fields F1, F2] [--compact]  Ticket details
  search --query "TQL" [--fields F1, F2]     Search (TQL)
  status TICKET STATUS [--field K=V]        Change status
  ...ещё 12 команд в том же формате

CLI: tracker-cli.sh [--json] <command> [args]
Run tracker-cli.sh help for commands, help <cmd> for details.

Оптимизация вывода CLI

Кроме документации, мы оптимизировали и сами CLI‑обёртки.

Во‑первых, мы сократили объём ответа:

• --json — структурированный вывод в JSON вместо форматированного текста: такой результат модели проще обрабатывать и использовать дальше;

• --compact — сокращённый вывод только с ключевыми полями;

• --page-size 5 — ограничение размера выдачи, чтобы не передавать десятки результатов, когда достаточно нескольких.

Во‑вторых, мы добавили более крупные команды для сценариев, где агенту нужен агрегированный результат целиком. Например, full‑diff PR_ID возвращает весь diff пул‑реквеста за один вызов, вместо того чтобы запрашивать diff отдельно для каждого файла через серию вызовов file‑diff.

# Полный вывод -- все поля, formatted text (~2K символов)
arcanum-cli.sh pr-data 12345678

# Компактный JSON -- только ключевые поля (~500 символов)
arcanum-cli.sh pr-data 12345678 --compact --json

# Поиск с ограничением -- 5 результатов вместо 50 по умолчанию
intrasearch-cli.sh search "query" --page-size 5

# Один вызов вместо N -- все диффы PR за раз
arcanum-cli.sh full-diff 12345678
# vs N отдельных вызовов:
arcanum-cli.sh file-diff 12345678 path/to/file1.go
arcanum-cli.sh file-diff 12345678 path/to/file2.go

Практический эффект здесь двойной: компактный вывод уменьшает объём данных, попадающих в контекст, а агрегированные команды дополнительно сокращают число шагов во взаимодействии агента с инструментами.

В связке с medium‑версией skill‑документации это дало лучший результат: агенту хватало краткого описания команд, а сами команды возвращали уже компактный и удобный для модели ответ.

Бенчмарки: полная картина

Хорошо, хватит теории. Вот цифры.

Методология:

• CLI‑клиент работал в неинтерактивном режиме;

• две модели одного семейства — старшая и младшая, обе с контекстным окном 200K токенов;

• не меньше трёх прогонов на каждую комбинацию (сценарий × режим × модель), усреднение по warm‑прогонам;

• 14 сценариев: от «покажи статус PR» до «спланируй реализацию фичи по тикету»;

• пять режимов: skill‑original, skill‑medium, skill‑optimized, mcp‑lazy, mcp‑eager;

• для каждого режима мы жёстко разводили доступные инструменты, чтобы в CLI‑сценариях агент не видел MCP‑инструменты.

Что видно по подходам:

• MCP lazy побеждает на простых задачах (S1, S2) и code review (S9) — минимальный overhead, schema подгружается один раз. Также расход ниже на error handling (S12).

• Skill‑medium побеждает на типовых рабочих задачах (S3–S6, S8, S11, S13) — экономия 30–52% по сравнению с MCP lazy. Компактная документация и контроль вывода окупаются.

• Skill‑original побеждает на сложных workflow (S10) — экономичнее в 5,5 раза. Полная документация экономит turns на поиск тулов трёх MCP‑серверов.

• Skill‑optimized (минимальная документация, агент открывает help при необходимости) — не побеждает ни в одном сценарии по суммарному расходу ресурсов, но даёт самую компактную загрузку в контекст. Полезен, когда нужно сэкономить место в context window.

• MCP eager лучше показывает себя на сценариях с тяжёлыми данными (S7, S14): описания инструментов уже переданы модели, и дополнительных шагов на их подгрузку не требуется. Но на простых задачах его накладные расходы заметно выше — до двух раз по сравнению с lazy loading.

Контекст: скрытая стоимость

У skill‑medium суммарный контекстный расход по сценарию стабильно держится около 60К токенов. У MCP lazy он варьируется от 58К (S1, S12) до 603К (S10). Здесь важно, что речь идёт именно о суммарном расходе по всем шагам сценария, а не о размере одного контекстного окна. Предсказуемость потребления контекста — одно из скрытых преимуществ CLI‑подхода.

Старшая vs младшая модель

Мы прогнали все 14 сценариев на младшей модели. Младшая экономичнее примерно в пять раз в пересчёте на токен, но в абсолюте экономия получается всего в два‑три раза — младшая делает больше turns из‑за меньших возможностей модели.

При этом основные паттерны сохраняются: MCP lazy остаётся наиболее эффективным на простых задачах, а skill‑medium — на типовых рабочих сценариях. Связка «младшая модель + skill‑medium» — самая бюджетная комбинация для типового вызова.

Полная картина младшей модели по всем сценариям:

Итоги замеров

После 400+ прогонов картина получилась такой: на старшей модели один из режимов CLI + Skill показал минимальный расход ресурсов в 9 сценариях из 14, режимы MCP — в 5. На младшей модели разрыв меньше: 8 против 6.

Интересно, что на младшей модели чаще выигрывает skill‑original — 4 сценария, тогда как на старшей лидирует skill‑medium — 7 сценариев. Это хорошо согласуется с общей картиной: для менее сильной модели полезнее более подробная документация, даже если она занимает больше места в контексте.

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

Если свести всё к практическим рекомендациям, то картинка в наших сценариях выглядит так.

На простых и точечных запросах — MCP lazy. Один вызов, минимум turns, без лишних накладных расходов. Это S1 (PR status), S2 (Ticket), S9 (Code review), S12 (Error handling).

На типовых рабочих задачах — skill‑medium. Это сценарии S3–S6, S8, S11, S13: тикет + PR, поиск документации, ежедневные комбинации. Выигрыш — 30–52% ресурсов по сравнению с MCP lazy за счёт компактной документации и контроля вывода.

На сложных многошаговых сценариях — skill‑original. На S10 (планирование фичи по тикету) полная документация экономит turns на поиск тулов трёх MCP‑серверов, и CLI оказывается экономичнее в 5,5 раза.

На сценариях с тяжёлыми входными данными — MCP eager. На S7 (поиск багов и документации) и S14 (diff большого PR) schemas уже были в контексте, поэтому агенту не приходилось тратить дополнительные шаги на их подгрузку.

Но графики показывают не всё. У CLI + Skill есть и качественные преимущества:

• полный контроль над форматом вывода через флаги вроде --json, --compact, --page-size и --max-chars;

• возможность быстро добавлять новые команды под конкретные сценарии;

• независимость от конкретного клиента: подход работает в агентных средах, где разрешён запуск shell‑команд;

• обычный цикл разработки и контроля версий: skill‑документация лежит в репозитории рядом с кодом и проходит тот же code review, что и остальная интеграция.

Выводы

Однозначного победителя нет. MCP lazy лучше показывает себя на простых задачах, skill‑medium — на типовых рабочих сценариях, а skill‑original — на сложных многошаговых задачах. Выбор зависит прежде всего от того, какие сценарии преобладают в вашей практике.

Оптимизация документации критична. Без неё CLI + Skill проигрывал MCP во многих сценариях: исходная версия нашей skill‑документации была слишком подробной и создавала лишний overhead. После того как мы сократили её на 78% и пришли к варианту skill‑medium, этот режим стал лучшим в 7 сценариях из 14.

Eager MCP оправдан для тяжёлых данных. На простых задачах он требует заметно больше ресурсов, чем lazy loading, но на сценариях с тяжёлыми входными данными — например, S7 и S14 — оказывался выгоднее: схемы инструментов уже были в контексте, и агенту не приходилось тратить шаги на их подгрузку.

CLI часто выигрывает не только по затратам, но и по простоте внедрения. На сложных сценариях CLI экономичнее в 5,5 раза. Если готовые skill и MCP‑сервер уже существуют, подключение в обоих случаях обычно сопоставимо по сложности. Но если интеграцию нужно писать с нуля, собственный skill чаще сделать проще: достаточно CLI‑обёртки и компактной документации, тогда как MCP обычно требует отдельного серверного слоя, описаний инструментов и протокольной обвязки.