MCP (Model Context Protocol) стал символом простоты: один универсальный коннектор, чтобы подключить агента к почте, календарю, CRM или Slack. Но когда Perplexity объявила, что убирает MCP и возвращается к обычным API и CLI, это не было капризом. Это было признание системного ограничения: MCP — протокол для локальных экспериментов, а не для продакшена, интернета и доверенных интеграций. В маркетинговом агентстве Dragon Farm мы не раз проходили этот же путь при проектировании агентных систем для клиентов: сначала восторг от plug-and-play, затем необходимость вернуть enterprise-контракты.
Perplexity и возврат к API: симптом, а не случайность
Решение Perplexity выглядит как внутренний технический выбор. На самом деле это маркер зрелости рынка. Команды, которые выросли из демо в продакшн, начинают замечать, что MCP не дает предсказуемости, безопасности и управляемости. Он удобен, пока агент живет внутри защищенного периметра. Как только агентная система должна касаться платежей, персональных данных, биллинга или межкомандных контрактов, plug-and-play наивность превращается в риск.
MCP как USB: почему простота побеждает только на демо
MCP продается как API для тех, кто не хочет думать про API. Это «USB для агентов»: инструмент умеет говорить на MCP — и его можно подключить к любому агенту без изучения нового контракта. Для локальной автоматизации это правда работает. Поднять MCP-сервер, подключить почту и календарь, поручить агенту назначать встречи — быстрый и понятный сценарий.
Локально MCP действительно удобен: это USB для агентов. Но интернет нельзя построить на USB-соединениях.
Если вы добавляете Slack к MCP-серверу, агент сразу получает доступ к новому инструменту. В enterprise-логике каждая такая интеграция — это отдельный контракт, версионирование, права доступа и регламент. Поэтому MCP кажется прорывом: он сжимает месяцы интеграции в подключаемый модуль. Проблема в том, что за этим сжатием исчезает все, что делает систему безопасной и масштабируемой.
Что на самом деле решают enterprise API
Любой серьезный софт построен на системах, которые вы не контролируете. API между компаниями, командами и внешними сервисами решают не задачу «как соединить». Они решают задачу «как соединиться с системами, которым нельзя доверять полностью». Это принципиально другая задача.
Аутентификация, авторизация, rate limiting, версионирование, разделение ответственности, аудит-трейлы и соглашения о качестве сервиса — это не бюрократия. Это накопленный тридцать лет опыт защиты от взломов, каскадных сбоев и аудиторских катастроф. MCP игнорирует эти слои, потому что изначально не проектировался для пересечения границы доверия. Он создавался для вызова локальных инструментов на одной машине.
Нельзя управлять банком так же, как семейный бизнес управляет кассой. Касса работает, потому что все в комнате известны и находятся внутри доверенного контура. Банк работает, потому что в нем по умолчанию не доверяют никому.
Четыре системные проблемы MCP
1. Гибкость без контрактов
Главное преимущество MCP — автоматическое обнаружение инструментов и отсутствие жестких контрактов. Но именно это делает протокол непригодным для доверенных систем. Нет детерминированного обещания, что система вернет тот или иной результат. Для низкорисковых задач это допустимо. Для процессов, где каждая операция может быть проверена аудитором, — нет.
2. Контекстное окно съедается до первого запроса
Perplexity обнаружила, что схемы MCP-сервера потребляют 72% контекстного окна агента еще до первого реального запроса. Человекочитаемые описания удобны для быстрой настройки, но крайне неэффективны для пропускной способности и вычислительных ресурсов. Enterprise API обычно разделяют обнаружение, команды и данные по разным каналам. Команды и схемы кэшируются, компилируются клиентом и не запрашиваются заново в каждой сессии.
3. Протокол не готов к интернет-масштабу
MCP построен на модели чата поверх HTTPS. Клиент отправляет сообщения, но сервер отвечает через stateful-соединение, которое должно оставаться открытым в течение всей сессии. Это означает, что каждый сеанс держит сетевой порт. Серверы так не масштабируются. Нет механизма переподключения, failover, миграции соединения на другой узел или балансировки нагрузки. Это архитектура локального инструмента, а не интернет-сервиса.
4. Безопасность — опциональная надстройка
В MCP нет встроенной концепции аутентификации и авторизации. Он не опирается на стек дополнительных протоколов, как OpenAPI или A2A. Команды пытаются оборачивать вызовы в OAuth или SAML, но единого стандарта MCP-безопасности нет. Это дробит plug-and-play совместимость и создает еще больше обходных путей. Показательна статистика компании Knostic: из 1862 обнаруженных в интернете MCP-серверов 119 были проверены вручную — и все 119 позволяли получать доступ к внутренним спискам инструментов без аутентификации.
Что делать командам, которые строят агентные системы
Локальный MCP по-прежнему имеет смысл. Он хорош там, где и был задуман: внутри защищенного контура, для экспериментов, прототипов и персональной автоматизации. Но если агент должен работать через границы доверия, быть доступным в интернете или участвовать в коммерческих процессах с аудитом, MCP как универсальный коннектор не подходит.
Google развивает Agent-to-Agent (A2A) как агент-специфичный протокол. В нашей практике хорошо работают обычные OpenAPI REST-эндпоинты. Они понятны клиентам, легко встраиваются в существующую инфраструктуру и не требуют создания параллельного теневого стека. Для маркетинговых и коммерческих сценариев, где агент касается заявок, сделок и unit-экономики, мы сначала выстраиваем настройку сквозной аналитики и лидгена, а уже затем решаем, какой коннектор использовать на уровне оркестрации.
Поэтому при внедрении ИИ-агентов и n8n воркфлоу мы не начинаем с MCP как с универсальной шины. Мы проектируем API-контракты, разделяем discovery и data-каналы, фиксируем роли доступа и только после этого запускаем агентов в контур клиента. Это дольше на старте, но значительно дешевле и безопаснее на дистанции.
Вывод
MCP не умер как локальный инструмент. Он умер как идея «одного простого коннектора», который можно без последствий перенести на интернет-масштаб и enterprise-уровень. Наивная простота не выдерживает столкновения с реальными границами доверия. Командам, которые строят серьезные агентные системы, пора перестать чинить MCP и начать использовать проверенную enterprise-архитектуру. Агенты не требуют новой платформы доверия. Им нужны те же принципы, что и всем остальным системам: контракты, аудит, версионирование и управляемый доступ.
