MCP для бизнеса: как подключить ИИ к корпоративным данным

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

Такой подход называют схемой N×M. Если в компании N приложений и M внешних сервисов, для их взаимодействия приходится создавать до N×M отдельных интеграций. Чем больше систем появляется, тем сложнее поддерживать и масштабировать такую архитектуру.

Протокол MCP переводит эту схему в N+M. Для каждого инструмента достаточно один раз создать MCP-сервер, а для приложения — MCP-клиент. После этого любой MCP-совместимый агент сможет работать с этим инструментом через единый протокол без разработки новых коннекторов.

Аналогия: USB-C для ИИ

Раньше у каждого гаджета был свой разъем и свой кабель. Зарядка от одного телефона не подходила к другому — приходилось таскать кучу проводов. Потом появился USB-C: один стандарт, который подходит ко всему.

Примерно то же самое MCP делает для ИИ. До него каждую новую систему — базу данных, таск-трекер, корпоративный портал — приходилось подключать к модели отдельно, своим способом. MCP вводит единый стандарт. ИИ-агент подключается один раз и работает с любым инструментом, который поддерживает этот протокол. Неважно, что внутри — для модели все выглядит одинаково. Поэтому MCP и называют «USB-C для ИИ».

Протокол разработали Anthropic — создатели Claude Code. Свой стандарт MCP компания представила стандарт в ноябре 2024 года. Уже в марте 2025 этот стандарт официально приняли OpenAI, внедрив протокол в продукты, включая десктопное приложение ChatGPT.

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

В декабре 2025 года Anthropic объявила о передаче MCP в Agentic AI Foundation (AAIF) — фонд под управлением Linux Foundation, который был создан при участии Anthropic, OpenAI, Block, Google, Microsoft, Amazon, Cloudflare и Bloomberg. Благодаря этому протокол перешел под нейтральное открытое управление и перестал зависеть от одного разработчика. 

Динамику роста экосистемы наглядно иллюстрирует ежемесячный прирост числа публичных MCP-серверов. 

Как устроен MCP: архитектура

В основе MCP лежит клиент-серверная архитектура. Она состоит из трех компонентов, каждый из которых выполняет свою задачу.

Host, Client, Server

Роли в архитектуре:

• Host — это само приложение, в котором живет ИИ-агент. Например, Claude Desktop или среда разработки (IDE). Host запускает агента, подключает ему нужные сервисы и управляет всем процессом. Модель при этом может быть встроенной прямо в приложение или работать где-то в облаке — для хоста это не принципиально.

• Client — это прослойка внутри Host, которая отвечает за связь с одним конкретным сервисом. Именно она открывает соединение, отправляет запросы, получает ответы и следит, чтобы все работало как надо. 

• Server — это внешний сервис, к которому обращается ИИ. Это может быть база данных, файловая система, корпоративный портал или что угодно еще. Server предоставляет модели готовые инструменты и данные, с которыми она может работать.

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

Транспорты: stdio и HTTP

MCP поддерживает два способа обмена данными между хостом и сервером. В обоих случаях сообщения передаются в формате JSON-RPC, а отличается только способ подключения.

• stdio используют для локальных серверов — хост запускает MCP-сервер как дочерний процесс и обменивается с ним данными через стандартные потоки ввода и вывода;

• HTTP применяют для удаленных серверов, например, облачных сервисов или корпоративных платформ. В более ранних версиях SDK использовался транспорт на основе SSE, однако в актуальных версиях предпочтительным является Streamable HTTP. 

Выбор транспорта зависит от сценария. Для локального помощника разработчика обычно достаточно stdio, а для корпоративных ИИ-агентов, которые работают с общими сервисами и данными, используют HTTP.

Три примитива MCP: Tools, Resources, Prompts

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

Важно не путать MCP с механизмом вызова функций (function calling):

• Function calling позволяет LLM вызвать конкретную функцию, но не решает, как найти доступные инструменты, установить соединение с внешней системой и обмениваться данными. 

• MCP работает поверх function calling: он автоматически сообщает клиенту, какие возможности доступны на сервере, использует JSON-RPC для передачи данных и управляет сессиями. Благодаря этому один и тот же MCP-сервер можно подключить к любому совместимому клиенту без отдельных интеграций.

MCP и мультиагентные системы

