MCP Docs ревизия 2026-07-28

Начало / Введение

Введение

Зачем нужен MCP и как он устроен

ПереводОснова: Архитектура MCP (документация 2026-07-28)Сверено 05.10.2026, ревизия 2026-07-28Открыть .md

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

Из чего состоит проект#

  • Спецификация MCP. Требования к реализации клиентов и серверов.
  • SDK. Библиотеки для разных языков программирования, реализующие протокол.
  • Инструменты разработки. Например, MCP Inspector для проверки серверов.
  • Эталонные серверы. Примеры реализаций серверов MCP.

Участники#

MCP построен по схеме «клиент — сервер». ИИ-приложение, например Claude Code или Claude Desktop, подключается к одному или нескольким серверам MCP. Для каждого сервера приложение создаёт отдельного клиента, и у каждой пары «клиент — сервер» своё соединение.

  • Хост MCP (host). ИИ-приложение, которое подключается к серверам MCP и координирует одного или нескольких клиентов. В глоссарии MCP (host). ИИ-приложение, которое координирует одного или нескольких клиентов.
  • Клиент MCP (client). Компонент хоста, который держит соединение с одним сервером MCP и получает от него контекст для хоста. В глоссарии MCP (client). Компонент, который держит соединение с сервером и получает от него контекст для хоста.
  • Сервер MCP (server). Программа, которая предоставляет контекст клиентам. Бывает локальной (stdio) и удалённой (Streamable HTTP). В глоссарии MCP (server). Программа, которая предоставляет контекст клиентам.

Например, Visual Studio Code выступает хостом. Когда он подключается к серверу Sentry, среда выполнения создаёт клиента для этого соединения. Подключение ко второму серверу, например к серверу файловой системы, создаёт второго клиента.

Слово «сервер» относится к программе, которая отдаёт контекст, и не говорит, где она запущена. Локальный сервер работает на той же машине и использует транспорт stdio, а удалённый сервер работает на чужой платформе и использует Streamable HTTP. Локальный сервер обычно обслуживает одного клиента, удалённый — многих.

Два слоя#

Два слоя MCP. Схема по описанию архитектуры в официальной документации.

  • Слой данных определяет протокол обмена на основе JSON-RPC 2.0: обнаружение (server/discover), возможности сервера (инструменты, ресурсы, шаблоны), возможности клиента, служебные функции вроде уведомлений и отчётов о ходе работы.
  • Транспортный слой определяет каналы обмена: установку соединения, обрамление сообщений и авторизацию. Формат сообщений JSON-RPC 2.0 одинаков для всех транспортов.

Концептуально слой данных внутренний, а транспортный внешний. Транспорты описаны на странице «Транспорты».

Три примитива сервера#

Примитивы определяют, что клиенты и серверы могут предложить друг другу. Сервер может открыть три основных примитива.

Примитив Что это Кто управляет
Инструменты (tools). Функции с типизированными входом и выходом, которые приложение вызывает по решению модели: операции с файлами, вызовы API, запросы к базам данных. В глоссарии (tools) Функции, которые приложение вызывает, чтобы выполнить действие: операции с файлами, вызовы API, запросы к базам данных. Модель
Ресурсы (resources). Источники данных для чтения, которые определяет URI: файлы, записи баз данных, ответы API. Дают приложению контекст. В глоссарии (resources) Источники данных, которые дают приложению контекст: содержимое файлов, записи баз данных, ответы API. Приложение
Шаблоны запросов (prompts). Параметризованные заготовки, которые пользователь вызывает явно: например, через слэш-команду. В глоссарии (prompts) Готовые шаблоны, которые помогают структурировать взаимодействие с моделью: системные подсказки, примеры. Пользователь

У каждого примитива есть методы обнаружения (*/list), получения (*/get, resources/read) и, для инструментов, выполнения (tools/call). Благодаря */list перечни могут быть динамическими. Подробно: «Понятия».

Что у клиента#

Клиент может открыть серверу Запрос данных у пользователя (elicitation). Способ, которым сервер просит у пользователя недостающие данные или подтверждение действия. С ревизии 2026-07-28 строится на многошаговых запросах. В глоссарии (elicitation): так сервер просит недостающие данные или подтверждение действия. Начиная с версии 2026-07-28 такие запросы доставляются по шаблону Многошаговый запрос (MRTR). Схема, по которой сервер возвращает промежуточный результат input_required, а клиент повторяет исходный запрос, добавив ответы. В глоссарии (MRTR), описанному на странице «Шаблоны обмена».

Устарели с версии 2026-07-28 и не рекомендованы для новых реализаций: сэмплинг (sampling, запрос ответа языковой модели у клиента), корневые каталоги (roots) и журналирование (logging, передача журналов клиенту). Подробнее: «Миграция».

MCP и A2A#

MCP подключает агента к инструментам и данным, а A2A связывает агентов между собой. Протоколы дополняют друг друга. Сравнение, таблица различий и типичные заблуждения: страница «MCP и A2A» справочника mcpprotocol.ru (то же со стороны A2A: a2aprotocol.ru).

Что читать дальше#