MCP-серверы: возможности и риски

Рынок искусственного интеллекта стремительно развивается — индикаторы называются разные, но пока любая оценка будет спекулятивной. Ясно, что огромные инвестиции в исследования и инфраструктуру ИИ не отобьются частными подписками по 20 долл. за токен. Основной потребитель ИИ — крупный бизнес и государство, оценивающие решения не только по качеству и скорости моделей, но и по таким традиционным критериям, как удобство интеграции, комплаенс и безопасность. На начальных этапах развития рынка ИИ эти вопросы оставались в тени — фокус внимания был нацелен на новые «удивительные» возможности, которым обладали чат-боты на основе больших языковых моделей. Но сейчас они выходят на первый план — бизнесу и государству нужны интеллектуальные системы высокого уровня сложности, в которых ИИ становится полноправным участником бизнес-процессов, а не просто приятным собеседником.

В этом контексте появление единого протокола взаимодействия ИИ-моделей с разнообразными информационными системами выглядит вполне логично, и в истории ИТ-индустрии такое случалось — достаточно вспомнить HTTP, USB 2.0 и другие стандарты, сформировавшие ее современный облик.

Когда компания Anthropic в ноябре 2024 года запустила в открытое пространство Model Context Protocol (MCP), за первый месяц было зафиксировано около 100 тыс. загрузок — достаточно серьезный старт для нового стандарта интеграции. Когда же в марте 2025 года OpenAI внедрила MCP, количество ежемесячных загрузок подскочило до 22 млн. Это уже не кривая принятия интересного новшества, а свидетельство того, что стандарт укоренился. Весьма вероятно, что именно MCP станет для ИИ универсальным протоколом, ныне находящимся под управлением независимого фонда. Но точка в этой истории еще не поставлена, даже несмотря на широкое принятие этого протокола рынком и обилие MCP-серверов. События в мире ИИ происходят столь динамично, что еще возможен любой поворот.

Как битломаны запустили ИИ‑революцию

Яркая страница в истории искусственного интеллекта открылась 12 июня 2017 года, когда группа ученых-битломанов из Google опубликовала статью 'Attention Is All You Need' по теории нейросетей (тут очевидна, и авторы сами это подтверждают, отсылка к хиту The Beates 'All You Need Is Love'). В этой публикации был представлен новый тип нейронных сетей, которые назвали трансформерами. Вся идея была в механизме внимания — матрице весов связности между элементами данных. Для каждого слова, пикселя или другого объекта модель вычисляет, насколько сильно он должен учитывать остальные объекты, а затем строит свое представление на основе этих весов. Именно поэтому трансформер способен выявлять сложные зависимости независимо от расстояния между элементами и даже от типа данных. Сеть может работать с текстами, изображениями, видео, музыкой, последовательностями аминокислот в белках, временными рядами, например, ценами акций или климатическими данными, — все превращается в векторы в многомерном пространстве.

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

Битломаны из Google показали, что можно полностью отказаться от рекуррентных сетей (RNN) и использовать только внимание — и модель работает быстрее, лучше и хорошо распараллеливается.

Расцвет чат-ботов

История языковых моделей уходит в статистическое моделирование текста и исследования грамматики и синтаксиса середины XX века. Но тогда их использование ограничивалось узкими рамками — машинный перевод, автодополнение, распознавание речи и пр. Все они были рабочими лошадками внутри специализированных систем и не претендовали на роль всезнающего оракула. Но уже тогда было понятно, что язык — это универсальный носитель знаний, а значит, если научиться моделировать его на очень больших данных, можно получить куда более мощную систему. Проблема была в том, что старые архитектуры не позволяли раскрыть этот потенциал в полной мере. Трансформеры дали языковым моделям второе дыхание и сделали возможным их масштабирование до невиданных ранее размеров — на сцену вышли LLM.

Исследовательская лаборатория Open AI одной из первых сумела превратить идею трансформеров в массовый продукт, перехватив инициативу у Google и начав выпускать свои модели серии generative pre-trained transformer — GPT-1, GPT-2, GPT-3…

Число параметров росло, а вместе с ним стали проявляться неожиданные эффекты. Модели, которые изначально обучались лишь предсказывать следующее слово, вдруг научились переводить тексты, отвечать на вопросы, писать программы и рассуждать над задачами, для решения которых специально не обучали. Исследователи заговорили об «эмерджентных способностях» и предположили, что простое масштабирование — больше данных, больше вычислений, больше параметров — может привести к появлению качественно новых возможностей.

