Чем MCP-сервер отличается от самой обычной CLI с флагом --help? По мнению Джеффри Хантли, ничем. В своём разборе он отвечает на этот вопрос коротко: «Чем MCP-сервер на самом деле отличается от самой обычной CLI с флагом --help? По-моему, ничем». Дальше идёт вывод, который и стал поводом для обсуждения: CLI, написанная с прицелом на агентов, закрывает те же задачи, и ничего нового изобретать не нужно (перевод материала на Habr).
Если тезис верен хотя бы наполовину, он меняет приоритеты у всех, кто делает инструменты для разработчиков. Вместо того чтобы первым делом поднимать MCP-сервер, публиковать его в реестрах и объяснять пользователям, как подключить пакет скиллов, можно вложиться в --help и документацию. Хантли идёт дальше и делит рынок на S-тир и F-тир, где прописку определяют веса моделей.
Ниже разбираем, что именно он утверждает, как проверить свою CLI на агентопригодность, что такое ASEO и где у подхода слабые места. Это рабочая гипотеза, а не доказанный закон. Дискуссия вокруг неё не ограничилась одним постом: в тему писал и Адам Уотан.
Суть спора: MCP-сервер против CLI с --help
Что такое MCP и почему его обычно предлагают агентам
MCP (Model Context Protocol) описывает, как агент подключается к внешним инструментам через отдельный сервер. Вместо того чтобы учить модель работать с конкретным API, вы поднимаете сервер, который объявляет набор инструментов, а агент вызывает их по схеме. Совет «сделайте MCP-сервер» звучит почти в каждом гайде по подключению продукта к Claude, ChatGPT или другому клиенту.
Обратная сторона: сервер нужно написать, протестировать, опубликовать, поддерживать и объяснить пользователю, как его подключить. Иногда к этому добавляется установка пакета скиллов. Для человека, который просто хочет, чтобы его инструмент работал под управлением агента, порог входа получается заметным.
Почему --help может заменить MCP-сервер
Аргумент Хантли простой: у большинства инструментов для разработчиков уже есть CLI. Агенту не нужен отдельный слой-обёртка, если он может выполнить tool --help, прочитать список подкоманд, вызвать нужную, посмотреть вывод и скорректировать следующий шаг. MCP-сервер в такой схеме часто дублирует то, что и так доступно из терминала.
Условие одно, и оно жёсткое: --help должен быть проработан. Автогенерённая простыня со списком флагов без примеров агенту не поможет. Работает это только тогда, когда из справки понятно, какие есть команды, что каждая делает, какие параметры принимает и в каком порядке их вызывать.
Разбор пет-проекта на Java с Claude Code показывает, как CLI-сессии агента становятся основой рабочего процесса: оркестратор запускает агента в терминале, а тот работает с git и файлами обычными командами. MCP там применяется точечно, для конкретных задач вроде end-to-end тестов с chrome-devtools, и не нужен как обязательный слой для всего остального.
S-тир и F-тир: кто выигрывает и почему это решают веса моделей
Хантли делит компании, которые делают инструменты для разработчиков, на два сорта: S-тир и F-тир. «Первые выигрывают, вторые проигрывают. А в какой тир вы попадёте, целиком решают веса моделей». Компания из S-тира уже «сидит» в весах: модель знает её CLI по обучающим данным и работает с ней без скиллов и MCP.
F-тир - это те, кого в весах нет. Им приходится уговаривать пользователей скачать пакет скиллов или поставить саму CLI. Хантли называет это лишней вознёй, которой у S-тира нет вовсе (источник).
Тест на S-тир: промпт с gh CLI
Проверка, по Хантли, укладывается в один промпт: «Use the GH cli to create a repository, commit the changes, push to origin, set the repository to public and update the repository description». Если модель выполняет всю цепочку через gh без скиллов и MCP, вы в S-тире.
Тест легко адаптировать под свой инструмент: дайте агенту задачу из нескольких шагов, требующую нескольких вызовов CLI, и посмотрите, справляется ли он, читая только --help. Ограничение, о котором стоит сказать прямо: результат на локальной модели может отличаться от облачной. Умение разбираться в справке зависит от конкретных весов, и тестировать нужно на тех моделях, с которыми работают ваши пользователи.
Почему GitHub в S-тире, а большинство молодых компаний остаётся в F-тире
GitHub попал в S-тир не из-за любви сообщества. Ругать его можно сколько угодно, но модели умеют с ним работать, потому что это умение зашито прямо в веса. Никакие скиллы и MCP им не нужны, хватает обычной CLI. Молодой компании в весах нет, и модель просто не знает её команд.
Отсюда вывод, который стоит проговорить отдельно: прописку в тире решает присутствие в весах, а не качество инструмента. Посредственная CLI от компании в S-тире может работать лучше, чем отличная CLI от компании, которой в весах нет. Для разработчика это меняет план действий: сначала стоит позаботиться о том, чтобы о вашем инструменте знали модели, и только потом сравнивать фичи с конкурентами.
В русскоязычном контексте это особенно заметно на локальных агентах. Скиллы, паки и MCP-серверы приходится ставить вручную на свою машину, и это дополнительная возня. Про то, как устроен современный опенсорс вокруг скиллов и агентов, мы разбирали в материале про Hacktoberfest 2026: участникам предлагают писать skills.md, собирать опенсорсных агентов и дообучать open-weight-модели, а не только присылать пул-реквесты.
Путь в S-тир для молодой компании: пошаговый план Хантли
План Хантли укладывается в пять шагов, и они идут по возрастанию стоимости: от правки текста справки до переговоров с лабораториями. Каждый следующий шаг имеет смысл после того, как сделан предыдущий.
Шаг 1: сделать качественную CLI и вылизывать --help
Сначала сделайте по-настоящему хорошую CLI и вылизывайте её --help. Критерий Хантли формулирует так: смотрите, доходит ли модель до результата, просто читая --help по всем подкомандам (перевод).
На практике это означает, что справка должна быть самодостаточной. Из неё агент понимает, какие есть команды, какие у них параметры, что они делают и в каком порядке их вызывать. Если у вас CLI для работы с API, в --help стоит показать, как агенту аутентифицироваться, как обрабатывать ошибки и как проверить результат.
Шаг 2: крутить формулировки и считать вызовы инструментов
Дальше крутите формулировки и оставляйте те, с которыми модели хватает минимума вызовов инструментов. Метрика простая: число вызовов CLI до достижения результата. Меньше вызовов - лучше справка.
Это критерий не про красоту текста, а про скорость, с которой агент доходит до цели. Представим, что на задачу «создать репозиторий и сделать его публичным» агент тратит десять вызовов, а после правки --help - три. Разницу можно замерить и сравнить версии справки между собой.
Шаг 3: автоматизировать проверку циклом
Всё это можно автоматизировать, хоть простым циклом, хоть циклом автоисследования, говорит Хантли. То есть можно написать скрипт, который прогоняет модель по типовым задачам, считает число вызовов и выдаёт отчёт. Тогда улучшение --help превращается в регулярную процедуру, а не в ручной прогон каждый раз.
Для локальных моделей это особенно удобно: цикл можно гонять на своей машине без затрат на API. Конкретные фреймворки Хантли не называет, так что собирать обвязку придётся своими руками.
Шаг 4: выложить документацию и заняться ASEO
Когда фундамент готов, выкладывайте документацию к CLI в открытый доступ и займитесь ASEO (Agentic Search Engine Optimization), то есть SEO для агентов, под их web_search_tool. Цель - чтобы агент находил всё нужное за один вызов веб-поиска. Если ему приходится блуждать по вашей документации, значит, ещё есть что допиливать.
Что это означает практически. Документация пишется под машину: конкретные команды для типовых сценариев, ясные заголовки, готовые примеры, чтобы поисковый инструмент агента вытащил нужный фрагмент сразу. Рассуждения общего плана и приглашения «узнать больше» тут работают против вас. Если у вас CLI для деплоя, на странице должны лежать команды для типовых сценариев, а не абстрактное описание философии продукта.
Шаг 5: коммерческая сделка с лабораториями
Финальный шаг - коммерческая сделка с лабораториями. Может, у вас с ними и так есть контракт на инференс. Тогда добивайтесь, чтобы документацию вашей CLI включили в следующий прогон обучения. После этого компания переходит в S-тир, и пользователям не придётся ставить пакеты скиллов, настраивать MCP-сервер и возиться со всей этой ерундой.
Это переговорный процесс, а не техническая задача. Деталей Хантли не приводит: ни условий, ни сроков, ни размера сделки. Для небольших команд шаг может оказаться недоступным, и это стоит держать в голове, планируя бюджет.
Как проверить свою CLI на агентопригодность: практический чек-лист
Проверка строится на повторяемом цикле, а не на разовом прогоне. Порядок действий такой:
- Дайте агенту задачу из нескольких шагов и проверьте, справляется ли он, читая только
--help. - Посчитайте число вызовов до результата.
- Пройдитесь по всем подкомандам и убедитесь, что справка по каждой даёт достаточно информации.
- Уберите из
--helpвсё, что не помогает агенту: маркетинговые описания, общие слова. - Добавьте примеры вызовов для типовых сценариев.
- Автоматизируйте прогон циклом.
- Выложите документацию в открытый доступ и проверьте, находит ли агент нужное за один вызов веб-поиска.
Метрика: число вызовов инструментов до результата
Ключевой показатель - число вызовов до результата. Возьмём задачу из теста Хантли: создать репозиторий, закоммитить изменения, запушить, сделать репозиторий публичным и обновить описание. Если агент проходит цепочку за пять вызовов, справка справляется. Если за пятнадцать, есть что улучшать. Цифры здесь условные, важен принцип: замеряйте до и после правок --help, иначе эффект от изменений не увидите.
Типичные ошибки в --help, которые мешают агенту
- Автогенерённый
--helpбез примеров: агент видит флаги, но не видит сценариев. - Нет описания типовых сценариев, и из справки непонятно, с чего начинать.
- Непонятные имена флагов и подкоманд, по которым нельзя догадаться о назначении.
- Нет подсказок по ошибкам: агент не понимает, что делать после неудачного вызова.
- Слишком длинный текст, в котором нужное тонет.
- Маркетинговые описания и общие слова на месте конкретных команд.
Ориентир простой: справка пишется для агента, а агенту нужны команды, примеры и порядок действий. Паттерн вызовов «команда, вывод, следующая команда» должен читаться из справки без догадок.
Ограничения подхода: когда MCP всё ещё нужен
Подход завязан на веса моделей, и это его главная уязвимость. Слабые места выглядят так:
- Зависимость от расписания обучения лабораторий.
- Невозможность быстрых итераций: вы обновили CLI, а в весах осталась старая версия.
- Риск устаревания документации, которая попала в веса.
- Коммерческая сделка может оказаться недоступной для небольших команд.
- Инструменты со сложным состоянием или постоянным соединением плохо ложатся на CLI.
Зависимость от лабораторий и расписания обучения
Включение документации в прогон обучения решается коммерчески и организационно. Лаборатории обучают модели по своему расписанию, и даже при наличии договорённости результат появится не сразу: попадание в веса измеряется месяцами, а то и годами. Для молодой компании это барьер, который не обойти одной только технической работой.
Альтернатива - продолжать улучшать CLI и ASEO, чтобы агент находил нужное через веб-поиск, даже если инструмента в весах пока нет. Этот путь медленнее, зато не зависит от чужого графика обучения.
Когда MCP-сервер всё ещё оправдан
Хантли не утверждает, что MCP не нужен вообще. Он говорит, что для многих задач достаточно CLI с хорошим --help. Случаи, где MCP остаётся оправданным:
- инструмент требует постоянного соединения или сложной аутентификации;
- он работает с состоянием, которое неудобно выражать через серию команд;
- нужен доступ к данным, которые через CLI не отдаются;
- MCP-сервер уже есть, и им пользуются.
Разбор Later Bender показывает, зачем MCP-слой бывает нужен: проект хранит состояние между чатами, моделями и агентами через задачи, заметки, runbook'и, временные среды и подключается к разным моделям по MCP. Такое состояние одним --help не передать. Выбор между MCP и CLI - инженерное решение, а не вопрос веры.
Что это значит для разработчиков инструментов на практике
Стоит ли вкладываться в MCP-сервер
Логика такая: MCP-сервер оправдан, если инструмент сложный, держит состояние или требует постоянного соединения, либо если у вас уже есть пользователи, которые им пользуются. В остальных случаях начинайте с CLI и --help. Это порядок работ: сначала дешёвый слой, потом дорогой.
Сравните издержки. CLI чаще всего уже есть у продукта, а правка справки занимает часы. MCP-сервер требует написать код, решить, сколько инструментов открывать и какие из них доступны анонимно, настроить аутентификацию, опубликовать сервер в реестрах и поддерживать его. Именно аутентификация и публикация обычно съедают основное время, а не сам код вызова.
Как связать это с локальными LLM и автоматизацией
Для локальных агентов тезис Хантли особенно практичен. Ставить MCP-серверы и пакеты скиллов на домашнюю машину - та самая возня: зависимости, конфиги, обновления. Если у CLI хороший --help, локальный агент работает с ней напрямую, без дополнительной инфраструктуры.
Ограничение то же: результаты на локальных моделях отличаются от облачных. Слабые модели хуже разбираются в справке и делают больше вызовов, так что проверять надо на тех весах, с которыми работают пользователи. Пример локального агентского контура с машинной проверкой фаз разобран в материале про Qwen 27B на двух GPU: агент работает через файловую память и мелкие шаги, а человек остаётся в контуре проверки.
Практический вывод для разработчика инструмента: прежде чем поднимать MCP-сервер и просить пользователей ставить скиллы, проверьте, хватает ли вашей CLI и её справки. Прогоните агента по типовым задачам, посчитайте вызовы, поправьте --help, выложите документацию и оцените, находит ли агент нужное за один поисковый запрос. MCP оставляйте для случаев, где без него действительно не обойтись.