У протокола MCP уже успели написать преждевременный некролог, хотя сам рынок агентных систем только начал разбираться, что именно он пытается стандартизировать. В этом и проблема: протокол MCP все чаще обсуждают как готовое корпоративное решение со всем набором гарантий, хотя по факту речь пока идет о базовом слое связности для ИИ-агентов, IDE и внешних инструментов. Для русскоязычной IT-аудитории вывод практичный: спорить о «смерти» стандарта рано, а вот о границах его применения, безопасности и управлении доступом уже пора всерьез.
Именно на этом акцентирует внимание The New Stack: дискуссия вокруг MCP страдает от нехватки контекста. Критики протокола, по сути, предъявляют ему требования уровня enterprise governance, ожидая, что один стандарт одновременно решит интеграцию инструментов, разграничение прав, аудит действий агента, изоляцию рисков и контроль над корпоративными данными. Логика понятная, но слегка нечестная. Если коротко, MCP спорно оценивать как «плохой корпоративный продукт», когда он задумывался скорее как общий язык между моделью и внешними возможностями, а не как готовый контур комплаенса для крупной компании.
Это не значит, что у MCP нет проблем. Наоборот: у агентных систем и всего, что подключается к модели через внешние серверы, уже сейчас есть понятный набор рисков. Чем проще агенту получать контекст, дергать инструменты и цепляться к внутренним системам, тем выше цена ошибки. Любая компания, которая пускает такие механизмы в разработку, поддержку, аналитику или внутренние бизнес-процессы, быстро упирается в знакомые вопросы: кто именно дал агенту доступ, по какому правилу он действует, что можно читать, что можно менять, где хранятся следы операций и кто отвечает за инцидент, если агент сделал лишнее. И вот здесь протокол MCP сам по себе не обязан закрывать всю поверхность риска. Он лишь делает саму интеграцию проще, а вместе с этим, как это обычно бывает, повышает требования к обвязке.
В этом смысле нынешняя реакция рынка довольно типична для любой быстро растущей технологии. Сначала появляется стандарт или интерфейс, который резко снижает порог интеграции. Потом сообщество радуется скорости сборки прототипов. Следом приходит корпоративная реальность и задает неприятные вопросы про контроль, безопасность, ответственность и масштабирование. На третьем акте кто-то обязательно объявляет, что технология «не взлетела», просто потому что она не решила все соседние проблемы разом. С MCP происходит примерно это. Его ругают не только за собственные ограничения, но и за отсутствие зрелого слоя управления поверх него. То есть обсуждение давно вышло за рамки самого протокола, а тезисы в споре часто делают вид, будто не вышло.
Для разработчиков здесь нет особой драмы, но есть важная инженерная поправка. MCP полезен как способ стандартизировать доступ модели к инструментам и контексту, особенно там, где раньше каждую интеграцию приходилось собирать вручную. Это экономит время, делает экосистему совместимее и позволяет быстрее менять поставщиков или компоненты. Но как только такой стек оказывается внутри компании, «быстрая интеграция» перестает быть единственной метрикой. Понадобятся отдельные решения для аутентификации, авторизации, политик доступа, журналирования, ревизии действий агента и безопасного исполнения. Иначе организация рискует получить не управляемого помощника, а еще один источник плохо наблюдаемой автоматизации с привилегиями выше, чем следовало бы.
Для бизнеса и IT-руководителей вывод еще жестче. Ошибка не в том, чтобы использовать MCP. Ошибка в том, чтобы воспринимать его как коробочный ответ на вопросы enterprise AI. Если компания строит внутренние агентные сценарии, ей в любом случае придется проектировать отдельный слой управления: какие серверы разрешены, какие инструменты доступны разным ролям, как проходит утверждение интеграций, как фиксируются действия агента, где включается ручная эскалация и как ограничивается доступ к чувствительным данным. Без этого любой разговор о «небезопасности MCP» превращается в спор не о протоколе, а о том, что организация пыталась заменить архитектуру одним удобным интерфейсом. Так не работает ни с облаком, ни с API, ни с LLM-инфраструктурой.
Отдельный нюанс в том, что вокруг агентных стандартов сейчас слишком много бинарного мышления. Либо «это новый универсальный стандарт», либо «это тупик». Но инфраструктурные технологии редко развиваются по такой схеме. Обычно побеждают не те, у кого в первой версии идеальная модель управления, а те, кто успевает стать удобной точкой сборки экосистемы. Если MCP закрепится как минимальный слой совместимости, рынок неизбежно начнет достраивать поверх него шлюзы, политики, каталоги доверенных интеграций, песочницы и контрольные механизмы. И тогда главный вопрос будет уже не в том, «мертв ли MCP», а в том, кто заберет себе слой управления поверх него: open source, платформенные вендоры или сами предприятия.
Поэтому нынешний спор полезен хотя бы тем, что возвращает разговор с уровня хайпа на уровень архитектуры. Протокол MCP не обязан быть серебряной пулей, чтобы оставаться важным элементом новой агентной инфраструктуры. Но и восхищаться им как нейтральной «трубой» без последствий тоже наивно. Чем активнее компании будут встраивать агентов в реальные процессы, тем сильнее внимание сместится с самого стандарта на то, кто и как контролирует контекст, права и границы действий. В агентной экономике побеждает не тот, у кого больше коннекторов, а тот, у кого лучше устроено управление ими.