Однако у GPT-3 был существенный недостаток — она плохо подходила для общения с человеком. Модель умела продолжать текст, но не понимала, чего именно хочет пользователь. Она могла внезапно сменить тему, начать писать от имени собеседника или уйти в пространные рассуждения. Фактически GPT-3 была лишь мощным генератором текста, но крайне неудобным помощником.

Решение оказалось неожиданно простым. Вместо того чтобы обучать модель только на текстах из Сети, OpenAI начала обучать ее на примерах хороших ответов, подготовленных людьми, а затем использовать оценки людей для дальнейшей настройки поведения модели. Так появился ChatGPT — чат-интерфейс поверх GPT-3.5, с помощью которого через обычный текст можно было задать почти любую задачу без перестройки продукта, но для точной работы он часто оказывался хуже специализированных UI.

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

Однако собственные API чат-ботов были очень аскетичны и фактически позволяли только передать запрос и получить ответ. Сколько-нибудь продвинутую автоматизацию на этом не построишь, и приходилось как-то выкручиваться. Чаще всего пытались с помощью промптов заставить модель вернуть структурированный JSON, чтобы передать его дальше на обработку. Но это было нестабильно и — что хуже всего — слишком разнообразно. Каждый разработчик реализовывал подобные коннекторы по-своему, а каждый поставщик LLM давал свои рекомендации, как общаться с его моделью.

Рынок столкнулся с классической ситуацией — если имеется M клиентов и N сервисов, то требуется M×N интеграций. Одна из самых повторяющихся архитектурных проблем в истории ИТ — проблема «интеграционного взрыва» — снова вышла на арену. Причем нельзя сказать, что всегда она решалась успешно. Например, в начале 2000-х была SOA [1] — неплохая идея связать все корпоративные приложения через общую шину, но не получилось. Аналогичный расклад случился и с появлением мобильных платформ, когда возникло разнообразие клиентов, потом с микросервисами и SaaS. Молодому рынку ИИ тоже пришлось разбираться со своим зоопарком интеграций. И рецепт только один — стандартизация.

Движение к стандарту

Первым шагом на пути к стандартизации взаимодействия LLM с внешним миром стал механизм function calling, представленный OpenAI в 2023 году. Модель больше не была ограничена генерацией текста — ей можно было передать описание функций, а она сама решала, когда и какую из них использовать. На первый взгляд это выглядело как особенность API OpenAI, но быстро стало ясно, что речь идет о более важной идее.

По сути, function calling — это метаданные поверх API. Сам этот механизм ничего не выполняет, он просто побуждает модель давать структурированный ответ в формате JSON по четко оговоренной схеме — и модель этому должна быть специально обучена, в этом принципиальная разница по сравнению с первым поколением LLM. Тогда вызывающая система может его разобрать и вызвать API, например, выполнить веб-поиск или узнать погоду в указанном городе. Получив отклик от сервиса, можно возвратить его модели, чтобы она могла продолжить свою работу. Так реализуются сложные многоходовые сценарии.

Важный момент — LLM сама функций не вызывает, за нее это делает построенная специальным образом система, выполняющая все, что приказывает модель [2].

Практически сразу похожие механизмы появились у остальных игроков рынка. Примечательно, первые чат-боты ничего не знали о недавних событиях в мире — они могли отвечать только на основе тех данных, на которых были обучены, но потом все они резко приобрели способность проводить исследования в Сети. Это как раз и было результатом использования инструментов function calling или Tool Use.

Однако быстро обнаружились ограничения function calling. Несмотря на общее название механизма, позволяющего языковым моделям взаимодействовать с внешними системами и инструментами, стандарта как такового не было. Каждая модель ожидала свой формат описания функций, каждое приложение по-своему хранило список инструментов, а каждая интеграция создавалась практически с нуля.

Парадокс — API внешних информационных систем давно были стандартизированы на основе REST, SQL, GraphQL и пр., но интерфейс между этими системами и языковыми моделями отсутствовал. Индустрии был нужен новый уровень абстракции для построения универсальной модели взаимодействия LLM с произвольными ИТ-системами.

Протокол для ИИ-агентов

В конце 2024 года ИИ-агенты еще не позиционировались как отдельный класс продуктов — каждый разработчик сам решал, какими инструментами снабдить своего агента, чтобы, в частности, выделиться на фоне конкурентов. Все эти интеграции разрабатывались и поддерживались вручную — проблема MxN оставалась нерешенной, а ресурсы тратились на практически повторяющуюся работу. И если бы не невообразимый хайп, который поднялся вокруг «фантастических» возможностей ИИ, то воз был бы и ныне там — владельцы зрелых платформ, как правило, не заинтересованы в интеграциях с десятками и сотнями стартапов. Но в этот раз дело обстояло иначе — все традиционные вендоры ПО были озабочены тем, как скорее продемонстрировать рынку, что и у них тоже есть «свой ИИ». Налицо синдром FOMO (fear of missing out) — боязнь пропустить интересное, но теперь уже поставщиков LLM захлестнула волна спроса на большое количество интеграций.

