Архитектура MCP

MCP-сервер - отдельная программа, которая даёт AI-приложению инструменты, ресурсы и шаблоны запросов. Хост, клиент и сервер, сообщения JSON-RPC 2.0, редакция 2026-07-28

описана редакция 2026-07-28, сверено со спецификацией 4 октября 2026

Три роли

Спецификация описывает архитектуру «клиент - хост - сервер».

Роль	Что делает
Хост	AI-приложение. Создаёт клиентов, решает, каким серверам что разрешено, спрашивает согласие пользователя, работает с языковой моделью
Клиент	Часть хоста. Общается ровно с одним сервером и прикладывает к каждому запросу версию протокола и свои возможности
Сервер	Отдельная программа. Даёт инструменты, ресурсы и шаблоны запросов. Бывает локальным процессом или удалённым сервисом

Сервер не видит всю переписку пользователя с моделью и не видит другие серверы. Это принцип проектирования протокола: полная история остаётся у хоста, границы между серверами держит хост.

Сообщения

Все сообщения следуют JSON-RPC 2.0. Базовый протокол задаёт три вида сообщений.

Вид	Кто отправляет	Особенности
Запрос	клиент	есть `id` - строка или целое число, `null` запрещён
Ответ	сервер	тот же `id`; либо `result`, либо `error`
Уведомление	клиент или сервер	без `id`, отвечать на него нельзя

Сервер сам запросы не отправляет. Когда ему нужно что-то от клиента, он возвращает особый результат - об этом страница «Многошаговые запросы».

В каждом результате есть обязательное поле resultType: "complete" - запрос выполнен, "input_required" - серверу нужны дополнительные данные. Если поля нет (так отвечают серверы прежних редакций), клиент считает результат завершённым.

{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Запросы без состояния

Сервер обрабатывает каждый запрос независимо и не опирается на предыдущие, даже если они пришли по тому же соединению. Версию протокола и возможности клиента сервер берёт из поля _meta самого запроса. Подробности - на странице «Ядро без состояния».

Возможности

Клиент и сервер сообщают друг другу, что они умеют.

Клиент перечисляет свои возможности в каждом запросе, в поле _meta под ключом io.modelcontextprotocol/clientCapabilities.
Сервер сообщает свои возможности в ответе на запрос server/discover. Вызывать его клиент не обязан.
Сервер не должен рассчитывать на возможность, которую клиент не объявил. Если она нужна, сервер возвращает ошибку -32021.
Дополнительные функции подключаются через расширения.

Что даёт сервер

Примитив	Для кого	Страница
Tools	функции, которые вызывает модель	Tools
Resources	данные и контекст для пользователя или модели	Resources
Prompts	шаблоны сообщений, которые выбирает пользователь	Prompts

Клиент со своей стороны может дать серверу возможность спросить пользователя - это Elicitation.

Ещё три функции клиента и сервера - Roots, Sampling и Logging - в редакции 2026-07-28 объявлены устаревшими. Они работают, но новым реализациям их добавлять не рекомендуется. Список и сроки - на странице «Что устарело».

Что обязательно

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

Карта раздела

Вопрос	Страница
Какие бывают редакции и как стороны договариваются о версии	Редакции и версии
Что значит «без состояния» и что лежит в `_meta`	Ядро без состояния
Как узнать версии и возможности сервера	Обнаружение: server/discover
Как сообщения передаются по stdio и HTTP	Транспорты
Как сервер запрашивает данные у клиента	Многошаговые запросы
Что изменилось и как перейти	Переход на 2026-07-28
Как устроен доступ к удалённому серверу	Модель авторизации
Кому и что можно доверять	Модель доверия