Сеансы, привязка клиентов, общие хранилища — все это уйдет в прошлое. MCP становится «обычным» веб-протоколом
Протокол, который помогает моделям искусственного интеллекта подключаться к внешним сервисам, готовится отказаться от одного из своих базовых принципов. Крупнейшее обновление Model Context Protocol (MCP) с момента запуска уберёт сеансы и перестанет заранее обмениваться служебными данными, из-за чего удалённые серверы приходилось строить сложнее обычных веб-сервисов.
Разработчики заморозили предварительную версию спецификации 21 мая, а окончательный вариант планируют выпустить 28 июля. Главная цель обновления – сделать так, чтобы каждый запрос содержал все данные, нужные для обработки, и не зависел от ранее установленного соединения.
Изначально MCP создавали для настольных приложений, которые связывались с локальными процессами через стандартные потоки ввода и вывода. В такой схеме постоянное соединение и то, что возможности проверялись заранее, почти не создавали проблем. Ситуация изменилась, когда серверы MCP начали переносить в облака и распределять между несколькими узлами.
Сервер присваивал клиенту идентификатор сеанса и фактически привязывал его к конкретному экземпляру. Чтобы масштабировать систему, операторам приходилось привязывать клиентов к конкретным серверам, хранить общие данные о сеансах или добавлять специальную логику в шлюзы. Обычный удалённый сервис из-за требований протокола превращался в более сложную распределённую систему.
После обновления версия протокола, возможности клиента и его идентификатор будут передаваться с каждым вызовом. Серверы получат отдельный метод server/discover, через который клиент сможет запросить доступные функции заранее или непосредственно перед тем, как обратиться к серверу. Разработчики называют такой подход сложностью по мере необходимости. Базовая схема остаётся простой, а состояние добавляют только там, где без него нельзя обойтись.
Для операций, которым нужно запоминать контекст, MCP предложит явные идентификаторы. Например, инструмент сможет создать корзину, вернуть basket_id, а модель передаст значение при следующем запросе. Такой механизм давно применяют обычные веб-приложения. В отличие от скрытого идентификатора сеанса, модель видит идентификатор ресурса и может передавать его между инструментами и этапами работы.
Подобные значения нельзя считать подтверждением прав доступа. Идентификаторы могут попадать в запросы, журналы и историю диалога, поэтому сервер должен связывать их с учётной записью и проверять разрешения каждый раз, когда к нему обращаются.
Удалённые серверы MCP после обновления можно будет запускать как обычные сервисы без состояния. Несколько экземпляров смогут работать за балансировщиком, не привязываясь к конкретным клиентам и не используя общее хранилище сеансов. Обновление серверов также перестанет обрывать длительные сеансы, хотя незавершённые запросы и потоки уведомлений всё ещё могут прерваться. В таком случае клиент отправит запрос заново с новым идентификатором.
Шлюзы получат обязательный заголовок Mcp-Method, а операции с инструментами, ресурсами и шаблонами также будут передавать Mcp-Name. Благодаря заголовкам инфраструктура сможет ограничивать частоту запросов и проверять права, не читая всего тела сообщения. Сервер при этом обязан отклонять вызовы, если заголовок не совпадает с содержимым запроса, иначе злоумышленник сможет замаскировать одну операцию под другую.
Обновление также меняет кэширование. Ответы со списками инструментов и ресурсов будут содержать срок хранения ttlMs и область действия cacheScope. Клиент сможет временно сохранять каталог и не запрашивать его каждый раз, когда обращается к серверу. Серверы также должны возвращать инструменты в стабильном порядке, что повысит эффективность кэширования запросов к моделям и может снизить задержки и расходы.
Авторы MCP вынесли расширения в отдельную систему с собственными названиями, хранилищами и циклами выпуска. Функция Tasks, которую добавили в экспериментальном виде в ноябре 2025 года, покинет ядро и станет расширением после того, как её переработают. Такой подход позволит развивать дополнительные возможности, не меняя постоянно основную спецификацию.
Вместе с обновлением появится формальная политика отказа от старых функций. Устаревшая возможность должна оставаться доступной не менее 12 месяцев. Срок разрешат сократить только при подтверждённой угрозе безопасности, но даже тогда переходный период составит не менее 90 дней.
Переход потребует доработок. Серверы, которые использовали экспериментальный интерфейс Tasks, придётся перевести на новую схему. Механизмы Sampling и Logging также утратят прежнюю роль. Если сервер станет напрямую обращаться к поставщику модели, его владельцу придётся самостоятельно хранить ключи доступа, оплачивать запросы и обрабатывать пользовательские данные.
Если отказаться от сеансов, прикладное состояние никуда не денется. Корзины, задачи, идентификаторы операций и защита от повторных запросов по-прежнему потребуют базы данных или другого хранилища. MCP лишь перестанет управлять такими данными на уровне протокола.
Чтобы перейти на новую версию, клиенты сначала будут вызывать server/discover, а когда подключаются к старому серверу – возвращаться к прежнему initialize. Разработчики также подготовили предварительные наборы средств для Python, TypeScript, Go и C#. В результате MCP станет ближе к привычной веб-инфраструктуре, а владельцам серверов больше не придётся поддерживать отдельный слой только ради требований протокола.