И тут Anthropic выдвинула идею — пусть не LLM интегрируются с бесчисленным количеством внешних ресурсов, а сами эти ресурсы станут доступны моделям (см. рисунок). Это развернуло ситуацию, и теперь создатели разнообразных прикладных систем сами должны были разрабатывать специальные компоненты, чтобы ИИ-агенты могли по своему усмотрению использовать их продукты в качестве инструментов [3].

Способы интеграции LLM c внешним миром: а) без MCP; б) с протоколом

Именно переход от заранее известных интеграций к динамической экосистеме инструментов стал главным шагом от современных LLM к агентным системам.

Anthropic представила протокол MCP как открытый стандарт, и вместе с ним были опубликованы SDK и примеры MCP-серверов. Начался новый этап ИИ-ралли — кто быстрее сделает свою систему полезной для агентов.

Machine-first — новый императив разработки

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

ИИ перестал быть просто бантиком, который можно было привесить к любой системе, чтобы не отставать от моды, — он стал одним из ключевых факторов стратегии компаний.

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

Фундаментальное отличие MCP от классического API заключается не в самом протоколе взаимодействия, а в смене адресата интерфейса. Классический API проектируется для разработчика. Его конечный пользователь — человек, который пишет код, читает документацию, принимает решения о том, какие эндпоинты вызывать и в каком порядке. Даже в самых высокоуровневых SDK ответственность за композицию вызовов остается на стороне человека. MCP-интерфейс проектируется для модели, которая сама планирует действия. Это означает, что теперь решения принимает агент, а интерфейс лишь предоставляет ему пространство допустимых действий.

Конечно, пока последнее слово за хозяином ИИ-агента. Но уже сейчас MCP-серверов многие тысячи, вполне вероятно, что счет пойдет и на миллионы, как было с мобильными приложениями. Естественно, среди них появятся и вредоносные, и криво работающие, и просто бесполезные. Также вполне предсказуемо, что человек не захочет во всем этом копаться и делегирует задачу своему агенту. Конечно, было бы слишком рискованно позволить агенту принести домой любой MCP-сервер, который он нашел в Сети, — несомненно, будут доверенные репозитории по типу нынешних магазинов приложений.

Но это все детали. Главное, что с достаточно высокой вероятностью реализуется сценарий автоматического или, как минимум, полуавтоматического обнаружения (discovery) агентами необходимых MCP-серверов. Это значит, что теперь вам придется разрабатывать свои API так, чтобы они нравились агентам. А это не такая простая задача, как кажется.

Под крылом Linux Foundation

За считанные месяцы после выпуска MCP начали поддерживать игроки ИИ-рынка, включая и конкурентов Anthropic: OpenAI и Google. Протокол, который создавался как конкурентное преимущество для Claude, стал претендовать на роль отраслевого стандарта. Едва ли Anthropic ожидала такого поворота. Если оставить MCP под собственным контролем, то неизбежно появятся альтернативы и рынок расколется на несколько несовместимых лагерей. А если MCP станет стандартом де-факто для агентных систем, его разработчик от этого только выиграет — лучше контролировать будущее через экосистему, чем контролировать протокол и потерять экосистему.

В декабре 2025 года Anthropic передала управление MCP, работающему под эгидой Linux Foundation, фонду Agentic AI Foundation (AAIF), учредители которого совместно с Anthropic OpenAI и Block передали ему свои проекты: формат AGENTS.md и агентный фреймворк Goose. На текущий момент инициативу также поддержали Google, Microsoft, AWS, Cloudflare, Bloomberg и другие, всего около 200 организаций.

Вообще говоря, когда вместо отдельных энтузиастов за дело берутся комитеты, это повод волноваться за судьбу проекта. Потому что, согласно закону Паркинсона о комитетах, «комитеты склонны разрастаться, усложняться и обсуждать второстепенные вопросы дольше, чем действительно важные». С MCP этого пока не произошло и даже наоборот — разработка из формата «секретной кухни Anthropic» трансформировалась в типичный инфраструктурный проект категории Open Source, управляемый сообществом, хотя и при историческом влиянии Anthropic.

Подготовленный фондом AAIF план развития проекта MCP выглядит весьма рационально и сосредоточен на ряде жизненно важных направлений.