Самое интересное начинается, если агентов становится несколько. ИИ-агент может выступать одновременно в двух ролях: как MCP-клиент (обращаясь к серверам за данными и инструментами) и как MCP-сервер (предоставляя свои возможности другим агентам). Это позволяет строить иерархические мультиагентные системы, где специализированные агенты решают узкие задачи — один работает с данными, другой отлаживает пайплайны, третий ищет по документации, — а агент-координатор управляет ими через цепочки вызовов (chaining). 

Как это выглядит в реальной эксплуатации, показал опыт Pinterest, описанный в аналитическом материале InfoQ. Развернули несколько MCP-серверов для работы с данными, отладки и оркестрации. Все они были объединены в едином реестре, а опасные операции требовали подтверждения человеком. Это принесло ощутимые результаты: около 66 000 вызовов в месяц от 844 пользователей и примерно 7 000 сэкономленных человекочасов ежемесячно. Сам протокол оказался не главной сложностью — больше усилий потребовала инфраструктура: реестр, авторизация и мониторинг. 

Собрать собственный MCP-сервер с нуля можно, но для типовой задачи «дать агенту доступ к корпоративным знаниям» это лишняя работа. Cloud.ru предоставляет готовую MCP-инфраструктуру в среде Evolution AI Factory, которая поддерживает протоколы MCP и A2A. Разберем связку по слоям.

MCP в Evolution AI Agents

Evolution AI Agents — сервис для создания и эксплуатации ИИ-агентов. Новые навыки агент получает за счет подключения MCP-серверов: он обращается к корпоративным мессенджерам, таск-трекерам и БД через стандартный протокол, а не кастомный адаптер под каждую систему. Дополнительно сервис интегрирован с популярными инструментами разработки агентов, поэтому сервер, написанный по стандарту MCP, встает в общий каталог инструментов агента.

Managed RAG как MCP-сервер

Evolution Managed RAG — сервис для создания и управления базами знаний, на основе которых языковая модель формирует ответы. Ключевая деталь для нашей темы: Managed RAG работает как MCP-сервер. Вы подключаете корпоративную базу знаний к агенту через MCP — и агент отвечает на вопросы, опираясь на ваши документы и контекст.

Представьте команду поддержки, которой приходится регулярно отвечать на однотипные вопросы по внутренним документам и регламентам. С Managed RAG компания загружает документы в базу знаний, подключает MCP-сервер и связывает его с ИИ-агентом в AI Agents по инструкции Cloud.ru. Дальше агент отвечает сотрудникам на основе актуальных документов.

Архитектура решения на Cloud.ru

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

Наблюдаемость — часть архитектуры: Evolution AI Agents интегрирован с платформой Arize Phoenix, поэтому разработчик видит, какие инструменты вызывал агент и как принимал решения. Инфраструктура Cloud.ru при этом размещена в дата-центрах стандарта Tier III на территории России и соответствует требованиям 152-ФЗ по работе с персональными данными.

Перед продакшеном: что стоит помнить

Подключение ИИ-агента к внешним системам расширяет его возможности, но одновременно создает новые риски безопасности. Перед запуском в продакшен важно учитывать, какие данные и инструменты получает агент и кто имеет к ним доступ.

Основные угрозы связаны с двумя сценариями:

• Первый — вредоносные инструкции во внешних данных. Модель может получить текст, который пытается изменить ее поведение и заставить выполнить нежелательное действие.

• Второй — небезопасные инструменты. Некорректно настроенный сервер может создать условия для утечки данных через другие подключенные системы.

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

Если остались неясности — вот краткие ответы на самые частые вопросы о том, что такое MCP и как он работает. 

Что такое MCP простыми словами?

MCP (Model Context Protocol) — открытый протокол, который задает единый способ подключения ИИ-моделей к внешним инструментам и данным.

Заменит ли MCP REST API?

Нет. MCP — это протокол доступа ИИ к инструментам. Обычные API он не заменит. REST и GraphQL продолжают использоваться для традиционных приложений и сервисов, а MCP добавляет удобный слой взаимодействия для ИИ-моделей.

Чем MCP отличается от вызова функций (function calling)?

Function calling позволяет модели вызвать конкретную функцию. MCP расширяет этот подход: он добавляет механизм обнаружения возможностей сервера, единый формат обмена сообщениями через JSON-RPC и управление сессиями.

Как подключить MCP к своим данным?

Один из вариантов — использовать Evolution AI Agents с MCP-интеграцией и Managed RAG в роли MCP-сервера. Подход позволяет подключить корпоративную базу знаний к ИИ-агенту без разработки отдельных адаптеров под каждую систему. Пошаговый сценарий с базой знаний есть в документации Cloud.ru.