MCP is Deprecated

Я считаю, что стандарт MCP должен быть deprecated и его использование должно быть прекращено. Многие просили меня объяснить, почему Builder не поддерживает MCP и почему я так против них. Причин несколько - давайте разберём все по очереди.

Причина 1: Отсутствие гибкости

Первая и главная причина - весь функционал, который MCP предоставляет, исключительно поставляется модели в виде инструментов (тулов), которые она может вызывать. Это было разработано ещё в 2024 году, в эпоху, когда люди даже не знали, что агентов можно запускать с доступом к Bash, к CLI, к командной строке. Поэтому тулы были единственным способом расширить функциональность агента - они поддерживались в API.

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

Почему? Потому что агенты очень хорошо работают с командной строкой. Они пользуются командами круче любого линуксоида, умеют писать и выполнять любые скрипты. Поэтому им ничего не стоит написать любую нужную функциональность, используя удобный CLI-интерфейс или даже API напрямую.

Например, если вы подключаете GitHub MCP, ваш агент получает в контекст инструменты, выдачу которых он никак не может постобработать и не может создать переиспользуемые скрипты для повторяющихся действий. GitHub MCP будет выдавать огромные JSON на десятки тысяч токенов в контекст агенту при каждом вызове инструмента - без возможности прогнать через jq для фильтрации, распарсить и убрать мусорные escape-символы, записать в файл и обработать кусками, запустить скрипты или написать собственную утилиту для удобного повторного использования. Да даже скомпоновать несколько вызовов стоит вам последовательных повторных запросов к API.

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

Причина 2: Загрязнение контекста и отсутствие прогрессивного раскрытия

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

Мы давно перешли из эпохи промпт-инжиниринга в эпоху контекстного инжиниринга и уже в эпоху harness-инжиниринга. А MCP всё ещё стоят на месте из-за фундаментально кривого дизайна, в котором нет никакой возможности прогрессивного раскрытия информации агенту.

Если вашему агенту нужно оставить комментарий под тикетом на GitHub, он не может просто посмотреть формат запроса исключительно для этого действия. Помимо нужного инструмента, он получает 45 других, которые занимают 50 000 токенов контекста - просто потому что он хотел оставить комментарий. И у вас нет возможности отключить лишние тулы MCP. Это фундаментальный косяк в архитектуре: если вы начинаете сессию и понимаете, что какой-то инструмент агенту не нужен, вы не можете его просто выключить - это приведёт к полной инвалидации кэшей. Итог: 50 000 токенов контекста потрачены впустую.

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

Представьте, что вы как человек, каждый раз, когда хотите открутить следующий болтик, должны сначала заново решить и найти нужный из 50 инструментов на балконе. Абсолютно то же самое происходит с агентами. Если у вас 50 тулов в MCP, внимание модели распыляется на все 50 инструментов, и на каждый уходит какая-то его часть. Образно говоря, модель проходит по всем инструментам как по списку: нужен ли мне create_github_comment? нужен ли мне search_github_issues? нужен ли мне edit_github_pull_request_description прямо сейчас? - и так до последнего тула в контексте. И это происходит не перед вызовом нужного инструмента, а буквально на каждый ход работы агента, даже если он занимается чем-то другим.

Кто-то скажет: “Но Anthropic же сделали tool search - теперь Claude может узнавать о наличии тулов через поиск”. Во-первых, это не решает проблему полностью: Claude всё ещё получает список всех тулов всех MCP в контекст на старте, пусть и в более минималистичном формате. Это просто уменьшает расход контекста, но не снимает необходимость принимать решение - Claude всё ещё видит create_github_issue, просто теперь ему нужно сделать дополнительный вызов get_tool_schema, чтобы получить детали. В каком-то смысле это делает ситуацию даже хуже. Во-вторых, это просто костыльное решение: люди пожаловались, и Anthropic сделали первое, что пришло в голову. Это не решает проблему прогрессивного раскрытия информации на корню, а лечит симптом, зато теперь агенту нужен лишний ход чтобы узнать описания инструментов.

Отдельно стоит упомянуть, что MCP по своему стандарту обязаны вместе с инструментами предоставлять контекст их использования - зачем они нужны, когда и как их использовать. И положить это некуда, кроме как в description тула или в отдельный инструмент, который тратит ходы агента. Следовательно, вы даже не знаете, что именно добавляете, когда подключаете MCP. Вы можете подключить MCP, который будет инструктировать вашу модель никогда не делать коммиты или слить ваши credentials на сторонний сервер - и модель это выполнит, потому что всё это попадает в системный блок и имеет практически тот же авторитет, что и системный промпт. Именно поэтому так распространены вредоносные MCP: как только пользователь его включает, атакующий может делать с моделью всё что угодно.