Самое большое внимание уделяется транспортному уровню. Изначально удаленные MCP-серверы использовали HTTP + SSE (Server-Side-Events), но у этого решения были существенные минусы: долгие соединения плохо живут в балансировщиках, плохо переживают рестарты и вообще ведут себя нестабильно там, где требуется масштабирование. Поэтому появился новый транспорт — Streamable HTTP, свободный от этих недостатков.

На уровне контекста выполнения вскрылась другая проблема. Первые MCP-серверы не были системами без контекста (состояния) между отдельными запросами или операциями (stateless). Пока сервера жили в локальном мире, это работало, но как только MCP начали переезжать в корпоративные ландшафты и облака, проявились классические проблемы систем с сохранением состояния (stateful) — сложность горизонтального масштабирования, управление сессиями, риски при переносе в рабочую среду и пр. Поэтому сейчас MCP движется в сторону модели stateless execution — состояние выполнения должно жить вне процесса сервера, а сессии — явно создаваться, восстанавливаться и переноситься между инстансами.

Другая важная тема — обнаружение (discovery). Сегодня, чтобы понять, что умеет MCP-сервер, к нему надо подключиться. Фонд предлагает изменить это с помощью Server Cards — стандартизированного описания возможностей сервера. Если это приживется, то вокруг появятся каталоги, поисковые системы и автоматическое обнаружение серверов агентами.

Еще одно направление связано с долгими операциями. MCP изначально был рассчитан на быстрые вызовы инструментов, но реальные системы постоянно сталкиваются с задачами, которые выполняются часами. Поэтому активно развивается примитив Tasks: сервер может принять работу, вернуть идентификатор задачи, а клиент — позже узнать статус, получить результат или отменить выполнение.

Наконец, AAIF много внимания уделяет вещам, которые обычно появляются только у зрелых стандартов: аудиту, SSO (Single Sign-On, технология единого входа), прокси-шлюзам, переносимости конфигураций и формальным процессам изменения спецификации. И это, пожалуй, самое важное — MCP все меньше напоминает эксперимент Anthropic и все больше инфраструктурный стандарт, который готовят к долгой жизни.

MCP — новая угроза

Но самое интересное сейчас происходит не в области функциональности, а в сфере безопасности. Когда есть тысячи серверов, позволяющих агентам читать файлы, запускать команды, работать с Git, облаками и корпоративными системами, быстро выясняется, что традиционные подходы к защите работают не всегда.

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

Одним из первых новых классов угроз стало Tool Poisoning — «отравление инструментов». Вместо взлома сервера злоумышленник публикует MCP-инструмент с вредоносным или вводящим в заблуждение описанием. Для модели такое описание становится частью контекста, который влияет на ее дальнейшие действия.

Другой класс угроз связан с Prompt Injection через внешние данные. Исследователи показали, что вредоносные инструкции могут попадать в контекст агента через GitHub Issues, документы, веб-страницы или другие источники. В результате агент начинает выполнять действия, которые не соответствуют намерениям пользователя, включая раскрытие конфиденциальной информации.

Наконец, появились Trust Chain Attacks — атаки на цепочки инструментов. В начале 2026 года исследователи обнаружили несколько серьезных уязвимостей в официальном Git MCP Server, показав, что комбинация Git и Filesystem MCP-серверов может использоваться для обхода ограничений и построения цепочек удаленного выполнения кода. Проблема оказалась не в одном конкретном сервере, а во взаимодействии нескольких доверенных компонентов.

Не обошлось и без более традиционных инцидентов. Весной 2026 года исследователи OX Security обнаружили критические проблемы в официальных SDK MCP для Python, TypeScript, Java и Rust, приведшие к выпуску более десятка новых уязвимостей.

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

***

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

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

Литература

1. Леонид Черняк. Общая шина предприятия // Открытые системы.СУБД. — 2003. — № 4. — С. 18–19. URL: https://www.osp.ru/os/2003/04/182897 (дата обращения: 21.07.2026).

2. Александр Огуречников. Риски и подводные камни ИИ-агентов // Открытые системы.СУБД. — 2026. — № 2. — С. 14–17. URL: https://www.osp.ru/os/2026/02/13060803 (дата обращения: 21.07.2026).

3. Владимир Быков. Что ETL может взять у LLM // osp.ru. — [Электронный ресурс]. — 2026. — URL: https://www.osp.ru/articles/2026/0220/13060443 (дата обращения: 22.07.2026).

Станислав Макаров (s.makarov15@gmail.com) — редактор канала Agentic Enterprise (@AgenticEnterprise) (Волгоград); Дмитрий Волков (vlk@keldysh.ru) — старший научный сотрудник ИПМ им. М. В. Келдыша РАН (Москва).

DOI: 10.51793/OS.2026.28.42.002