Model Context Protocol, или MCP, перешёл на stateless-модель на уровне ядра протокола. Для команд, которые строят не демо, а рабочие AI-интеграции, это главный смысл релиза от 28 июля 2026 года: меньше зависимости от конкретной сессии, проще балансировка нагрузки, меньше боли при масштабировании на несколько серверов и сред.
Проще говоря, MCP убрал протокольную сессию и handshake, из-за которых удалённые развёртывания требовали sticky sessions и общего хранилища состояния. Для enterprise-сценариев это было узким местом. Теперь запрос можно обрабатывать на любом инстансе, если в нём уже есть все нужные данные.
Что именно изменилось в спецификации
Ключевая перемена в версии MCP 2026-07-28: протокол стал stateless на транспортном уровне. Из него убрали связку initialize/initialized и заголовок Mcp-Session-Id. Раньше клиент сначала создавал сессию, а потом должен был ходить в тот же серверный инстанс. Теперь запрос самодостаточен: версия протокола, сведения о клиенте и его возможностях передаются в каждом вызове.
На практике это означает более приземлённую вещь: удалённый MCP-сервер теперь можно ставить за обычный round-robin-балансировщик без sticky sessions. Для платформенных команд это разница между «красиво работает на стенде» и «это можно без стыда отдавать в прод».
Важно, что stateless здесь не означает полный отказ от состояния в приложении. Если серверу нужно помнить контекст между вызовами, он может вернуть явный идентификатор вроде basket_id или browser_id, а модель передаст его в следующем запросе уже как обычный аргумент. Состояние не исчезло, но перестало быть спрятано в транспортном слое.
Новые механики для маршрутизации, кэша и длинных операций
Вместе с новой архитектурой MCP получил несколько обновлений, которые выглядят сухо, но для эксплуатации важнее любого красивого демо. Транспорт Streamable HTTP теперь использует заголовки Mcp-Method и Mcp-Name, чтобы прокси, шлюзы и лимитеры могли маршрутизировать запросы без разбора тела. Это мелочь только на бумаге.
Ещё одно практическое изменение: ответы на списки и чтение ресурсов теперь могут нести ttlMs и cacheScope. То есть клиенту заранее говорят, как долго ответ считается свежим и можно ли делиться им между пользователями. Для нагруженных систем это прямой способ снизить лишние обращения и задержки.
Отдельно MCP переработал server-to-client взаимодействие через Multi Round-Trip Requests. Если серверу во время вызова нужно уточнение или подтверждение, он больше не держит постоянное соединение открытым. Вместо этого он возвращает структуру с запросом на ввод, а клиент повторяет исходный вызов уже с ответом пользователя. Для отказоустойчивости такая схема заметно удобнее старой модели с постоянным соединением.
Почему это важно для корпоративного рынка
В том же релизе протокол получил формальную политику устаревания: между объявлением функции устаревшей и её возможным удалением должно проходить как минимум 12 месяцев, кроме критических проблем безопасности. Для крупных компаний это почти обязательное условие. Никто не хочет пересобирать внутренние интеграции только потому, что мейнтейнеры решили резко поменять правила.
MCP также усилил авторизацию и вынес часть возможностей в расширения, а не в ядро спецификации. Это тоже взрослый шаг: базовый протокол становится проще, а новые функции можно развивать отдельно, не ломая всё сразу.
Для русскоязычной аудитории вывод довольно прикладной. Если команда собирает внутреннего AI-ассистента, поиск по базе знаний, интеграцию модели с CRM, репозиториями или сервис-деском, новый MCP снижает инфраструктурный налог на такие проекты. Особенно там, где уже есть Kubernetes, API-шлюзы, несколько дата-центров или жёсткие требования к отказоустойчивости. Иными словами, стандарт становится ближе не к лабораторным экспериментам, а к обычной корпоративной эксплуатации.
Следующий вопрос теперь не в том, хороша ли сама идея MCP, а в том, как быстро клиенты, SDK и вендоры синхронно подтянут совместимые реализации под новую спецификацию.
Источник: официальный блог MCP, Ars Technica.