Model Context Protocol (MCP): полное руководство для бизнеса

Год назад подключение большой языковой модели к внутренней системе означало отдельный проект. CRM требовала одного API-клиента и своей схемы авторизации, GitLab — другого, PostgreSQL — третьего, со своими правами доступа и пулом соединений, корпоративная Wiki — четвёртого, обычно самописного. Каждая новая интеграция добавляла код, который нужно было поддерживать, обновлять при смене версии API и отдельно тестировать на утечки данных. При пяти системах и трёх моделях число таких связок росло не линейно, а как произведение: N систем × M моделей. Это и есть проблема N×M, которая годами тормозила внедрение AI-агентов в компаниях крупнее стартапа.

Model Context Protocol (MCP) — открытый стандарт, который решает эту задачу иначе: не N×M интеграций, а N серверов и M клиентов, совместимых друг с другом по одному протоколу. Разберём, как устроен MCP, какие задачи он закрывает в корпоративной инфраструктуре, какие риски несёт и как развернуть MCP-инфраструктуру в облаке на примере сервисов VK Cloud.

Почему появился MCP

Разработчики годами решали одну и ту же задачу: как дать модели доступ к данным и инструментам за пределами её обучающей выборки. Каждая компания решала её по-своему, и в итоге возник разрозненный набор несовместимых решений.

Проблема интеграций

Классическая интеграция LLM с внешней системой — это код, написанный под конкретную пару «модель плюс сервис». У CRM свой REST API и OAuth-поток, у GitLab — токены доступа и вебхуки, у внутренней базы знаний вообще нет API, только веб-интерфейс. Для каждой пары нужен свой SDK, своя авторизация, свой формат ответа, который приходится вручную превращать в контекст для модели. Когда компания меняет модель — переходит, например, с одного поставщика на другого — часть интеграций приходится переписывать заново, потому что они были завязаны на специфичный формат function calling конкретного провайдера. Стоимость поддержки растёт вместе с числом систем и моделей, а не с масштабом бизнеса.

Почему одного API-провайдера недостаточно

Модель, вызванная напрямую через API OpenAI, Anthropic или любого другого провайдера, не имеет встроенного механизма безопасной работы с внешними корпоративными системами. Она не знает прав доступа пользователя, не умеет ограничивать области видимости данных и не разделяет ответственность между тем, что модель может вызвать, и тем, что ей разрешено вызвать в данном контексте. Прослойку авторизации, аудит вызовов, ограничение по ролям приходится реализовывать поверх API самостоятельно. Без единого протокола каждая команда придумывает эту прослойку заново, и получившиеся решения плохо переносятся между проектами.

От разрозненных плагинов к открытому стандарту

Первой попыткой стандартизировать доступ модели к внешним инструментам стали ChatGPT Plugins в 2023 году, следом появился function calling (tool calling) — модель научилась формировать структурированный вызов функции по описанной схеме. Оба подхода работали, но оставались привязаны к конкретному провайдеру: плагин, написанный под одну экосистему, не запускался в другой. 25 ноября 2024 года Anthropic представила Model Context Protocol как открытый стандарт с публичной спецификацией, SDK и набором референсных серверов для Google Drive, Slack, GitHub, Git, PostgreSQL и Puppeteer. Уже на старте протокол поддержали ранние партнёры — Block, Apollo, а также редакторы кода Zed, Replit, Codeium и платформа Sourcegraph.

Дальше протокол вышел за пределы одной компании: 19 марта 2025 года Microsoft добавила MCP в публичное превью Copilot Studio, 26 марта 2025 года OpenAI объявила о поддержке MCP в Agents SDK, а 9 апреля 2025 года глава Google DeepMind Демис Хассабис объявил о поддержке MCP для моделей и SDK Gemini.

Что такое Model Context Protocol

Model Context Protocol — протокол на основе JSON-RPC 2.0, который описывает, как модель обменивается данными и вызывает инструменты через промежуточный слой клиента и сервера. Спецификация построена на клиент-хост-серверной архитектуре: один хост может держать несколько клиентских соединений одновременно, а каждый клиент общается ровно с одним сервером.

Чтобы разобраться в архитектуре, разложим её на компоненты так, как они определены в официальной спецификации.

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

