MCP переходит в stateless-режим: спецификация наконец-то устраняет последний корпоративный барьер

Новая редакция протокола Model Context Protocol снимает требование к сессиям с сохранением состояния — то, что делало MCP неудобным для масштабирования за балансировщиком нагрузки. Небольшое изменение на бумаге; значительное — в развёртывании.

Простыми словами. Model Context Protocol — спецификация, позволяющая ИИ-ассистентам вызывать внешние инструменты — выпустил обновление, которое убирает требование о сохранении состояния соединения между клиентом и сервером. Это то изменение, которого ждали команды инфраструктуры предприятий.

Почему сохранение состояния было проблемой

Изначальная транспортировка MCP предполагала постоянную сессию клиент-сервер. Если ассистенту требовался вызов инструмента, ассистент и инструмент делили живой канал на время взаимодействия. Это было нормально на ноутбуке; неудобно в масштабах.

Неудобства проявляются, как только вы ставите балансировщик нагрузки перед системой. Сохранение состояния означает, что каждый последующий вызов должен попадать на тот же бэкенд-инстанс. Это убивает самый дешёвый шаблон развёртывания в инфраструктуре предприятий — распределять запросы по безсостоятельному пулу, автоскейлить при нагрузке, терпеть потерю узлов. Приходится изобретать костыли для привязки сессий, sticky-маршрутизацию или, что хуже, менеджеров соединений, которые сами становятся едиными точками отказа.

Что именно меняет новая спецификация

Согласно отчётам, обновлённая транспортировка позволяет серверам заявлять о поддержке безсостоятельного режима. На практике:

# до (перефразировано)
POST /mcp/session → session_id
POST /mcp/call { session_id, tool, args } # должен попасть на тот же узел
POST /mcp/close { session_id }

# после — безсостоятельный режим
POST /mcp/call { tool, args, ctx } # любой узел, без сессии

ctx — это то, что переносит всё, что нужно серверу о предыдущих ходах, передаваемое клиентом. Это тот же шаблон, который REST API выбрали двадцать лет назад — безсостоятельность за счёт чуть более крупных запросов.

Под капотом: компромисс, который теперь ваш

Безсостоятельность не бесплатна. Две вещи переходят на клиент:

• Управление контекстом. Клиент теперь становится источником истины для любого состояния по разговору, которое нужно инструменту. Более крупные полезные нагрузки и новый класс багов: забыть передать контекст.
• Идемпотентность. Теперь любой узел может обрабатывать любой вызов, поэтому повторные попытки становятся возможными в большем количестве мест. Авторам инструментов нужно делать свои вызовы идемпотентными или мириться с двойным исполнением.

Для большинства корпоративных развёртываний эта плата оправдана. Для низколатентных ассистентов, где важны байты в пути, это реальная цена.

Что это сигнализирует

В обсуждениях экосистемы MCP речь шла о том, что инфраструктура созревает от «качества прототипа» до «мы можем поставить это за SRE-командой». Безсостоятельная транспортировка — это конкретный шаг в этом направлении. Она также говорит о том, где, по мнению авторов спецификации, находится рост: внутри предприятий, за прокси, а не на отдельных машинах разработчиков.

Итак

Для разработчика: если вы выпустили интеграцию MCP и столкнулись с проблемами привязки сессий, исправление теперь одобрено спецификацией, а не является самодельным. Для лица, принимающего решения: MCP стал удобным для закупок. Ожидайте, что вендоры будут рекламировать «MCP-native» так же, как раньше рекламировали «REST-native».