Участники#
В MCP три роли. Хост — ИИ-приложение, с которым работает пользователь. Клиент — компонент хоста, который держит связь с одним сервером. Сервер — программа, которая предлагает инструменты, ресурсы и шаблоны запросов.
Протокол взял идею у Language Server Protocol: так же, как тот стандартизирует поддержку языков программирования в редакторах, MCP стандартизирует подключение контекста и инструментов к ИИ-приложениям. Сообщения передаются в формате JSON-RPC 2.0.
Транспорты#
Транспорт определяет, как сообщения доходят от клиента до сервера. Сейчас действуют два транспорта, ещё один устарел.
| Транспорт | Для чего | Как устроен | Статус |
|---|---|---|---|
| stdio | Локальные серверы | Хост запускает сервер как процесс и обменивается сообщениями через стандартные потоки | Действует |
| Streamable HTTP | Удалённые серверы | Запросы HTTP POST на адрес сервера, ответ обычный или потоковый | Действует |
| HTTP+SSE | Удалённые серверы | Прежний транспорт с двумя адресами | Устарел устарело |
Запросы без состояния#
Главное изменение ревизии 2026-07-28: протокол больше не хранит состояние соединения. Рукопожатие initialize и заголовок Mcp-Session-Id удалены, каждый запрос несёт всё необходимое сам.
- Каждый запрос содержит версию протокола (заголовок
MCP-Protocol-Versionи поле в_meta), возможности клиента и, как правило, сведения о клиенте. - Если клиенту нужно узнать возможности сервера заранее, он вызывает метод
server/discover; сервер обязан его поддерживать. - При несовпадении версий сервер возвращает ошибку
UnsupportedProtocolVersion. - Если серверу нужно состояние между вызовами, он выдаёт явный идентификатор через инструмент, а модель передаёт его как обычный аргумент.
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: get_stock
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"get_stock","arguments":{"sku":"A-100"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}Заголовки Mcp-Method и Mcp-Name обязательны для запросов POST в Streamable HTTP. Благодаря им шлюз, ограничитель запросов или файервол могут маршрутизировать и учитывать вызовы, не разбирая тело.
Многошаговые запросы#
Раньше серверу, которому не хватало данных, приходилось самому отправлять запрос клиенту по открытому потоку: спросить пользователя, обратиться к модели, запросить корневые каталоги. Для протокола без состояния это не подходит.
Теперь действует схема многошагового запроса (MRTR). Сервер возвращает результат типа input_required и перечисляет, что ему нужно. Клиент получает ответы — например, спрашивает пользователя — и повторяет исходный запрос, добавив их в поле inputResponses. Каждый результат теперь содержит обязательное поле resultType: complete для обычного ответа или input_required для промежуточного.
Кэширование и уведомления#
Списки инструментов, шаблонов и ресурсов, а также чтение ресурса теперь содержат ttlMs и cacheScope. Клиент использует их, чтобы не запрашивать список заново без нужды, а промежуточные узлы знают, можно ли хранить ответ общим.
Сервер должен возвращать инструменты в одном и том же порядке: это помогает кэшировать список и стабильно использовать кэш запросов к модели. Об изменениях сервер сообщает через единый поток subscriptions/listen, на который клиент подписывается по типам уведомлений.
Расширения#
Всё, что не входит в ядро, оформляется как расширение: клиент и сервер объявляют поддержку явно. В ревизии 2026-07-28 к ним относятся:
- Tasks (
io.modelcontextprotocol/tasks) — долгие операции с опросом состояния; - MCP Apps — интерактивные элементы интерфейса в диалоге;
- Enterprise Managed Authorization — корпоративное управление доступом.
Кроме того, рабочая группа развивает «Skills over MCP» — передачу структурированных инструкций для сценариев агента через MCP; в спецификации это пока не расширение ядра.