# Переход на редакцию 2026-07-28

> Что изменилось в MCP 2026-07-28 по сравнению с 2025-11-25 и что менять в сервере и клиенте - отказ от initialize и сессий, MRTR, новые заголовки, коды ошибок, кэш

Страница: https://mcpdoc.ru/protocol/migration/
Указатель сайта: https://mcpdoc.ru/llms.txt

Редакция `2026-07-28` несовместима с предыдущими: рукопожатия `initialize` и сессий больше нет, сервер не отправляет запросы клиенту, а каждый запрос несёт версию и возможности. Старый клиент с новым сервером не заработает, и наоборот - если одна из сторон не поддерживает обе эпохи.

сверено со списком изменений спецификации 4 октября 2026

Источник - [Key Changes](https://modelcontextprotocol.io/specification/2026-07-28/changelog) редакции `2026-07-28`. Ниже изменения сгруппированы по тому, что нужно сделать.

## Главное

| Было в `2025-11-25` | Стало в `2026-07-28` | Изменение |
|---|---|---|
| `initialize` и `notifications/initialized` | версия и возможности в `_meta` каждого запроса | SEP-2575 |
| сессии, заголовок `Mcp-Session-Id` | сессий нет; состояние - через явные идентификаторы в аргументах | SEP-2567 |
| сведения о сервере из ответа на `initialize` | обязательный для сервера запрос `server/discover` | SEP-2575 |
| сервер отправляет `elicitation/create`, `sampling/createMessage`, `roots/list` | сервер возвращает результат «нужны данные», клиент повторяет запрос | SEP-2322 |
| поток по GET, `resources/subscribe`, `resources/unsubscribe` | один запрос `subscriptions/listen` | SEP-2575 |
| `ping`, `logging/setLevel`, `notifications/roots/list_changed` | удалены | SEP-2575 |
| возобновление потока по `Last-Event-ID` | не поддерживается | SEP-2575 |
| Tasks в основном протоколе (экспериментально) | Tasks - отдельное расширение | SEP-2663 |

## Что менять в сервере

1. **Не ждать `initialize`.** Версию и возможности клиента брать из `_meta` запроса. Запрос без обязательных полей отклонять с кодом `-32602`. Подробнее - [«Ядро без состояния»](https://mcpdoc.ru/protocol/stateless/).
2. **Реализовать `server/discover`.** Это обязательный запрос. Формат - на странице [«Обнаружение»](https://mcpdoc.ru/protocol/discovery/).
3. **Не хранить состояние «по соединению».** Списки инструментов, ресурсов и шаблонов не должны зависеть от соединения. Если между вызовами нужно состояние, выдавать идентификатор и принимать его аргументом - см. [«Инструменты с состоянием»](https://mcpdoc.ru/protocol/tools/#инструменты-с-состоянием).
4. **Заменить запросы к клиенту на MRTR.** Вопрос пользователю и прочие обращения к клиенту вкладываются в результат. Порядок - [«Многошаговые запросы»](https://mcpdoc.ru/protocol/mrtr/).
5. **Добавить `resultType` во все результаты.** Значение `"complete"` для обычного результата.
6. **Добавить `ttlMs` и `cacheScope`** в результаты `tools/list`, `prompts/list`, `resources/list`, `resources/templates/list`, `resources/read` и `server/discover`.
7. **Проверять заголовки HTTP.** `MCP-Protocol-Version`, `Mcp-Method`, `Mcp-Name` обязаны совпадать с телом; при расхождении - `400` и код `-32020`. См. [«Транспорты»](https://mcpdoc.ru/protocol/transports/).
8. **Поменять код «ресурс не найден»** с `-32002` на `-32602`.
9. **Отвечать `405` на GET и DELETE** по адресу MCP, если сервер поддерживает только новую редакцию - это рекомендация спецификации.
10. **Журнал.** Сообщения `notifications/message` отправлять только по запросам, где клиент указал уровень в `_meta`. Сама функция Logging объявлена устаревшей - см. [«Что устарело»](https://mcpdoc.ru/protocol/deprecations/).
11. **Возвращать инструменты в постоянном порядке** - это рекомендация, она помогает кэшу.

## Что менять в клиенте

1. **Прикладывать `_meta` к каждому запросу:** версию и возможности обязательно, имя клиента - по рекомендации.
2. **На HTTP добавлять заголовки** `MCP-Protocol-Version`, `Mcp-Method` и, где нужно, `Mcp-Name`. Поддержка `x-mcp-header` для клиента обязательна.
3. **Обрабатывать `resultType`.** `"input_required"` - собрать ответы и повторить запрос с новым `id`. Отсутствие поля считать значением `"complete"`.
4. **Обрабатывать ошибку `-32022`:** выбрать версию из списка `supported` и повторить.
5. **Не возобновлять оборванный поток.** Отправить запрос заново с новым `id`.
6. **Отменять запрос на HTTP закрытием потока,** а не уведомлением.
7. **Для изменений списков открывать `subscriptions/listen`** вместо потока по GET.
8. **Принимать код `-32002`** от старых серверов наравне с `-32602`.

## Если нужно работать с обеими эпохами

Спецификация называет такую реализацию Dual-era и описывает, как определить эпоху второй стороны.

| Кто | Как действует |
|---|---|
| клиент на stdio | отправляет `server/discover`; при ошибке, не похожей на ошибку Modern, или при молчании переходит на `initialize` |
| клиент на HTTP | отправляет запрос в новом формате; при `400` без распознанной ошибки Modern переходит на `initialize` |
| сервер | запрос с `_meta` обслуживает без состояния; запрос `initialize` - по правилам согласованной старой редакции |

Сервер может обслуживать обе эпохи одновременно на одном адресе. Полная таблица исходов - на странице [«Редакции и версии»](https://mcpdoc.ru/protocol/versions/).

## Авторизация: что изменилось

| Изменение | Суть |
|---|---|
| Dynamic Client Registration объявлена устаревшей | предпочтительный способ - Client ID Metadata Documents; см. [«Регистрация клиента»](https://mcpdoc.ru/auth/client-registration/) |
| параметр `iss` в ответе авторизации | серверу авторизации следует его включать; клиент обязан проверить его, если он есть |
| учётные данные клиента привязаны к серверу авторизации | клиент обязан хранить их по идентификатору издателя и не использовать с другим сервером авторизации |
| `application_type` при динамической регистрации | клиент обязан указывать подходящее значение |

## Что устарело, но работает

Roots, Sampling, Logging и Dynamic Client Registration объявлены устаревшими в этой редакции; HTTP+SSE устарел раньше. Сроки и замены - на странице [«Что устарело»](https://mcpdoc.ru/protocol/deprecations/).

## Что проверить в своём SDK

Этот список описывает протокол, а не конкретную библиотеку. Какую редакцию и какую эпоху поддерживает ваш SDK, нужно смотреть в его документации и примечаниях к выпускам: спецификация этого не определяет.