MCP protocol removes session state и меняет подход к масштабированию remote servers в AWS. Новая спецификация переносит continuity в явные identifiers и request context.
Когда MCP protocol removes session state, меняется не только формат запросов. Меняется сама цена горизонтального масштабирования (horizontal scaling). Старый session-based режим требовал sticky routing, shared session store и дополнительного plumbing для observability, если сервер работал на нескольких инстансах. Для AWS это означало, что часть инфраструктуры существовала не ради бизнес-логики, а ради компенсации ограничения протокола.
Новый подход делает протокол stateless, но не делает приложение “без состояния” в абсолютном смысле. Это важная развилка. Состояние по-прежнему допустимо, но оно уходит в datastore, а в модель и в последующие вызовы передаётся только identifier. Такой компромисс ближе к обычной REST-дисциплине: сервер больше не обязан помнить пользователя через один и тот же экземпляр, а любой instance может обработать следующий запрос.
Выбор здесь прагматичный. Вместо привязки к сессии используется явный контекст на уровне каждого request. Первый message клиента может быть сразу tool call. Если клиенту нужно понять возможности сервера заранее, он вызывает новый server/discover, который возвращает supported protocol versions, capabilities и identity. Это снижает связность между клиентом и конкретным экземпляром сервера. Но есть и trade-off: разработчикам, которые строили систему вокруг session semantics, нужно пересобрать gateway, routing и monitoring.
На уровне реализации это убирает несколько привычных костылей. Для старого протокола приходилось держать ALB stickiness, shared session stores вроде DynamoDB или ElastiCache и отдельные правила маршрутизации. В новом протоколе этого не требуется, если речь именно о session infrastructure, построенной ради старой схемы. AWS прямо рекомендует instrument gateway так, чтобы логировать protocol version per request, а legacy lane выключать только тогда, когда traffic на старой версии обнулится.
Самое заметное изменение в поведении системы связано с Multi Round-Trip Requests. Раньше сервер мог удерживать stream и push-ить запрос клиенту mid-call. Теперь сервер возвращает input_required с inputRequests map и opaque requestState token. Клиент завершает elicitations, sampling calls или root queries и затем повторно отправляет исходный call с inputResponses. Это снимает зависимость от long-lived connections и shared session state. И именно поэтому схема подходит для AWS Lambda, где удерживать соединение ради промежуточного шага неестественно.
С точки зрения операционной модели это выглядит как более чистое разделение обязанностей. Сервер не хранит цепочку диалога в памяти, а возобновление работы возможно на любом экземпляре, потому что requestState несёт нужный контекст. Такой дизайн лучше согласуется с observability, security и reliability, которые AWS Well-Architected Agentic AI Lens считает критичными для agentic workloads. При этом сам протокол не отменяет сложности. Он просто переносит их из скрытой session layer в явные request and state boundaries.
Отдельно важно, что переход не одномоментный. Для клиентов 2025-era сохраняется backward-compatible lane, поэтому старые и новые версии могут сосуществовать. Но это означает, что legacy infrastructure нельзя удалить заранее. До полного ухода старых клиентов ALB stickiness и session store должны оставаться в работе. Здесь нет красивого shortcut: сначала измерение, потом sunset date, потом decommission.
Архитектурно новая версия ещё и дисциплинирует изменения. Long-lived streams не исчезли, но теперь subscriptions/listen используется как opt-in POST-response stream. Это требует внимательнее проверить idle timeouts на load balancer, proxy и compute tier. Параллельно появились deprecations с жёстким окном, минимум twelve months до removal, а также feature lifecycle policy, extension framework и conformance suite. Для платформенной команды это означает меньше риска внезапного дрейфа в протоколе и больше управляемости при миграциях.
Итог здесь не в том, что MCP стал “проще”. Итог в том, что сложность стала явной и лучше распределённой. Stateless core убирает целый класс compensating infrastructure, но взамен требует аккуратного обращения с identifiers, cacheScope, ttlMs, routing и versioning. Для remote MCP server на AWS это выглядит как зрелое архитектурное решение: меньше скрытой магии, больше предсказуемости, лучшее соответствие Well-Architected подходу. Если сервер строится сегодня, целевая версия 2026-07-28 выглядит более естественной основой, чем наследование session-based модели.