MCP или CLI для AI-агентов: плюсы, минусы и выбор

Спор «MCP или CLI для AI-агентов» обычно начинается с эффектного тезиса. MCP называют универсальным разъёмом для AI, CLI - старым добрым интерфейсом, который модель уже умеет использовать. Потом одна сторона считает токены, другая вспоминает OAuth и аудит, и обсуждение быстро превращается в выбор религии.

Как мне кажется, реальный вопрос проще: где работает агент, от чьего имени он действует и кто отвечает за последствия. Если агент помогает одному разработчику в локальном репозитории, CLI часто оказывается самым коротким путём. Если десятки агентов ходят в GitLab, CRM, таск-трекер и внутренние документы от имени разных сотрудников, одного shell-доступа уже мало.

MCP и CLI решают разные задачи. CLI даёт агенту способ управлять программами через команды, stdout, stderr и exit codes. MCP задаёт стандартный контракт между AI-хостом и сервером инструментов: discovery, схемы параметров, вызовы, ресурсы, авторизацию и жизненный цикл соединения. Оба подхода могут быть быстрыми, опасными, удобными или дорогими - всё зависит от того, какую архитектуру вокруг них построили.

Ниже - плюсы и минусы MCP и CLI без магии. В конце будет конкретная матрица выбора и гибридная схема, которая на практике часто разумнее ответа «только MCP» или «только терминал».

MCP и CLI: в чём принципиальная разница

CLI, или command-line interface, рассчитан на выполнение команд в операционной системе. Агент формирует строку вроде:

gh issue list --state open --limit 5 --json number,title

Дальше shell запускает процесс, а агент читает результат. Команды можно соединять через pipes, фильтровать jq, сохранять в файл, оборачивать в скрипт и повторять. Для git, docker, kubectl, terraform, gh и других зрелых developer tools это естественная среда.

MCP, или Model Context Protocol, работает иначе. MCP-сервер публикует список доступных tools, resources и prompts. AI-хост получает их описания и схемы, а модель формирует структурированный вызов, например:

{
  "name": "list_issues",
  "arguments": {
    "state": "open",
    "limit": 5
  }
}

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

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

Плюсы CLI для AI-агентов

1. CLI уже встроен в инженерный workflow

Разработчики и platform-команды годами используют shell-команды в терминале, CI и runbook. Репозиторий уже содержит скрипты, Makefile, package scripts и инструкции. Агент может работать с теми же интерфейсами, что и человек, без отдельного MCP-сервера для каждой операции.

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

2. Команды легко компоновать

Сильная сторона CLI - не одна команда, а возможность собрать из нескольких команд маленький workflow. Агент может получить большой JSON, оставить нужные поля через jq, сравнить результат с файлом и передать данные следующей утилите. Промежуточный объём не обязательно отправлять модели целиком.

Для повторяемой операции агент может написать скрипт, проверить его и запускать снова. MCP тоже позволяет строить сложные серверные tools, но композиция должна быть предусмотрена разработчиком сервера или выполнена через несколько tool calls.

3. Контекст можно раскрывать постепенно

CLI обычно не требует заранее загружать в контекст модели полные схемы всех возможных команд. Агент знает имя утилиты, при необходимости вызывает --help и читает только нужный раздел. Это экономит контекст, когда инструментов много.

Официальные рекомендации для MCP-клиентов отдельно предупреждают: наивная загрузка определений всех tools от десятков серверов может занять значительную часть контекстного окна. То есть проблема реальна, но относится не только к протоколу - многое зависит от качества MCP-host и progressive disclosure.

4. Локальная диагностика прозрачна

Команду можно повторить руками. Видны exit code, stdout и stderr. Инженер может скопировать проблемный вызов из лога и воспроизвести его в той же среде. Для отладки сборки или тестов это зачастую проще, чем разбирать цепочку host → client → transport → MCP server → upstream API.

Минусы CLI для AI-агентов

1. Shell-доступ часто шире реальной задачи

Чтобы агент выполнил одну команду, ему нередко дают доступ к целому окружению: файловой системе, сети, переменным среды и установленным credential helpers. Это удобно, но blast radius получается большой.

Можно добавить sandbox, allowlist команд и подтверждения опасных действий. Но это уже отдельная security-система поверх CLI. Сам факт, что команда запускается в терминале, не отвечает на вопросы «какие записи CRM видит этот пользователь?» или «имеет ли он право менять статус именно этой задачи?».

2. Секреты оказываются рядом с runtime агента

CLI часто получает токены из environment variables, dotfiles, keychain или локальной сессии пользователя. Для одного инженера это привычная модель. Для команды из десятков пользователей она создаёт операционную цену: секреты нужно раздать, обновлять, отзывать и искать при инциденте.

