Почему MCP всегда была плохой идеей

Недавно я посетил целодневное мероприятие, посвященное последним и лучшим достижениям в мире MCP. Хотя все докладчики были замечательны и казались увлеченными своей работой, я честно устал от MCP. Это ужасный протокол, созданный для времени, когда LLM не были такими умными, и мы уже выросли из него.

Краткая история

MCP был выпущен в ноябре 2024 года командой Anthropic как протокол, предназначенный для помощи агентам в подключении к внешним сервисам и источникам данных. Модели того времени все еще были относительно примитивными, по крайней мере, по сравнению с тем, что у нас есть сейчас. У нас даже не было Claude Code тогда, и общегоназначенные агентные рабочие процессы были гораздо менее надежными. Пользователи начали видеть полезность предоставления своим ИИ-моделям доступа к внешним сервисам. Это открыло уровень производительности, которого мы не видели раньше. Мы увидели взрыв в принятии MCP, совпавший с похожим, если не более взрывным, ростом принятия LLM во всей экономике. Со временем MCP продолжал развиваться под управлением Anthropic, прежде чем в конечном итоге был передан в Agentic AI Foundation под эгидой Linux Foundation в 2025 году.

Промышленный комплекс MCP

С огромным ростом принятия пользователи начали добавлять множество серверов MCP в свои настройки и начали сталкиваться с проблемой раздувания контекста. Каждый сервер поставлялся с множеством инструментов, каждый со своей схемой, что начало перегружать контекст всех этих моделей. Разработчики Harness нашли множество уловок для обхода этого, включая универсальные паттерны поиска/выполнения, которые теперь предлагают платформы вроде Composio, Mint MCP и Pipedream. Все они эффективно решают проблему наличия одного места для хранения учетных данных для различных внешних сервисов и предоставления вашему агенту минимального набора инструментов (для уменьшения раздувания контекста), которые он может использовать для доступа к ним. Я хочу прояснить, что это хорошая вещь на краткосрочной перспективе.

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

Удивление, удивление, большие лаборатории были правы

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

LLM стали настолько хороши в этом, что даже Cloudflare запустил Code Mode — лучший способ использовать MCP, заставляя LLM составлять различные вызовы в скрипты, которые можно выполнять в песочнице. Но еще лучше того, LLM разобрались, как использовать команду --help для обнаружения CLI, поэтому им больше не нужны серверы MCP для доступа ко многим сервисам, доступным через документированные API или CLI. Большинство удаленных серверов MCP в конечном счете оборачивают API, которые уже существуют.

Что теперь?

Мы удаляем большинство наших серверов MCP. Вот и все. Агенты с доступом к терминалу могут заменить большинство серверов MCP и часто являются более способными.

Все еще есть некоторые проблемы, например, CLI возвращают машиночитаемые ответы (JSON/XML и т.д.), которые склонны быть очень многословными и тяжелыми по использованию токенов, но у нас есть способы это исправить. Большая часть альтернативы уже существует: документированные HTTP API, стандартное согласование контента и зрелые механизмы аутентификации. Мы должны начать стандартизировать то, как агенты используют HTTP API напрямую. Например, клиенты агентов могли бы прикреплять заголовки для идентификации себя как агентов, а серверы могли бы автоматически отправлять им данные ответа в виде Markdown или текста вместо HTML или....