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

> Как устроено соединение между ИИ-приложением и сервером MCP и что изменилось с переходом на протокол без состояния.

Ревизия MCP 2026-07-28 · проверено 03.10.2026 · https://mcpprotocol.ru/architecture/

## Участники

В MCP три роли. [Хост](https://mcpprotocol.ru/glossary/#host) — ИИ-приложение, с которым работает пользователь. [Клиент](https://mcpprotocol.ru/glossary/#client) — компонент хоста, который держит связь с одним сервером. [Сервер](https://mcpprotocol.ru/glossary/#server) — программа, которая предлагает инструменты, ресурсы и шаблоны запросов.

_Хост создаёт по клиенту на каждый подключённый сервер. Серверы сами обращаются к файлам, базам данных и внешним сервисам._

Протокол взял идею у Language Server Protocol: так же, как тот стандартизирует поддержку языков программирования в редакторах, MCP стандартизирует подключение контекста и инструментов к ИИ-приложениям. Сообщения передаются в формате [JSON-RPC 2.0](https://mcpprotocol.ru/glossary/#json-rpc).

## Транспорты

Транспорт определяет, как сообщения доходят от клиента до сервера. Сейчас действуют два транспорта, ещё один устарел.

**Транспорты MCP**

| Транспорт | Для чего | Как устроен | Статус |
|---|---|---|---|
| [stdio](https://mcpprotocol.ru/glossary/#stdio) | Локальные серверы | Хост запускает сервер как процесс и обменивается сообщениями через стандартные потоки | Действует |
| [Streamable HTTP](https://mcpprotocol.ru/glossary/#streamable-http) | Удалённые серверы | Запросы HTTP POST на адрес сервера, ответ обычный или потоковый | Действует |
| [HTTP+SSE](https://mcpprotocol.ru/glossary/#http-sse) | Удалённые серверы | Прежний транспорт с двумя адресами | Устарел [УСТАРЕЛО]устарело |

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

Главное изменение ревизии 2026-07-28: протокол больше не хранит состояние соединения. Рукопожатие `initialize` и заголовок `Mcp-Session-Id` удалены, каждый запрос несёт всё необходимое сам.

_Слева: до 2026-07-28 клиент сначала согласовывал сессию. Справа: каждый запрос самодостаточен, поэтому его может обработать любой экземпляр сервера за обычным балансировщиком._

- Каждый запрос содержит версию протокола (заголовок `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. Благодаря им шлюз, ограничитель запросов или файервол могут маршрутизировать и учитывать вызовы, не разбирая тело.

## Многошаговые запросы

Раньше серверу, которому не хватало данных, приходилось самому отправлять запрос клиенту по открытому потоку: спросить пользователя, обратиться к модели, запросить корневые каталоги. Для протокола без состояния это не подходит.

Теперь действует схема [многошагового запроса](https://mcpprotocol.ru/glossary/#mrtr) (MRTR). Сервер возвращает результат типа `input_required` и перечисляет, что ему нужно. Клиент получает ответы — например, спрашивает пользователя — и повторяет исходный запрос, добавив их в поле `inputResponses`. Каждый результат теперь содержит обязательное поле `resultType`: `complete` для обычного ответа или `input_required` для промежуточного.

## Кэширование и уведомления

Списки инструментов, шаблонов и ресурсов, а также чтение ресурса теперь содержат `ttlMs` и `cacheScope`. Клиент использует их, чтобы не запрашивать список заново без нужды, а промежуточные узлы знают, можно ли хранить ответ общим.

Сервер должен возвращать инструменты в одном и том же порядке: это помогает кэшировать список и стабильно использовать кэш запросов к модели. Об изменениях сервер сообщает через единый поток `subscriptions/listen`, на который клиент подписывается по типам уведомлений.

## Расширения

Всё, что не входит в ядро, оформляется как [расширение](https://mcpprotocol.ru/glossary/#extension): клиент и сервер объявляют поддержку явно. В ревизии 2026-07-28 к ним относятся:

- **Tasks** (`io.modelcontextprotocol/tasks`) — долгие операции с опросом состояния;
- **MCP Apps** — интерактивные элементы интерфейса в диалоге;
- **Enterprise Managed Authorization** — корпоративное управление доступом.

Кроме того, рабочая группа развивает «Skills over MCP» — передачу структурированных инструкций для сценариев агента через MCP; в спецификации это пока не расширение ядра.