Что такое MCP (Model Context Protocol) и как он работает

Что такое MCP? Объясняем Model Context Protocol

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

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

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

Что такое MCP?

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

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

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

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

Согласно официальной спецификации MCP, протокол использует JSON-RPC 2.0 и поддерживает локальные и удалённые интеграции.

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

Архитектура MCP состоит из трёх основных компонентов:

Рассмотрим ИИ-ассистента, подключённого к платформе электронной коммерции.

Пользователь спрашивает: «Какой статус у заказа 1024?»

Хост-приложение управляет диалогом, а его MCP-клиент взаимодействует с соответствующим MCP-сервером. Сервер предоставляет инструмент, например get_order_status, который внутри обращается к API платформы электронной коммерции.

Процесс выглядит следующим образом:

1. Клиент получает список доступных инструментов сервера.
2. ИИ-приложение определяет, что для запроса подходит инструмент get_order_status.
3. Хост применяет правила авторизации и подтверждения действий.
4. Клиент отправляет запрос к инструменту, передавая идентификатор заказа.
5. Сервер обращается к соответствующей системе и возвращает результат.
6. ИИ-приложение использует полученную информацию для ответа пользователю.

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

Здесь важно понимать следующее: MCP стандартизирует взаимодействие, но ответственность за бизнес-логику и контроль доступа остаётся на стороне основного приложения.

Инструменты, ресурсы и промпты

MCP-сервер может предоставлять три основных типа возможностей.

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

Resources (ресурсы) предоставляют информацию, идентифицируемую с помощью URI. Благодаря им приложения могут получать необходимый контекст без необходимости оформлять каждую операцию чтения данных как отдельную команду.

Prompts (промпты) предоставляют заранее подготовленные сценарии работы или инструкции, которые клиенты могут получать и адаптировать под свои задачи.

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

MCP, API и Function Calling: различия

MCP часто сравнивают с REST API, вызовом функций ИИ (function calling) и Retrieval-Augmented Generation (RAG). Эти технологии связаны между собой, но решают разные задачи.

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

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

Таким образом, эти технологии дополняют друг друга, а не являются взаимозаменяемыми.

INTERNAL LINK: REST API vs GraphQL: Understanding Application Integrations

INTERNAL LINK: What Is RAG? Retrieval-Augmented Generation Explained

Практический пример интеграции MCP

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

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

Такой сервер может предоставлять следующие инструменты:

• find_customer — получение данных клиента в пределах разрешённого доступа.
• get_order_status — получение актуальной информации о заказе.
• create_support_ticket — создание нового обращения в службу поддержки.

У каждого инструмента есть определённое имя, описание и схема входных данных.

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

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

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

Как MCP работает на техническом уровне

MCP использует сообщения JSON-RPC 2.0 для представления операций, таких как tools/list, resources/read и tools/call.

Официальная спецификация определяет два стандартных транспорта:

• stdio: взаимодействие с локальным дочерним процессом через стандартные потоки ввода и вывода.
• Streamable HTTP: взаимодействие с удалённым эндпоинтом с помощью HTTP POST-запросов, при котором ответы могут передаваться в формате JSON или через Server-Sent Events в рамках отдельного запроса.

В спецификации от 2026-07-28 в MCP было введено stateless-ядро протокола — механизм, не зависящий от сохранения состояния между запросами. Запросы содержат информацию о версии протокола и доступных возможностях вместо зависимости от процедуры начальной инициализации, использовавшейся в предыдущих версиях.

Например, запрос tools/call определяет вызываемый инструмент по имени и передаёт его аргументы. Согласно протоколу версии 2026-07-28, запрос также содержит обязательные метаданные. Клиенты, использующие Streamable HTTP, дополнительно отправляют HTTP-заголовки, включая MCP-Protocol-Version, Mcp-Method и Mcp-Name.

Сервер может сообщать о поддерживаемых версиях и возможностях через server/discover.

Такая архитектура упрощает развёртывание удалённых MCP-серверов с использованием стандартной HTTP-инфраструктуры. Однако разработчикам необходимо внимательно проверять совместимость при работе с клиентами или SDK, созданными для более ранних версий протокола.

Полные требования к сообщениям описаны в спецификации Streamable HTTP.

Безопасность и ограничения MCP

Стандартизация интеграций не означает, что они автоматически становятся безопасными.

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

Разработчикам следует учитывать несколько основных рисков:

• Авторизация: проверяйте права доступа для каждого запроса и каждой операции.
• Принцип минимальных привилегий: предоставляйте доступ только к инструментам и данным, необходимым для конкретного сценария.
• Prompt injection: рассматривайте внешние документы и ответы инструментов как недоверенную информацию, а не как обязательные к исполнению инструкции.
• Подтверждение человеком: требуйте явного подтверждения для чувствительных или потенциально разрушительных операций.
• Защита учётных данных: обеспечивайте безопасность токенов, проверяйте, для какого получателя они предназначены, и не допускайте их ненужного раскрытия.
• Наблюдаемость (observability): регистрируйте значимые вызовы инструментов, ошибки и решения об авторизации, не раскрывая при этом секретные данные.

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

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

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

INTERNAL LINK: API Security Best Practices for Modern Web Applications

Когда стоит использовать MCP?

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

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

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

В официальном руководстве по разработке MCP-сервера приведены примеры реализации с использованием поддерживаемых SDK.

Часто задаваемые вопросы

MCP — это API?

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

Требуется ли LLM для работы MCP?

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

MCP и RAG — это одно и то же?

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

Может ли MCP подключаться к приватным базам данных?

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

MCP работает с любым ИИ-ассистентом?

Не автоматически. ИИ-приложение должно поддерживать MCP, а обе стороны интеграции — совместимые функции протокола, способы передачи данных и требования к аутентификации.

Заключение

Model Context Protocol предоставляет единый способ взаимодействия ИИ-приложений с существующим программным обеспечением.

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

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

Источники

При подготовке статьи использовались следующие первичные источники. Основное внимание уделено спецификации MCP от 28 июля 2026 года.

1. Model Context Protocol — Official Specification, 2026-07-28.
2. Model Context Protocol — Architecture.
3. Model Context Protocol — Tools.
4. Model Context Protocol — Resources.
5. Model Context Protocol — Prompts.
6. Model Context Protocol — Streamable HTTP.
7. Model Context Protocol — Authorization.
8. Model Context Protocol — Authorization Security Considerations.
9. Model Context Protocol — Build an MCP Server.
10. David Soria Parra and Den Delimarsky — The 2026-07-28 Specification, 28 июля 2026 года.