Короткий ответ: платите не за протокол, а за интерфейс доступа
Счёт за подключение ИИ-агента к API определяют две характеристики интерфейса доступа: объём данных, который инструмент возвращает в модель, и возможность собрать несколько операций в один составной вызов. Выбор между CLI и MCP влияет на итог слабее, чем принято думать.
Числа из эксперимента Arseniy Potapov (проект Takt). Готовые MCP-серверы требовали в 3-6 раз больше вызовов, чем базовый вариант с GraphQL CLI, и обходились до 6,5 раза дороже. В контрольном прогоне, где CLI и MCP получили одинаковый набор операций, разница в стоимости составила 1,13 раза.
Порядок работы, который следует из этих цифр: сначала список операций под реальные задачи агента и интерфейс с компактными ответами, затем решение о протоколе. Ниже разбор методики и цифр из перевода статьи Arseniy Potapov в блоге OTUS. Своих замеров редакция не проводила.
Что сравнивали в эксперименте: четыре способа подключения к GitHub API и Takt
Полигоном стали два несхожих API: GitHub API и Takt, сервис автора. GitHub API даёт широкое поле для GraphQL-запросов, Takt ближе к продуктовой доске задач. Два разных источника нужны, чтобы отделить эффект протокола от эффекта одного конкретного сервера.
Сравнивались четыре конфигурации:
- заранее заданный набор команд CLI, где маршрут агента прописан сценарием;
- GraphQL-запрос через CLI (GraphQL CLI), базовая линия, относительно которой считались множители;
- готовый MCP-сервер;
- один инструмент graphql, доступный через MCP.
Прогоны шли на моделях Sonnet и Sol. Метрики три: стоимость, количество вызовов, расход токенов. Полные детали замеров автор приводит в исходной статье на Habr.
Логика выбора полигона важна для оценки выводов. Если бы тест ограничился одним API, множители можно было бы списать на особенности конкретного сервиса и его схемы. Две разные системы ловят эту ошибку: множители повторяются там, где совпадает структура инструментов.
Как MCP-сервер описывает инструменты и почему этот слой стал отдельным интерфейсом продукта, разбирали в материале про MCP как новый интерфейс продукта.
Откуда берутся 3-6x по вызовам и 6,5x по стоимости
Механика перерасхода складывается из двух шагов. Готовый MCP-сервер отдаёт ответ целиком, со всеми полями, которые предусмотрел автор сервера. Агент получает килобайты текста, платит за них токенами и всё равно идёт за следующей порцией.
Второй шаг: инструмент из готового набора решает одну узкую задачу. Связать пять действий (получить список, отфильтровать, уточнить детали, изменить, проверить) агент может только цепочкой из пяти вызовов. Каждый круг добавляет запрос к модели и ответ обратно, и оба оплачиваются.
Отсюда множители. Формулировка из источника: все готовые MCP-серверы требовали в 3-6 раз больше вызовов, чем базовый вариант с GraphQL CLI. Разброс между 3 и 6 показателен сам по себе. Если бы причиной был протокол, серверы укладывались бы в узкий коридор, а разные цифры у разных серверов говорят, что вклад вносит качество конкретной сборки инструментов.
Ограничение, без которого цифры превращаются в натяжку: замеры шли на Sonnet и Sol, на GitHub API и Takt. Переносить множители на другой стек без собственной проверки нельзя.
Контрольный эксперимент: почему разница упала до 1,13 раза
В контрольном прогоне автор уравнял набор операций и интерфейс доступа, оставив различие только в способе взаимодействия: CLI или MCP. Стоимость отличалась в 1,13 раза.
Результат снимает главный тезис спора. Пока интерфейс отдаёт умеренные ответы и позволяет собрать составной запрос, протокол почти не влияет на счёт. Подтверждение из источника: интерфейс с поддержкой составных запросов (surface) обычно сокращал затраты, и неважно, был он собран на CLI или как инструмент MCP.
1,13x стоит читать буквально. Это не значит, что MCP ничего не стоит: это значит, что при равном интерфейсе разница уходит в шум рядом с эффектом от дизайна операций. Если ваш MCP-сервер дороже CLI в шесть раз, проблема почти наверняка в том, что он отдаёт модели и сколько вызовов требует.
Почему объём ответа и составные вызовы решают больше, чем протокол
Каждый килобайт ответа превращается в токены контекста. Токены едут в модель на каждом шаге агента, а не один раз за сессию, поэтому лишние поля в JSON оплачиваются многократно. Второй рычаг - составной вызов: одна операция вместо пяти снимает четыре круга обмена с моделью.
Список инструментов MCP тоже стоит денег
Автор измерил размер списка инструментов MCP в Takt и, по его словам, был поражён результатом. Описания инструментов лежат в контексте постоянно, ещё до того как агент сделал хоть один вызов.
Дилемма из источника выглядит так: MCP должен оставаться компактным, иначе засоряет контекст лишней информацией, но чем он компактнее, тем меньше возможностей даёт. Практический смысл для разработчика: большой каталог превращается в постоянный налог на каждый запрос, а не в разовый расход при подключении.
Масштаб легко представить по соседнему примеру: в Linux MCP daemon (mcpd) агент получает 38 инструментов вместо SSH с sudo, и описание каждого занимает место в контексте до первого полезного действия.
Фильтрация ответов до попадания в модель
Приём, который не требует смены протокола: отдавать агенту уже отфильтрованный результат вместо полного JSON. В CLI-цепочке это делает jq. Запрос уходит в API, ответ режется до нужных полей, в контекст попадают три строки вместо трёхсот. Тот же принцип работает в MCP-инструменте: если сама операция возвращает только нужные поля, протокол перестаёт быть узким местом.
Питер Штайнбергер в подкасте Лекса Фридмана сформулировал это резко: любой MCP лучше бы работал как CLI, потому что MCP забивает контекст большими объёмами данных, которые через CLI можно отфильтровать с помощью jq. Держите в голове, что это позиция практика, а не измерение. Контрольный прогон показал, что протокол сам по себе не приговор: решает то, что именно инструмент отдаёт модели.
Скрытые издержки: сколько стоит поддерживать CLI и MCP одновременно
Токены не единственная статья расходов. Второй адаптер удваивает поверхность, которую нужно держать в согласии с API. Три класса проблем всплывают почти в любом проекте с двумя способами доступа.
- Дублирование валидации. Правила проверки аргументов живут в двух местах: в CLI и в MCP-сервере. Изменение схемы вносится дважды, а расхождение обнаруживается на живом запросе.
- Расхождения в правах доступа. CLI и MCP-сервер могут трактовать permissions по-разному, и разница проявляется в проде, когда агент получает через один адаптер то, что второй закрывал.
- Обратная совместимость инструментов. Переименование метода или правка схемы ломает один из адаптеров, а имена инструментов после публикации менять дорого.
Подтверждение из практики автора: за два месяца он разобрал четыре сбоя при работе с агентами. Две проблемы возникли по его вине, конфликтующие имена инструментов (create_wiki и wiki_create) и около 40 инструментов, возвращавших JSON, дважды закодированный внутри JSON. Оба случая описаны в разборе на Habr и оба относятся к дизайну, а не к протоколу.
Баг MCP-клиента, из-за которого появился taktcli
Один сбой оказался целиком на стороне клиента. MCP-клиент отбрасывал весь объект arguments, если хотя бы одно значение было пустой строкой. Агент пытался отвязать задачу от родительской на доске Takt, отправлял parent="", а сервер получал arguments: {}. Обойти это со стороны сервера было невозможно: аргументы не доходили до кода.
Отсюда появился taktcli. С ним весь код между аргументами агента и HTTP API находится под контролем автора: видно, что именно пришло, и нет зависимости от поведения чужого клиента. Это аргумент про контроль над цепочкой, а не приговор протоколу.
Скорость разработки не равна скорости эксплуатации
Несколько агентов параллельно написали CLI за один день. Команда taktcli login сломалась при первом реальном использовании: страницы, на которую она ссылалась, ещё не существовало. Код есть, сценарий не проверен.
Риск одинаков для CLI и MCP-сервера. Агенты быстро выдают код, а интеграционные дыры видны только на живом сценарии: реальный логин, реальные права, реальный ответ API с пустым полем.
Считайте обе статьи расходов. Цена поддержки двух адаптеров часто выше разницы в токенах, которую они должны были сэкономить.
Так что выбрать: CLI, MCP или оба
Рамка без категоричных советов, потому что решает контекст, а не мода на протокол.
CLI уместен, когда нужен полный контроль над цепочкой «аргументы → API», когда важна фильтрация вывода на стороне клиента и когда потребитель один. Сценарий с консольными кодинг-агентами (Claude Code, Codex, Gemini CLI) и удалённым управлением через Telegram разбирали в материале про AcpGram: там ставка сделана именно на CLI-интерфейс.
MCP уместен, когда нужна одна интеграция для разных клиентов и готовность отдавать инструменты в стандартном протоколе. Пример из практики: в Connected Analytics от AvioBook MCP-инструменты вынесены в Gateway, а доступ к данным изолирован через JWT и Cognito, детали в разборе мультиагентной системы. Ценность здесь в единой точке подключения, а не в экономии токенов.
Оба адаптера оправданы, если есть ресурс на синхронизацию валидации и прав и понятно, где живёт истина в правах доступа.
| Критерий | CLI | MCP |
|---|---|---|
| Контроль над кодом между аргументами и API | полный, как в taktcli | зависит от клиента: баг с пустой строкой обойти было нельзя |
| Фильтрация ответа | jq и пайпы до попадания в модель | закладывается в сам инструмент |
| Стоимость в тестах | базовая линия GraphQL CLI | готовые серверы: 3-6x вызовов, до 6,5x стоимости; равный интерфейс: 1,13x |
| Стандартизация для многих клиентов | своя у каждого инструмента | единый протокол |
Ограничения проговорим прямо: множители получены на Sonnet и Sol, на GitHub API и Takt. В другом стеке они могут выглядеть иначе, проверять придётся своими замерами. Автор исходной статьи отметил, что результаты подтвердили его предположения о стоимости, но опровергли объяснение причин. Интуиция «MCP дорогой» верна для конкретных сборок серверов, а не для протокола целиком.
Чек-лист: проектируем операции и интерфейс до выбора протокола
- Выпишите реальные задачи агента, а не методы API. Список «что агент должен уметь» обычно короче списка «что умеет API».
- Сгруппируйте задачи в минимальный набор операций. Одна операция на сценарий, а не на каждый endpoint.
- Для каждой операции определите, что реально нужно вернуть, и урежьте ответ. Лишние поля оплачиваются на каждом шаге агента.
- Найдите места, где агент делает цепочку из четырёх-пяти вызовов, и добавьте составной вызов. Именно этот шаг отделяет 3-6x от 1,13x.
- Посчитайте, сколько инструментов попадёт в список, и оцените размер их описаний. Каталог из десятков инструментов работает как постоянный налог на контекст.
- Только теперь выбирайте способ: CLI, MCP или оба.
- Если делаете два адаптера, заранее решите, где живёт валидация, как проверяются права и что происходит при переименовании инструмента. История с create_wiki и wiki_create показывает цену отложенного решения.
Финальная проверка простая. Если после этих шагов агент делает один вызов вместо пяти и получает 20 полей вместо 200, вопрос «CLI или MCP» перестаёт быть вопросом о деньгах. Он становится вопросом о том, какой клиент вам удобнее поддерживать.