Перезагрузка MCP, которая меняет всё

Первоначальный протокол MCP накладывал существенное архитектурное ограничение: неотъемлемую привязку к состоянию. Ранее клиент инициировал взаимодействие с помощью запроса initialize к MCP-эндпоинту. Затем сервер создавал и возвращал уникальный session ID — токен, критически важный для всего последующего общения между клиентом и сервером. Каждый последующий запрос обязан был содержать этот идентификатор.

Такая архитектура создавала фундаментальный изъян для масштабируемых развертываний. Обязательный session ID привязывал клиента к конкретному экземпляру сервера, который изначально обработал вызов initialize. Это нарушало стандартные парадигмы балансировки нагрузки. Если балансировщик, например, маршрутизатор round-robin, направлял последующий запрос на другой экземпляр, у этого сервера не было записей о сессии. Результатом была критическая ошибка 400 "session not found", останавливающая работу клиента. Аналогично, если экземпляр падал, все состояния его активных сессий мгновенно терялись, вызывая немедленные сбои клиентских запросов.

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

Новая спецификация MCP '2026-07-28' вводит радикальные изменения. Два ключевых предложения, SEP-2575 и SEP-2567, переопределяют ядро протокола. SEP-2575 исключает рукопожатие initialize и initialized, а SEP-2567 удаляет заголовок MCP-Session-Id и связанную с ним сессию на уровне протокола.

Эти изменения превращают многошаговый вызов инструмента в единый, самодостаточный HTTP-запрос. Раньше контекст был фрагментирован; теперь вся необходимая информация передается в поле meta внутри JSON-тела. Такая архитектура делает каждый запрос независимым, отражая принципы stateless HTTP.

Полная совместимость со стандартной HTTP-инфраструктурой достигнута. Новые заголовки MCP-Method и MCP-Name теперь несут критически важную информацию для маршрутизации. Это позволяет сетевым компонентам, таким как шлюзы, брандмауэры и ограничители частоты запросов, принимать решения без необходимости парсинга JSON-полезной нагрузки. Такая эффективность критически важна для производительности, особенно на Cloudflare.

Протокол больше не требует Durable Objects для работы с MCP, что упрощает развертывание. Сервисы могут масштабироваться до нуля в режиме простоя, что значительно снижает операционные расходы и расширяет возможности развертывания. Этот сдвиг устраняет проблемы «липких» сессий или общих экземпляров Redis, делая MCP по-настоящему stateless по умолчанию.

Отсутствие состояния (statelessness) открывает огромные преимущества для развертывания. Бессерверные платформы, такие как Cloudflare Workers и Google Cloud Run, теперь масштабируются до нуля в режиме простоя, радикально сокращая операционные расходы. Серверам больше не нужно поддерживать постоянные соединения, что исключает необходимость в постоянно работающих экземплярах для хранения состояния сессии. Это фундаментально меняет подход к предоставлению инфраструктуры.

Protocol больше не обременяет управление состоянием. Вместо этого состояние становится заботой уровня приложения. Инструменты могут создавать явные дескрипторы, например basket_id или browser_id. Затем модель передает этот идентификатор обратно в качестве обычного аргумента при последующих вызовах инструментов. Это дает разработчикам большую гибкость, позволяя им управлять состоянием именно так, как это необходимо, вместо того чтобы подстраиваться под шаблоны, навязанные протоколом.

MCP использует кэширование в стиле HTTP для повышения эффективности на стороне клиента. Новые подсказки time to live и cache scope информируют клиентов о свежести списков инструментов, промптов и ресурсов. Это позволяет клиентам уверенно кэшировать ответы, избегая постоянных соединений для обновлений. Для дальнейшего изучения надежного проектирования stateless API ознакомьтесь с Statelessness in API Design: Understanding & Examples - Unkey. Эти подсказки гарантируют, что клиенты точно знают, как долго данные остаются актуальными для пользователей.

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

Этот результат включает сериализованную полезную нагрузку request_state, инкапсулирующую весь контекст для ожидающего действия. Клиент получает input_required, запрашивает пользователя (например, «Вы уверены?»), а затем повторно инициирует исходный запрос. Клиент прикрепляет ответ пользователя и повторяет request_state. Это гарантирует, что клиент всегда управляет взаимодействием. Любой экземпляр сервера может подхватить возобновленный запрос, что усиливает принцип stateless.

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

Затем клиенты отслеживают прогресс асинхронно. Они могут опрашивать сервер с помощью tasks/get или подписаться через subscriptions/listen. Это позволяет получить окончательный результат после завершения длительной задачи. Такая архитектура устраняет необходимость в постоянных соединениях во время длительных вычислений, повышая эффективность и устойчивость протокола.

В чем заключалась основная проблема старого stateful MCP?

Старый протокол требовал идентификаторы сессий, которые привязывали клиентов к конкретным экземплярам сервера. Это затрудняло балансировку нагрузки, требовало сложных обходных путей, таких как «липкие» сессии (sticky sessions) или Redis, и делало систему хрупкой, так как перезапуск сервера мог привести к потере состояния сессии.

Как новый stateless MCP решает эти проблемы?

Он полностью исключает рукопожатия сессий и идентификаторы (спецификация 2026-07-28). Каждый запрос является самодостаточным, что позволяет использовать стандартную балансировку нагрузки round-robin, повышает устойчивость и дает возможность серверам масштабироваться до нуля, снижая затраты.

Как состояние управляется в новом MCP, если протокол является stateless?

Состояние теперь управляется на уровне приложения, а не на уровне протокола. Разработчики могут создать инструмент, который генерирует явный дескриптор (например, 'browser_id'), который модель передает обратно в последующих вызовах — это гибкий шаблон, распространенный в стандартных HTTP API.

Что происходит с длительными вызовами инструментов без постоянного соединения?

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