В сравнении с CLI агент получает инструкции только тогда, когда вызывает help команды. Если агенту нужно оставить комментарий на GitHub, он вызовет gh --help, получит нужное описание прямо перед использованием - и это никак не влияет на сессию до тех пор, пока GitHub CLI агенту не понадобился. Инструкции раскрываются непосредственно перед использованием инструмента, как и должно быть - ведь внимание модели значительно сильнее сосредоточено на конце контекстного окна. Агент постепенно “забывает” инструкции из начала контекста. Поэтому с MCP у вас будет постоянная деградация качества использования инструментов, тогда как с CLI агент получает инструкции позже - что повышает длительность их соблюдения.

Причина 3: Странная архитектура и нестабильный стандарт

Поговорим об архитектуре MCP. Во-первых, если MCP работает локально, он обязан поднимать сервер, к которому агенты обращаются через STDIO. Непонятно, почему нельзя было сделать их stateless и хранить credentials авторизации в другом месте. Почему именно STDIO-транспорт - по сути хак для передачи данных через терминальный ввод-вывод - а не любой другой способ?

Стандарт MCP начинался с SSE-событий, а в начале 2025 года авторы абсолютно всех MCP должны были мигрировать на HTTP-транспорт и переделывать свои реализации. Если с CLI вы можете рассчитывать на десятилетия стабильности - терминалы никуда не уходят - то с MCP каждая смена стандарта влечёт за собой очередной рефакторинг.

И угадайте, кто разработал этот стандарт практически в одиночку? Anthropic. Вы полностью зависите в разработке инструментария для ваших агентов от желаний одной компании. В то время как CLI - это семидесятилетний стандарт работы с терминалами.

CLI как альтернатива

Описывая все эти недостатки, я уже начал упоминать CLI и bash-инструментарий - и не случайно. Для агентов с доступом к файловой системе это сейчас лучший вариант, по крайней мере, пока не появится что-то лучше.

CLI-интерфейсы были и будут всегда. Практически весь нужный функционал уже доступен через консоль: агенты с доступом к терминалу умеют автоматизировать действия на компьютере, писать код, деплоить проекты, управлять авторизацией в Google Cloud, Amazon, DevOps, конвертировать медиафайлы в любые форматы, редактировать документы - всё это исключительно через консольные команды. Это ярко иллюстрирует бум популярности OpenClaw: люди поняли, что агент с доступом к командной строке и широким набором привилегий способен выполнять огромное количество полезной работы.

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

Контраргументы к CLI

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

Это всё ещё сырые решения, поэтому единственный юзкейс, в котором MCP не получится не использовать прямо сейчас, - это агенты без доступа к файловой системе и без другого способа взаимодействия со сторонним ресурсом.

Но MCP в любом случае - это ленивый хак вместо настоящего harness. Мы занимаемся harness-инжинирингом, и первое правило хорошего агента - это уздечка, в которой он выполняет свою работу. Если вы просто подключили MCP с 50 тулами для всевозможных задач, никак не пытаясь специализировать агента или настраивать его окружение, производительность на сложных задачах будет соответствующая. Подумайте: может, вы подключаете MCP просто чтобы сэкономить время и не заниматься дизайном настоящего harness’а?

Про авторизацию

Некоторые говорят: “А как же авторизация в MCP?”. Дело в том, что стандарт MCP особо и не помогает в авторизации. STDIO-серверы, которые выполняются локально, не поддерживали авторизацию вообще, когда я последний раз проверял, - так что вы не можете сделать их безопасными. Удалённые MCP поддерживают OAuth, что в принципе хороший стандарт. Но что из этого не поддерживает CLI?

С помощью CLI вы можете безопасно хранить ключи в Keychain вашей операционной системы, и CLI получает к ним доступ при вызове соответствующих команд. Вам не нужно поднимать отдельный сервер, не нужна интеграция в ваш harness для правильного хранения ключей - каждый CLI сам отвечает за хранение своих авторизационных данных.

В стандарте MCP Anthropic прописали, что harness должен заниматься хранением и предоставлением данных для авторизации MCP - задачей, которая ему совершенно не свойственна. Я считаю, это неправильное разделение зон ответственности. Если CLI подразумевает авторизацию, то CLI и должен отвечать за неё от А до Я, а не делегировать это на harness, который непонятно как эту авторизацию реализует. Некоторые агенты реализовывали авторизацию через банальное хранение всех ключей в домашней директории компьютера - и вы даже не знали об этом, потому что через harness это выглядело прозрачно. Если CLI плохо авторизуется, вы можете изолировать этот CLI. Если целый харнесс, что тогда будете делать?

Документация и промпты в MCP

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

Это только загоняет вас в закрытый сад. С CLI у вас всегда есть команда --help, у каждой субкоманды есть возможность добавить описание. Как автор и MCP, и CLI, я знаю, насколько тяжело поддерживать разрозненные локации для документации и насколько много дыр в безопасности у стандарта MCP.

Что делать вместо MCP?

Допустим, вы согласны, что MCP должен быть deprecated, но у вас есть 25 MCP без эквивалентных CLI. Как работать с Figma, например?

Решение уже есть. Провайдеры активно разрабатывают CLI для своих популярных инструментов. Как временное решение я рекомендую использовать инструменты для портирования MCP в CLI, например mcporter.

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