Новая спецификация MCP от 28.07.2026 отказывается от всех требований к состоянию сессии (session-state), позволяя каждому запросу нести все необходимые ему данные. Переход к протоколу без сохранения состояния (stateless) означает, что разработчики могут разворачивать отдельный экземпляр на каждый вызов, запускать его на serverless-функциях или edge-узлах и отказаться от старых механизмов «липкой» маршрутизации (sticky routing) и общих хранилищ (shared-store), которые всегда были головной болью при развертывании.

От рукопожатий к автономным вызовам

До сих пор протокол Model Context Protocol (MCP) требовал выполнения рукопожатия (handshake) для выдачи ID сессии. Серверы должны были помнить этот ID на протяжении всего времени соединения, что на практике означало необходимость поддерживать процессы в активном состоянии, реплицировать состояние в кластере Redis или настраивать балансировщики нагрузки для «липкой» маршрутизации. Результатом был сложный и ресурсоемкий стек, который затруднял масштабирование и делал горизонтальный рост дорогим.

Новая спецификация делает каждый запрос автономным. Каждый payload включает версию протокола и идентификатор вызывающей стороны, поэтому сервер может обрабатывать запрос как разовую транзакцию. Никаких хранилищ сессий, никаких долгоживущих процессов, никаких специальных правил маршрутизации.

Почему stateless важен для развертывания

  • Готовность к serverless и edge-вычислениям — запрос несет в себе всё необходимое, поэтому функция может запуститься, ответить и завершиться без необходимости предварительного прогрева состояния. Провайдеры, использующие оплату за каждый вызов, становятся жизнеспособным вариантом для рабочих нагрузок MCP.
  • Упрощенная балансировка нагрузки — стандартные балансировщики L4/L7 могут равномерно распределять трафик; больше нет необходимости привязывать клиента к конкретному бэкенду.
  • Снижение эксплуатационных расходов — команды могут отказаться от кластеров Redis или кастомного кода для репликации сессий, сокращая как затраты, так и поверхность возможных отказов.

Для организаций, которые уже используют MCP за балансировщиком нагрузки, это изменение устраняет необходимость в правилах «sticky routing», которые часто приводят к неравномерному распределению трафика. Экономия особенно заметна для высокопроизводительных сервисов, обрабатывающих миллионы вызовов в день.

Улучшения производительности и безопасности

Спецификация добавляет конкретные улучшения, которые усиливают протокол помимо его stateless-природы:

  • Кэширование на основе TTL — списки инструментов (tools) и промптов теперь включают поле time-to-live, что позволяет клиентам кэшировать результаты локально и избегать лишних циклов запросов.
  • Маршрутизация на основе заголовков — новые HTTP-заголовки раскрывают информацию о маршрутизации на раннем этапе, позволяя шлюзам перенаправлять трафик без парсинга всего тела JSON, что экономит миллисекунды задержки.
  • Усиление OAuth/OIDC — токены идентификации проходят более строгие проверки OAuth и OpenID Connect, что снижает риск атак повторного воспроизведения (replay attacks) и кражи токенов.
  • Формальный фреймворк расширений — задачи (Tasks) и приложения (Apps) теперь относятся к определенной модели расширений, что упрощает внедрение новых функций для мейнтейнеров SDK.

Влияние на разработчиков

Экосистема SDK уже отражает эти изменения: библиотеки для TypeScript, Python, Go и C# поддерживают новый формат запросов. Суммарное количество скачиваний этих SDK приближается к полумиллиарду в месяц, что в четыре раза больше, чем в начале года, — это указывает на широкое внедрение MCP.

Разработчикам необходимо адаптировать любой код, который полагался на постоянную сессию. Обычно это означает перенос данных, специфичных для сессии, в payload запроса или во внешнее хранилище, к которому обращаются при каждом вызове. Окно миграции составляет двенадцать месяцев, что дает командам время на рефакторинг, тестирование и внедрение нового паттерна.

Контраргумент: сложность миграции

Stateless-подход не является бесплатным бонусом. Приложениям, которые ранее полагались на состояние на стороне сервера для таких вещей, как прогрессивная история диалога, теперь приходится управлять этим состоянием на стороне клиента или через отдельный слой хранения данных.

На что обратить внимание

  • Метрики внедрения — следите за темпами обновления версий SDK; замедление может сигнализировать о трудностях при миграции.
  • Поддержка edge-платформ — по мере того как всё больше провайдеров анонсируют среды выполнения, совместимые с MCP, реальная выгода от использования serverless станет очевидной.
  • Отчеты об инцидентах безопасности — усиленный поток OAuth/OIDC должен снизить количество атак на идентификацию, но любое нарушение безопасности станет проверкой новых защитных механизмов.

Итог: Делая MCP stateless, спецификация приводит протокол в соответствие с современными облачными (cloud-native) паттернами, избавляя от эксплуатационного багажа управления сессиями и открывая двери для более дешевых и эластичных моделей развертывания. Обратной стороной являются кратковременный период рефакторинга кода и увеличение объема передаваемых данных в запросах, но долгосрочная выгода — это протокол, который масштабируется так же легко, как и инфраструктура, на которой он работает.