MCP Client создаётся хостом и держит соединение один к одному с конкретным сервером. Это стейтфул-сессия: клиент и сервер на старте обмениваются списком поддерживаемых возможностей (capability exchange) и дальше работают в рамках согласованного протокола. Клиент выступает границей безопасности между серверами — один сервер не видит, что происходит в сессии другого.

MCP Server раскрывает вовне свои возможности: инструменты, данные и шаблоны промптов. У сервера узкая ответственность — обычно один сервер отвечает за одну систему: PostgreSQL, файловое хранилище, Git-репозиторий. Сервер может быть локальным процессом рядом с хостом или удалённым сервисом за сетью.

Возможности сервера делятся на три типа:

• Tools — функции, которые модель может вызвать сама: сделать запрос к базе данных, обратиться к внешнему API, выполнить вычисление.
• Resources — данные, которые сервер отдаёт модели как контекст: содержимое файла, схема таблицы, фрагмент документации.
• Prompts — переиспользуемые шаблоны запросов и последовательностей действий для типовых сценариев.

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

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

Как работает MCP

Разберём типовое взаимодействие пошагово — от вопроса пользователя до итогового ответа модели.

Пользователь задаёт вопрос в интерфейсе хоста: например, просит показать открытые инциденты по конкретному сервису за последнюю неделю. Модель определяет, что ответить из собственных знаний нельзя — нужны актуальные данные из внешней системы. Дальше в дело вступает MCP Client: он обращается к подключённому серверу (в этом примере — серверу, который знает про Service Desk) и запрашивает список доступных инструментов и ресурсов. Сервер вызывает нужный инструмент, например функцию поиска инцидентов по фильтру, и выполняет его на своей стороне, обращаясь к реальной базе данных Service Desk. Результат возвращается клиенту в структурированном виде — не сырой ответ базы данных, а формат, который модель может встроить в контекст. Модель получает эти данные и формирует итоговый ответ пользователю на естественном языке, опираясь на структурированный результат, а не на догадки.

Весь обмен идёт поверх JSON-RPC 2.0 — компактного протокола удалённого вызова процедур, где запрос и ответ описываются простой JSON-структурой с полями метода, параметров и идентификатора. Транспортный уровень эволюционировал вместе со спецификацией. В первой публичной ревизии 2024-11-05 поддерживались два транспорта: локальный stdio (стандартные потоки ввода-вывода процесса — для серверов, запущенных рядом с хостом) и связка HTTP плюс Server-Sent Events для удалённых серверов.

В ревизии от 26 марта 2025 года HTTP+SSE заменил Streamable HTTP — единый эндпоинт, где клиент отправляет запросы методом POST, а метод GET на том же эндпоинте открывает канал Server-Sent Events для потоковой доставки ответов и уведомлений. Та же ревизия ввела базовый фреймворк авторизации на основе OAuth 2.1 с обязательным PKCE (proof key for code exchange — механизм защиты кода авторизации от перехвата) и обнаружением авторизационного сервера через RFC 8414. Это упростило развёртывание удалённых серверов за балансировщиками и API-шлюзами: отдельное SSE-соединение больше не нужно держать постоянно открытым.

Ревизия 2025-06-18 усилила фреймворк: классифицировала MCP-серверы как OAuth Resource Servers и добавила обязательные RFC 9728 (Protected Resource Metadata) для обнаружения сервера и RFC 8707 (Resource Indicators) для привязки токена доступа к конкретному серверу-получателю. Ревизия 2025-11-25 добавила поддержку OpenID Connect Discovery, метаданные с иконками серверов, инкрементальное согласие на расширение прав доступа (incremental scope consent) и экспериментальную поддержку долгих асинхронных задач.

Какие задачи решает MCP

Практическая ценность MCP видна не в архитектурных диаграммах, а в конкретных корпоративных сценариях.

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

Доступ к репозиториям кода. Официальный референсный сервер Git даёт модели инструменты для чтения истории коммитов, диффов и содержимого файлов репозитория. Разработчик просит объяснить, почему тест упал после последнего коммита, — ассистент читает сам дифф через Git-сервер и формирует объяснение на основе реального изменения кода, а не предположения.