Если агент действует от имени сервиса с широким токеном, персональная ответственность теряется. Если каждому агенту выдают отдельные токены, растёт количество credential lifecycle. В обоих случаях нужен централизованный ответ на вопрос, кто и на каких правах выполнил действие.

3. Выход команды не всегда стабилен

Хороший CLI поддерживает --json, предсказуемые exit codes и обратную совместимость. Плохой возвращает таблицу для человека, смешивает служебные сообщения с данными и меняет формат между версиями. Модели приходится парсить текст и угадывать смысл ошибки.

Shell добавляет собственные риски: quoting, globbing, pipes, перенаправления и command injection. Для локального помощника это управляемо. Для автономного агента, который работает с недоверенными данными, цена ошибки выше.

4. Discovery и переносимость не гарантированы

Агент должен знать, какая утилита установлена, какой у неё version и как выполнен login. Один и тот же сценарий может работать на ноутбуке разработчика и ломаться в контейнере или удалённом runner. Команда вынуждена стандартизировать образы, версии и конфигурацию.

Плюсы MCP для AI-агентов

1. Структурированный контракт вместо угадывания

MCP tool описывает название операции и схему входных параметров, а при необходимости - схему результата. Клиент может обнаружить доступные возможности, а сервер - валидировать вызов. Для систем без хорошего CLI это серьёзное преимущество: не нужно учить агента особенностям каждого REST API или парсингу интерфейса для человека.

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

2. Инструмент можно сделать уже, чем системный доступ

Вместо универсального curl с широким токеном сервер может опубликовать конкретные операции: get_issue, add_mr_comment, search_documents. Чем уже tool, тем проще проверить параметры, ограничить результат и объяснить пользователю последствия.

Это не происходит автоматически. MCP-сервер с инструментом execute_any_sql остаётся широким и опасным. Но сам формат подталкивает проектировать осмысленные capability boundaries, а не отдавать агенту весь shell.

3. Удалённую авторизацию можно централизовать

Актуальная спецификация авторизации MCP определяет OAuth-based flow для HTTP transport, discovery authorization server и работу со scopes. Это позволяет отделить identity пользователя от секрета к downstream-системе и выдавать доступ через управляемую точку.

Для корпоративного сценария это сильный аргумент: новый агент получает разрешённые tools, а не копию токена от GitLab или CRM. Отзыв доступа и изменение политики происходят централизованно.

4. MCP лучше подходит для разных клиентов и пользователей

CLI хорош там, где есть терминал. Но не каждый агент работает на машине разработчика. AI-функция может жить в IDE, браузере, корпоративном чате или отдельном приложении. MCP даёт этим клиентам общий способ работать с инструментами без выдачи полноценного shell-доступа.

Минусы MCP для AI-агентов

1. Схемы tools расходуют контекст

Если host сразу показывает модели сотни инструментов, растут token cost и поверхность выбора. Агенту сложнее найти нужную операцию, а cache становится тяжелее. Плохо спроектированный MCP-каталог превращается в меню на триста страниц.

Лечится это не отказом от MCP как такового, а нормальной архитектурой: группировать инструменты по сценарию, скрывать недоступные tools, применять progressive disclosure, отдавать короткие описания и возвращать только нужные поля. Но эту работу кто-то должен сделать.

2. Появляется дополнительная инфраструктура

У MCP есть host, client, transport, server и upstream-система. Нужно следить за версиями протокола и SDK, timeouts, reconnect, schema validation, observability и совместимостью клиентов. CLI subprocess в локальной среде устроен проще.

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

3. MCP сам по себе не гарантирует безопасность

Это ключевой reality-check. Протокол предоставляет механизмы, но не заменяет security architecture. В MCP Security Best Practices описаны риски confused deputy, token passthrough, SSRF, session hijacking и компрометации локальных серверов. Там же рекомендуется least privilege, sandboxing локальных процессов и строгая проверка токенов.

Другими словами, MCP с широким scope, секретом в локальном конфиге и без аудита не становится безопасным только из-за JSON Schema. А небрежный локальный MCP-сервер может запускаться с теми же правами, что и клиент, и получить доступ к чувствительным файлам.

4. Композиция зависит от дизайна сервера

CLI позволяет агенту быстро собрать новый pipe. MCP-агент ограничен опубликованными tools. Если сервер возвращает слишком большой объект или не поддерживает нужный фильтр, клиент не всегда может обработать результат до попадания в контекст.

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

MCP vs CLI: таблица выбора

Критерий	CLI	MCP
Локальные файлы, git, build, tests	Обычно лучший выбор	Часто лишний слой
Композиция нескольких операций	Сильная сторона shell и pipes	Зависит от набора tools
Progressive disclosure	Естественно через `--help` и skills	Требует умного host и каталога
Структурированные параметры	Зависит от качества CLI	Встроены через schemas
Работа без терминала	Неудобна или невозможна	Подходит разным AI-hosts
Удалённые корпоративные системы	Требует CLI, API и credential setup	Естественный сценарий
Права конкретного пользователя	Нужен отдельный слой	Можно встроить в gateway/server
Секреты вне runtime агента	Требует дополнительной архитектуры	Реализуемо на серверной стороне
Централизованный аудит	Нужно строить отдельно	Удобно делать в единой точке вызова
Инфраструктурная сложность	Ниже для локального сценария	Выше из-за протокольного слоя

