Спор про MCP: за что ругают протокол и что считать

Публикация с вопросом «а не был ли MCP плохой идеей с самого начала» собрала на Hacker News больше трёхсот комментариев и разделила аудиторию надвое. Критики считают, что протокол раздувает контекст и сжигает токены там, где хватило бы обычной программы. Защитники отвечают, что он даёт не удобство, а контроль доступа, выдачу прав и аудит. Обе стороны правы — просто говорят о разных сценариях, и разобраться, какой из них ваш, можно за один вечер по журналу.

Разберём аргументы обеих сторон и, главное, покажем, как перевести этот спор в цифру, которую видно в вашем счёте.

Что такое MCP в двух предложениях

Протокол, по которому агент узнаёт, какие инструменты у него есть, и вызывает их. Технически — обмен по стандартной схеме поверх HTTP, с описанием доступных операций, форматом вызова и отдельной частью, отвечающей за выдачу доступов.

Практически это означает, что вместо написанного вами кода интеграции агент получает список инструментов и сам решает, какой вызвать. Как подключить такой сервер, мы разбирали в материале MCP-сервер: как подключить.

Аргументы критиков

Четыре претензии, которые звучат чаще остальных.

Описания инструментов едут в каждый вызов. Схема каждого инструмента — это текст, и он попадает в контекст при каждом обращении к модели, а не один раз. На нескольких подключённых серверах объём становится заметным.

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

Командная строка часто справляется лучше. У популярных утилит есть представление в обучающих данных: модель знает их синтаксис и пользуется уверенно. Самописный инструмент приходится описывать с нуля, и описание тоже стоит токенов.

Отдельный слой ради синтаксиса. Часть участников обсуждения формулирует резко: получается прослойка, которая переводит уже существующий интерфейс в другой формат, и её надо где-то держать и обслуживать.

Аргументы защитников

Здесь показательно, что возражения идут не про удобство, а про контроль.

Список того, что агенту доступно. Через протокол задаётся, к каким внешним сервисам агент может обращаться, а к каким нет. С командной строкой и доступом к оболочке граница размывается.

Доступы без выдачи ключей агенту. Аутентификация устроена так, что агенту не нужно видеть сам ключ. Это принципиально для сценариев, где агент работает с чужими данными.

Журнал обращений. Централизованный аудит того, что агент вызывал и когда, — требование, которое в команде появляется быстро, а в одиночной разработке не возникает никогда.

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

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

Где проходит настоящая граница

Не между «хорошо» и «плохо», а между сценариями.

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

Что изменилось в самом протоколе

Отдельная линия обсуждения, которая объясняет, почему старые претензии частично устарели.

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

Там же отдельно выделяют удачную часть: механизм выдачи доступов называют полезным сам по себе, безотносительно остального. Формулировка одного из участников — что это чистый плюс для любого публичного API, а не только для агентов.

Вывод отсюда практический: если вы читали разбор претензий годичной давности и на его основании решили, что протокол вам не нужен, решение стоит перепроверить. Часть аргументов относилась к тому, чего уже нет.

Три вопроса, которые решают за вас

Если спорить не хочется, достаточно ответить на три вопроса про свой случай.

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

Нужен ли журнал того, что вызывал агент? В одиночной работе вопрос не возникает. В команде он возникает в первый же месяц, обычно после первого странного действия агента.

Детерминированная ли операция? Если шаг всегда один и тот же и не требует решения, его дешевле делать кодом. Агент нужен там, где надо выбрать, а не там, где надо выполнить. Про это же — в материале какие задачи отдать нейросети первыми.

Как перевести спор в цифру

Самое практичное, что можно сделать после прочтения любой стороны, — посмотреть на свой журнал.

Шаг первый: посчитайте служебную часть первого вызова. Сколько токенов уходит до того, как в промпте появится задача пользователя. Туда входят системные инструкции и все описания инструментов.

Шаг второй: сравните с полезной частью. Если служебное больше полезного в разы — у вас есть что оптимизировать независимо от исхода спора.

Шаг третий: посчитайте на месяц. Служебная часть умножается на число вызовов, а не на число задач. В агентном сценарии на одну задачу приходится десяток ходов.

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

Измерять это удобнее там, где расход виден по каждому запросу: KeyDealer даёт один ключ на каталог из 57 позиций, 44 из которых доступны сейчас, с оплатой российской картой в рублях и ставками от 1 ₽ за миллион токенов. Токены входа и выхода в журнале лежат раздельно — то есть служебную часть видно без дополнительных замеров. Сама механика служебного объёма разобрана в материале служебный контекст маршрута.

Компромисс, к которому приходят

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

Цена этого решения честная: контроль доступа и аудит переезжают на уровень приложения и окружения. Для одного разработчика это не потеря, для команды — задача, которую придётся решать отдельно.

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

Чего мы не утверждаем

Три оговорки.

Мы не подводим итог спору. Это обсуждение в публичном форуме, а не исследование. Мы пересказываем позиции сторон как позиции, а не как установленные факты.

Мы не приводим чисел расхода. Конкретных замеров в обсуждении нет, а придумывать проценты мы не станем. Цифра есть только одна и она ваша — в вашем журнале.

Мы не даём рекомендации «отключить всё». У протокола есть сценарии, где он закрывает задачи, которые иначе придётся решать самому и хуже. Речь о том, чтобы считать, а не о том, чтобы отказываться.

Что держать в голове

Первое. Спор идёт не о протоколе, а о сценарии. Прежде чем принимать чью-то сторону, определите, в каком сценарии находитесь вы: одиночная работа, команда или продукт с чужими данными.

Второе. Всё, что попадает в контекст на каждом вызове, вы оплачиваете на каждом вызове. Описания инструментов — не исключение, и это единственная часть спора, которую можно проверить числом.

Третье. Самая дешёвая оптимизация — убрать неиспользуемое. Посмотрите за месяц, какие инструменты агент не вызвал ни разу, и отключите их: это не архитектурное решение, а уборка. Что мы за проект — на странице о проекте, ключ заводится на keydealer.ru/login.