Работа с базами данных. Работу с PostgreSQL закрывают коммьюнити-серверы; официальный референсный сервер Postgres — исторический: с мая 2025 года он перенесён в архивный репозиторий и не входит в текущий поддерживаемый набор. Аналитик просит посчитать число активных подписок по регионам за квартал — модель формирует SQL-запрос в рамках прав подключения, сервер выполняет его на реальных данных и возвращает таблицу, которую модель превращает в читаемый ответ.

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

Файловые хранилища. Референсный сервер Filesystem даёт модели контролируемый доступ к файлам на диске, с ограничением по каталогам. Юрист просит найти во всех файлах папки проекта пункты про неустойку — сервер ищет по разрешённой директории, модель извлекает и группирует релевантные фрагменты.

Service Desk. MCP-сервер поверх системы обработки заявок раскрывает создание, поиск и обновление тикетов как инструменты. Сотрудник описывает проблему в чате — ассистент создаёт тикет с правильной категорией и приоритетом, не заставляя человека заполнять форму вручную.

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

Отдельно стоит упомянуть память как ресурс: референсный сервер Memory реализует граф знаний, который накапливается между сессиями, — это полезно, когда ассистенту нужно помнить контекст предыдущих обращений пользователя. Ещё один референсный сервер, Sequential Thinking, помогает модели структурировать многошаговое рассуждение как отдельный инструмент, а не как часть одного текстового ответа.

Из корпоративных внедрений заметна платформа GitLab Duo Agent Platform, которая встроила поддержку MCP для расширения возможностей AI-агентов внутри DevOps-цикла — от анализа merge request до работы с CI/CD-пайплайнами.

Безопасность MCP

MCP не снимает вопросы безопасности — он их формализует и делает видимыми, но ответственность за корректную настройку остаётся на стороне, которая разворачивает серверы и клиенты.

Базовый уровень защиты — авторизация. Ревизия 2025-03-26 ввела фреймворк на основе OAuth 2.1 с обязательным PKCE и обнаружением авторизационного сервера через RFC 8414 (Authorization Server Metadata). Ревизия 2025-06-18 усилила его: классифицировала MCP-серверы как OAuth Resource Servers и добавила обязательные RFC 9728 (Protected Resource Metadata) и RFC 8707 (Resource Indicators) для привязки токена доступа к конкретному серверу-получателю. Это напрямую закрывает один из характерных рисков протокола — token passthrough, когда токен, выданный для одного сервера, можно переиспользовать для доступа к другому.

Спецификация выделяет и другие типовые риски. Prompt injection — скрытая инструкция, встроенная в данные, которые модель получает через Resources, способная заставить модель выполнить нежелательное действие. Tool poisoning — вредоносные инструкции, спрятанные прямо в описании инструмента, которые модель читает как часть системного контекста, доверяя им наравне с легитимным описанием. Tool mutation — изменение поведения инструмента после того, как пользователь один раз одобрил его использование. Confused deputy — ситуация, где сервер-посредник с широкими правами доступа выполняет действие от имени пользователя с меньшими правами, фактически повышая его привилегии. Cross-server exploitation — использование одного скомпрометированного сервера как плацдарма для атаки на данные, доступные через другой сервер в той же сессии.

Эти риски не гипотетические. В апреле 2025 года исследователи Invariant Labs раскрыли уязвимость в MCP-интеграции с WhatsApp: через отравленные описания инструментов можно было извлечь историю переписки. Кейс получил повторный резонанс в обзорах безопасности MCP осенью 2025 года — классический пример tool poisoning: модель доверилась вредоносному тексту, который выглядел как обычное описание доступного инструмента.

Практическая защита строится на нескольких принципах. Минимизация прав — сервер получает доступ ровно к тем данным и операциям, которые нужны для его задачи, не шире. Изоляция инструментов — компрометация одного сервера не должна автоматически давать доступ к данным другого, эту границу обеспечивает архитектура хост-клиент. Инкрементальное согласие (incremental scope consent), закреплённое в ревизии 2025-11-25, требует явного подтверждения пользователя при расширении прав доступа сервера, а не однократного согласия на всё сразу. Аудит вызовов — журналирование каждого обращения модели к инструменту, чтобы можно было расследовать инцидент постфактум. И принцип Zero Trust: ни один компонент системы, включая сами MCP-серверы, не считается доверенным по умолчанию, каждое обращение проверяется независимо от источника.

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

