Обновить

MCP 2026-07-28: что действительно изменилось

Главное изменение — MCP стал stateless на уровне протокола. Убрали обязательные initialize, initialized и Mcp-Session-Id. Версия протокола и возможности клиента теперь передаются в каждом запросе, а сведения о сервере можно получить через server/discover. Любой запрос может обработать любой экземпляр сервера — без sticky sessions и общего хранилища сессий. Состояние приложения никто не запрещает: просто передавай явные идентификаторы вроде browser_id в аргументах инструментов.

Что ещё важно:

  1. Долгие операции получили нормальный жизненный цикл. Tasks позволяют вернуть taskId, а затем проверять состояние через tasks/get, передавать дополнительные данные через tasks/update и отменять работу через tasks/cancel. Но Tasks не появились с нуля — раньше это была экспериментальная часть ядра, теперь её переработали и вынесли в официальное расширение.

  2. Протокол стал удобнее для эксплуатации. Заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы, не разбирая JSON. Появились стандартные подсказки для кеширования — ttlMs и cacheScope, а также единые поля для передачи OpenTelemetry Trace Context.

  3. Переработано общение сервера с клиентом. Вместо произвольных server-to-client запросов сервер теперь может вернуть input_required, после чего клиент повторяет исходный запрос с ответом пользователя. Подписки на изменения вынесены в subscriptions/listen.

  4. Extensions стали полноценной частью экосистемы. Новые возможности теперь можно развивать отдельно от ядра. Первые заметные расширения — Tasks и MCP Apps. Последнее позволяет серверу отдавать интерактивный HTML-интерфейс, который клиент показывает в изолированном iframe.

  5. Есть важные ломающие изменения. Все результаты теперь содержат resultType. Roots, Sampling, Logging и старый HTTP+SSE объявлены устаревшими. Схемы инструментов получили полноценную поддержку JSON Schema 2020-12. Если ты пишешь MCP-клиент или SDK, этот пункт может оказаться важнее MCP Apps.

  6. Авторизацию подтянули ближе к реальному OAuth/OIDC. Добавили проверку iss, привязку учётных данных к конкретному issuer и уточнили регистрацию клиентов и работу с refresh-токенами.

В сухом остатке: remote MCP перестал требовать обязательную протокольную сессию и стал гораздо больше похож на нормальный stateless JSON-RPC поверх HTTP. Для продакшена это означает более простое горизонтальное масштабирование, маршрутизацию и кеширование. Остальные изменения полезны, но в основном касаются новых возможностей и миграции клиентов.

tg

Теги:
Всего голосов 3: ↑3 и ↓0+5
Комментарии1

Путь к ИИ‑сингулярности

У нас было два репозитория неоттестированного вайб‑кода, семьдесят пять тяжеловесных SDD‑спецификаций, пять обмазанных смазкой харнессов, солонка, наполовину полная кастомных скиллов и забитых капслоком правил, с десяток дырявых MCP‑серверов, RAG‑база со свежевекторизованным Confluence, самодельная дощечка имаго‑кодинга и целая россыпь автономных агентов всех мастей, от безобидных автодополнялок до галлюцинирующих субагентов, ставящих пакеты со slopsquatting и втихаря сносящих боевые базы.

Не то чтобы все это было действительно нужно для поездки к ИИ‑сингулярности, но если уж начали участвовать в спуске с горы на велосипеде без седла, остановиться уже невозможно.

Единственное, что вызывало у меня настоящий животный страх, это передача ответственности за ревью самой модели. Тот самый момент, когда седьмой агент подтверждает галлюцинации шестого, потому что все тесты зеленые, и я знал, что рано или поздно мы перейдем на эту дрянь.

Нет ничего более беспомощного, безответственного и испорченного, чем IT‑команда, запустившая мультиагентный оркестр в режиме allow all.

Это критический (и слегка ехидный) обзор того, что произошло с разработкой последние пару лет.

Путь к ИИ‑сингулярности

Публикации