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

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

MCP был выпущен в ноябре 2024 года командой Anthropic как протокол для подключения агентов к внешним сервисам и источникам данных.¹ Модели того времени были ещё примитивны по сравнению с тем, что есть сейчас. Даже Claude Code ещё не существовал, а универсальные агентские рабочие процессы были намного менее надежны.

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

Со временем MCP продолжала развиваться под руководством Anthropic, прежде чем в 2025 году была передана в Agentic AI Foundation под эгидой Linux Foundation.²

Индустриальный комплекс MCP

С бурным ростом адопции пользователи начали добавлять в свои системы множество MCP-серверов и столкнулись с проблемой раздутия контекста. Каждый сервер приходил с несколькими инструментами, каждый со своей схемой, что перегружало контекст моделей. Разработчики нашли множество решений, включая паттерны с обобщённым поиском и выполнением, которые сейчас предлагают платформы вроде Composio, MintMCP и 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 или многословного JSON.

Реальные примеры

1. Заголовок Accept Markdown

   Растущее число LLM-дружественных серверов, особенно сайты с большим объёмом текста, таких как сайты с документацией, поддерживают заголовок Accept: text/markdown. Эти серверы могут автоматически отправлять визуализированный файл Markdown вместо обычного HTML-ответа. Сам тип носителя стандартизирован, и его использование для согласования контента, ориентированного на агентов, набирает популярность.

2. Сайты документации, использующие заголовок Accept-Language

   Недавно инженер из Vercel призвал разработчиков отправлять предпочитаемый язык программирования, чтобы сайты документации могли предоставлять более конкретные примеры. Например, указание Python может дать приоритет документации по Python SDK вместо чего-то универсального. Это так понравилось Tobi Lutke из Shopify, что теперь это включено в Shopify docs.

Malte Ubl (@cramforce): Request to harnesses: I love that you now send "Accept: text/markdown". Next thing is: Put the programming language you prefer into the Accept-Language header.

Tobi Lutke (@tobi): Great idea. Will support this on Shopify docs.

Заключение

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