Когда выбирать CLI

CLI обычно выигрывает, если одновременно выполняются несколько условий:

агент работает в контролируемом sandbox рядом с кодом;
задача локальная: файлы, git, сборка, тесты, логи;
команда уже использует стабильный CLI с machine-readable output;
секреты не нужно размножать между множеством пользователей и сред;
результат удобно фильтровать и комбинировать shell-инструментами;
действие можно воспроизвести вручную по команде и exit code.

Практический пример - coding agent в ephemeral container. Ему нужен репозиторий, git, package manager и test runner. Заворачивать каждое чтение файла и запуск теста в удалённый MCP tool вряд ли имеет смысл. Здесь CLI - нормальный рабочий интерфейс.

Когда выбирать MCP

MCP обычно выигрывает, когда:

инструментом пользуются разные AI-клиенты;
агент работает с удалённой системой, у которой нет зрелого CLI;
доступ зависит от identity пользователя, команды или проекта;
секреты должны оставаться вне ноутбука и runtime агента;
нужны централизованные rate limits, policy checks и audit trail;
операции должны быть уже, чем произвольный shell или HTTP-запрос;
каталог возможностей меняется и должен обнаруживаться динамически.

Пример - агент, который от имени менеджера читает задачи, а от имени разработчика комментирует merge request. Тут важны не только команды. Нужно проверить identity, права на конкретный проект, разрешённое действие и записать, кто инициировал вызов. MCP подходит как контракт, но enforcement всё равно должен находиться на серверной стороне.

Почему на практике нужен гибрид MCP + CLI

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

локальная работа агента → CLI в sandbox
корпоративные действия → управляемый MCP gateway → внутренние системы

CLI остаётся внутри контролируемой рабочей среды: агент читает код, запускает тесты, форматирует данные и собирает артефакты. Для действий во внешних системах он обращается к узким MCP tools. Gateway проверяет пользователя и policy, подставляет серверный секрет, вызывает upstream API и записывает аудит.

Именно такую границу строит Codenik. Он не пытается запретить CLI или сделать MCP-обёртку над каждой локальной командой. Codenik работает как управляемый слой доступа между AI-агентом и корпоративными системами: отбирает разрешённые инструменты, держит секреты на серверной стороне, применяет права и сохраняет журнал вызовов.

Это заодно снижает контекстную цену MCP. Агенту не нужно видеть все инструменты компании. Codenik может отдать короткий набор tools для конкретного пользователя и сценария. Подробнее про эту модель - в статьях «Что такое MCP и зачем он нужен» и «MCP без локальных секретов».

Пять вопросов перед выбором

Чтобы не переспать с мыслью неделю, можно начать с пяти вопросов:

Где выполняется задача? Рядом с локальным кодом - аргумент за CLI. В удалённой корпоративной системе - за MCP.
Кто является субъектом доступа? Один владелец sandbox или разные сотрудники с разными правами?
Где лежат секреты? В runtime агента или в управляемой серверной инфраструктуре?
Нужно ли восстановить цепочку действий? Команды в локальном логе могут быть достаточны для разработки, но не для корпоративного аудита.
Сколько клиентов используют интеграцию? Для одного coding agent CLI может окупаться сразу. Для нескольких IDE, чатов и внутренних приложений общий MCP-контракт снижает дублирование.

Это не теоретический выбор на годы. Это гипотеза, которую можно проверить на одном сценарии. Возьмите реальную операцию - например, чтение issue и комментарий к MR - и сравните время интеграции, объём контекста, failure modes, схему доступа и качество аудита. Только практика покажет цену именно в вашей инфраструктуре.

Короткий вывод

CLI - сильный интерфейс для локальной инженерной работы: он компактный, гибкий, знакомый модели и отлично компонуется. Его минусы начинаются там, где shell-доступ слишком широк, секреты размножаются, а действия нужно связывать с конкретным пользователем.

MCP - сильный контракт для удалённых инструментов и разных AI-клиентов: он даёт discovery, schemas и стандартный способ вызова. Его минусы - дополнительная инфраструктура, расход контекста при плохом каталоге и ложное ощущение безопасности без policy enforcement.

Поэтому ответ на «MCP или CLI» чаще всего такой: CLI для работы внутри sandbox, MCP для управляемого доступа наружу. А задача номер один для компании - не выбрать модный интерфейс, а провести правильную границу прав, секретов и ответственности.