Как развернуть MCP в VK Cloud

Развёртывание MCP-инфраструктуры в облаке — это сборка из нескольких сервисов, каждый из которых закрывает свою часть архитектуры.

MCP-серверы по своей природе — небольшие изолированные процессы, каждый под одну систему. Это хорошо ложится на контейнеризацию: серверы разворачиваются как поды в Managed Kubernetes, каждый сервис (Postgres, Git, Service Desk) получает свой под или небольшой набор реплик с независимым масштабированием. Container Registry хранит образы серверов и интегрируется с CI/CD-пайплайном сборки: обновил код сервера, собрал образ, обновил под в кластере.

Состояние, которое серверам нужно хранить между вызовами — граф знаний сервера Memory, кэш результатов частых запросов, — логично разместить в Managed PostgreSQL для структурированных данных и Redis для быстрого кэша и хранения сессий. Оба сервиса управляемые, что снимает с команды задачу администрирования репликации и резервного копирования баз данных, на которых держится MCP-инфраструктура.

Файлы, которые MCP Server раскрывает через Resources — документы, логи, артефакты сборки, — хранятся в Object Storage, S3-совместимом хранилище. Это снимает с сервера ответственность за файловую систему и даёт единую точку доступа для нескольких серверов сразу, если им нужно читать одни и те же документы.

Перед слоем MCP-серверов имеет смысл поставить API Gateway в связке с IAM (Identity and Access Management). Здесь выполняется первичная авторизация запросов от клиентов, маршрутизация к нужному серверу и, если требуется, ограничение частоты запросов. IAM управляет ролями и правами доступа на уровне облачной инфраструктуры, что дополняет OAuth 2.1-авторизацию на уровне самого MCP-протокола — получается два слоя проверки вместо одного.

Load Balancer распределяет нагрузку между репликами MCP-серверов при росте числа одновременных запросов от AI-агентов, а Virtual Private Cloud изолирует всю инфраструктуру MCP-серверов и связанных баз данных от публичного интернета — снаружи доступен только API Gateway, внутренние компоненты общаются в приватной сети.

Есть и отдельная причина держать MCP-инфраструктуру внутри контролируемого облачного периметра, а не полагаться на внешние SaaS-серверы, — регуляторный контекст. В Казахстане с 18 января 2026 года действует Закон Республики Казахстан № 230-VIII «Об искусственном интеллекте», подписанный 17 ноября 2025 года. Он закрепляет принципы безопасности, прозрачности и ответственности при использовании систем искусственного интеллекта, требования к защите персональных данных в ИИ-системах и меры против несанкционированного доступа к ним. Для компании, которая подключает MCP-серверы к системам с персональными данными клиентов (CRM, Service Desk, биллинг), это прямой аргумент в пользу локализации инфраструктуры внутри страны и контролируемого периметра, а не распределения серверов по внешним облачным сервисам без ясной юрисдикции.

Когда MCP действительно нужен

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

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

Обратная сторона: если нужно подключить модель к одному внешнему API и сценарий не собирается меняться, чаще хватает обычного function calling без выделенного слоя MCP-серверов. Разворачивать хост, клиента, отдельный сервер, слой авторизации и мониторинг ради единственной интеграции — избыточная инженерная нагрузка, которая не окупается. MCP раскрывает ценность там, где число систем и моделей растёт и повторное использование одних и тех же серверов для разных клиентов становится ощутимым.

Заключение

Model Context Protocol не заменяет REST API и не отменяет привычные способы интеграции систем между собой — он решает другую задачу: даёт языковой модели единый, предсказуемый способ обращаться к внешним данным и инструментам, вместо того чтобы каждая пара «модель плюс система» обрастала своим кодом. За два с половиной года с момента анонса протокол прошёл путь от инициативы одной компании до проекта под управлением Agentic AI Foundation при поддержке крупных игроков рынка. К концу 2025 года MCP вышел за рамки эксперимента: официальный реестр серверов запущен в сентябре 2025 года, а спецификация продолжает развиваться — стабильная ревизия 2025-11-25, следующая готовится к выпуску.

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