MCP растёт с редкой для инфраструктурного стандарта скоростью. После релиза в ноябре прошлого года ежемесячное число загрузок SDK первого уровня приблизилось к полумиллиарду, а суммарные загрузки SDK для TypeScript и Python уже превысили миллиард. За считаные месяцы Model Context Protocol стал заметной опорой для данных, инструментов и взаимодействий в агентных сценариях.
Сегодня опубликована новая редакция спецификации MCP — 2026-07-28. Вместе с ней выходят обновлённые SDK, так что к разработке MCP-клиентов и серверов можно приступать сразу, без долгой паузы между стандартом и практикой.
Главное изменение — ядро без сохранения состояния. MCP уходит от двунаправленного протокола с сохранением состояния к модели независимых запросов и ответов. Для команд, которым нужна отказоустойчивая схема агентного слоя под горизонтальное масштабирование MCP-серверов, это, пожалуй, ключевая новость релиза.
Вкратце, новая версия приносит следующее:
- Каждый запрос теперь самодостаточен. Клиент при необходимости вызывает необязательный метод обнаружения возможностей, а затем любой запрос можно отправить на любой экземпляр сервера за обычным балансировщиком round-robin.
- Метод и имя инструмента передаются в HTTP-заголовках
Mcp-MethodиMcp-Name. Шлюзы могут маршрутизировать запросы и применять правила доступа, не разбирая JSON-тело. - Серверные запросы к клиенту — например, для sampling и elicitation — заменены механизмом Multi Round-Trip Requests (MRTR). Постоянно открытый двунаправленный поток больше не обязателен.
- Списки инструментов, промптов и ресурсов получили параметры кэширования и детерминированный порядок. Это уменьшает число повторных обращений и помогает сохранять стабильность кэша промптов.
- Инфраструктура расширений закреплена формально: Tasks дополняет MCP Apps и Enterprise Managed Authorization (EMA).
- Усилены механизмы авторизации: добавлена проверка issuer по RFC 9207 и начат официальный переход от DCR к Client ID Metadata Documents (CIMD).
- Введена политика устаревания: функции будут поддерживаться минимум 12 месяцев. Планировать миграцию становится проще — без пожарного режима в пятницу вечером.
SDK для TypeScript, Python, Go и C# уже приведены в соответствие со спецификацией. Для изменений, нарушающих совместимость, опубликованы подробные рекомендации по миграции.
Что изменилось
Без инициализации и сессий
Спецификация официально отказывается от пары сообщений initialize/initialized и заголовка Mcp-Session-Id — см. SEP-2575 и SEP-2567. Каждый запрос теперь передаёт в _meta версию протокола, сведения о клиенте и его возможности.
Если до вызова инструмента клиенту нужно узнать возможности сервера, он может использовать новый RPC-метод server/discover. Но это именно опция, не обязательный ритуал. Благодаря этому запросы без общего хранилища состояния распределяются между экземплярами сервера за стандартным балансировщиком нагрузки.
POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
{"jsonrpc":"2.0","id":1,"method":"tools/call",
"params":{"name":"search","arguments":{"q":"otters"},
"_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}копироватьПри этом транспорт без сохранения состояния не заставляет само приложение быть «без памяти». Когда серверу необходимо сохранить контекст между вызовами, инструмент создаёт явный дескриптор (handle), который модель передаёт в следующем вызове. Такой подход часто прозрачнее скрытого состояния сессии: модель видит дескриптор и может передавать его между инструментами. Для сложных сценариев полезно отдельно продумать стратегию хранения контекста между вызовами инструментов — протокол сам по себе её не заменяет.
Многошаговые запросы (MRTR)
MRTR заменяет инициируемые сервером вызовы elicitation/create, sampling/createMessage и roots/list, которым раньше требовалось удерживать соединение открытым.
Бывает, что инструмент посреди выполнения должен спросить пользователя: подтвердить действие, уточнить недостающий параметр, согласовать стоимость. Механизм MRTR из SEP-2322 решает эту задачу в модели без сохранения состояния: сервер отвечает с resultType: "input_required" и перечнем нужных ответов, а клиент повторяет исходный вызов, добавив данные в inputResponses.
Маршрутизация по заголовкам
Запросы Streamable HTTP теперь обязаны содержать Mcp-Method и Mcp-Name — подробнее в SEP-2243. API-шлюз, rate limiter или WAF получает возможность маршрутизировать трафик, вести учёт и применять политики до разбора JSON. Это практичная деталь, особенно когда контроль агентного трафика на периметре должен работать на уровне инфраструктуры, а не задним числом.
Кэширование результатов списков
Ответы методов tools/list, prompts/list, resources/list и resources/read теперь включают ttlMs и cacheScope (SEP-2549). Клиент может выбрать подходящую стратегию кэширования, реже дёргать сервер и не ломать стабильность внешнего кэша промптов при новых подключениях.
Авторизация
По отзывам разработчиков, интеграция авторизации остаётся одной из самых трудоёмких частей внедрения MCP. В редакции 2026-07-28 этой теме уделено заметно больше внимания — и это разумно.
- Серверы авторизации должны возвращать параметр
issпо RFC 9207, а клиент обязан проверить его до обмена кода (SEP-2468). Это снижает риск подмены сервера авторизации. - При Dynamic Client Registration клиент указывает
application_type. Благодаря этому серверы авторизации не должны отклонять перенаправления наlocalhostдля desktop- и CLI-приложений (SEP-837). - Учётные данные клиента жёстко привязаны к issuer, который их выпустил; повторно использовать их у другого сервера авторизации нельзя (SEP-2352).
- DCR официально объявлен устаревающим механизмом в пользу CIMD. Обратная совместимость пока сохранена, но новым реализациям стоит ориентироваться на Client ID Metadata Documents.
Для корпоративных внедрений это не мелкая техническая правка. Проверяемые цепочки идентификации, политики доступа и регламенты допуска ИИ к корпоративным данным становятся базовой частью эксплуатации агентных систем.
Задачи
Tasks переезжает из экспериментального ядра в расширение io.modelcontextprotocol/tasks. В нём доступны polling-метод tasks/get и новый tasks/update (SEP-2663). Уведомления об изменениях переносятся со старой конечной точки HTTP GET в единый поток subscriptions/listen; клиент подписывается отдельно на каждый тип уведомлений.
Устаревшие возможности
Roots, Sampling и Logging объявлены устаревшими (SEP-2577). Они продолжат работать минимум 12 месяцев, однако в новых реализациях их использовать не рекомендуется. Аналогичный годичный переходный период установлен для устаревшего транспорта HTTP+SSE.
SDK
На дату выпуска все четыре SDK уровня Tier 1 поддерживают спецификацию 2026-07-28:
Новая спецификация также доступна в бета-версии Rust SDK.
SDK позволяют создавать и MCP-серверы, и клиенты для новой редакции протокола. Как отмечалось в анонсе бета-версий SDK, миграция потребует усилий прежде всего там, где код зависел от идентификаторов сессий. Однако замечания ранних пользователей уже учтены, поэтому путь стал заметно ровнее.
Поддержка экосистемы
Крупный релиз MCP не появляется из воздуха. Его тестировали и проверяли участники сообщества, поставщики облачных платформ, разработчики SDK и компании, которые уже используют агентные приложения в промышленной эксплуатации.
Это важнейший релиз MCP со времени появления удалённого MCP. Он собирает уроки последних полутора лет, даёт масштабируемым серверам прочную основу и открывает дорогу новым расширениям.
Релиз показывает, что MCP становится инфраструктурой промышленного уровня. Сообщество выбрало сложную, но честную работу над совместимостью — именно этого ждали команды, строящие корпоративных агентов.
Ядро без сохранения состояния позволяет развёртывать MCP-серверы на обычной масштабируемой инфраструктуре без управления сессиями. Расширение Tasks добавляет основу для надёжных долгоживущих агентов.
MCP приближается к модели привычного веба: без состояния, с кэшированием, маршрутизацией и глобальным масштабированием. Поддержка в Agents SDK доступна с первого дня.
Архитектура без сохранения состояния масштабируется вместе с растущим использованием MCP-сервера Figma. MCP Apps, Tasks и управляемая корпоративная авторизация помогут ещё плотнее связать дизайн и код.
Переход к архитектуре без сохранения состояния снимает одно из главных препятствий для масштабного развёртывания агентных рабочих процессов и создаёт безопасную, расширяемую основу для нового поколения ИИ-приложений.
Почти 20% ежемесячных интерактивных запросов honeycomb.io уже выполняют агенты. Новая спецификация даёт возможность поддерживать более сложные сценарии в корпоративном масштабе.
MCP помогает Microsoft Foundry масштабироваться от десятков интеграций к тысячам. Операции без сохранения состояния, Tasks и управляемая предприятием идентификация упрощают создание защищённых систем промышленного уровня.
Протокол взрослеет благодаря обратной связи разработчиков и урокам, накопленным за десятилетия проектирования веб-протоколов. Самое интересное, как всегда, — увидеть неожиданные решения, которые появятся на его основе.
MRTR делает elicitation доступным для сервисов без сохранения состояния: инструмент может запросить подтверждение перед созданием платного проекта или выполнением операции удаления данных.

Ядро без сохранения состояния снижает инфраструктурную сложность и позволяет быстрее предоставлять клиентам новые возможности в большем масштабе.
С чего начать
Новая спецификация уже готова к использованию. Начните с первоисточников — это сбережёт немало времени при проектировании и миграции:
Если разбираться с миграцией на 2026-07-28 внутри команды некогда, мы развернём и обновим MCP-серверы под новую спецификацию — с авторизацией, маршрутизацией и мониторингом на нашей стороне.
Благодарности
Этот релиз не состоялся бы без большого сообщества участников и отраслевых партнёров: авторов спецификации, документации и SDK, рабочих групп и независимых сообществ по всему миру. Именно их практический опыт помогает MCP развиваться не в вакууме, а вокруг реальных задач разработки, эксплуатации и безопасности агентных систем.
