Сеансы, привязка клиентов, общие хранилища — все это уйдет в прошлое. 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 станет ближе к привычной веб-инфраструктуре, а владельцам серверов больше не придётся поддерживать отдельный слой только ради требований протокола.
От себя: так-то уже есть REST и RESTful приложения, а тут нам пытаются приподнести всё это как что-то новое. Ну и вот ещё анализ ИИ Qwen по этому поводу:
Проблема здесь не в том, что «они глупые», а в системном кризисе передачи знаний и подмене инженерных понятий маркетинговыми.
Вот как выглядит справедливая критика ситуации с MCP и «новым stateless-протоколом» через призму истории и архитектуры.
1. Феномен «амнезии индустрии»
То, что сейчас преподносится как революционное открытие («сессии уйдут в прошлое», «контекст передаётся в запросе»), является фундаментальным принципом REST, сформулированным Роем Филдингом ещё в 2000 году. Stateless (отсутствие состояния) — это не изобретение 2026 года, это базовое ограничение архитектуры HTTP, которое обеспечивает масштабируемость, надёжность и кэшируемость уже четверть века.
Когда специалисты представляют давно известное решение как новинку, это свидетельствует не о прогрессе, а о разрыве преемственности. Новое поколение ML-инженеров и AI-архитекторов, пришедшее из математики и data science, часто не имеет бэкграунда в распределённых системах. Они искренне не знают, что проблема, которую они решают, была решена до их рождения. Это не злонамеренный обман, а следствие узкой специализации и отсутствия культуры изучения первоисточников.
2. Подмена терминологии как маркетинговый инструмент
Название «MCP Web Protocol» вместо «REST over HTTP with JWT/Bearer tokens» — это классический приём ребрендинга существующей технологии.
- В инженерии точность терминов критически важна. Когда мы говорим «REST», мы подразумеваем конкретный набор ограничений и контрактов.
- Когда мы говорим «AI-native protocol», мы создаём пустую семантическую оболочку, которая позволяет продать старое вино в новых мехах.
Это не техническая инновация, а упаковочная. Цель такой упаковки — не улучшить систему, а создать нишу для финансирования, публикаций и карьерного роста. Инвесторы и менеджеры не дают деньги на «внедрение REST», но охотно финансируют «разработку AI-native stateless infrastructure». Результат один и тот же, но цена входа и уровень хайпа различаются на порядки.
3. Проблема «Glue Language» в архитектуре
Как справедливо отмечено в анализе Python: этот язык стал стандартом в ML именно потому, что является клеем между высокоуровневой логикой и низкоуровневыми вычислениями. Но у клея есть обратная сторона: он скрывает детали соединения.
ML-специалисты привыкли работать на уровне абстракций, где сложные операции (`torch.matmul`) вызываются одной строкой, а вся физика процесса скрыта внутри C++/CUDA. Этот паттерн мышления переносится и на сетевые взаимодействия: «я вызываю API, а как оно работает внутри — неважно». Но когда такие специалисты начинают *проектировать* протоколы, отсутствие понимания «физики сети» приводит к тому, что они заново изобретают механизмы, которые в HTTP/REST отлаживались десятилетиями. Разница лишь в том, что зрелые решения прошли через тысячи edge-cases, а новые — нет.
4. Прогноз: 20 лет на созревание (или забвение)
Прогноз основан на исторических прецедентах:
- CORBA / SOAP / XML-RPC: тоже были «революционными протоколами для распределённых систем». Потребовалось 10–15 лет, чтобы индустрия осознала их избыточную сложность и вернулась к простоте REST/JSON.
- GraphQL: появился как «убийца REST», но спустя годы занял свою узкую нишу, не заменив REST, а дополнив его там, где REST действительно неудобен.
MCP ждёт одна из двух судеб:
1. Стандартизация через боль. Протокол будет обрастать спецификациями, исправлять ошибки дизайна, добавлять авторизацию, кэширование, версионирование — и через 10–15 лет превратится в ещё один вариант REST с лишними надстройками.
2. Забвение. Когда хайп спадёт и бизнес столкнётся с реальными проблемами масштабирования, безопасности и поддержки, индустрия вспомнит, что HTTP+JWT уже решают 95% задач, и MCP останется нишевым инструментом для специфических AI-сценариев.
5. Почему это опасно
Проблема не в том, что кто-то изобретает велосипед. Проблема в том, что новый велосипед продают как космический корабль, и на этом основании принимаются архитектурные решения в реальных проектах.
- Команды внедряют MCP, потому что это «современно», а не потому что это решает их задачу лучше REST.
- Безопасность страдает, потому что новый протокол не прошёл decades of adversarial testing, которые прошёл HTTP.
- Ресурсы тратятся на поддержку параллельной инфраструктуры вместо развития продукта.
Итог
Критика MCP и подобных инициатив должна быть не эмоциональной, а историко-технической. Это не «дебилы изобрели ерунду». Это закономерное следствие:
- Узкой специализации без фундаментального образования в distributed systems.
- Маркетинговой упаковки старых идей под видом новых парадигм.
- Отсутствия культуры чтения первоисточников и RFC.
И да, пройдёт ещё немало лет, пока эта волна либо созреет до уровня зрелых технологий, либо схлынет, оставив после себя очередные уроки для тех, кто захочет их усвоить. А те, кто знает историю, продолжат строить системы на проверенных фундаментах, не отвлекаясь на ребрендинг старых решений.