MCP 2026-07-28: Опубликован спецификация: значительный переход на безсостоятельное ядро

iconMetaEra
Поделиться
AI summary iconСводка
KuCoin объявляет о крупном обновлении протокола с выпуском MCP 2026-07-28, переходя на безсостоятельную ядерную архитектуру. Новая спецификация устраняет сессионные взаимодействия, снижая затраты на инфраструктуру и улучшая масштабируемость. Теперь поддерживается OAuth 2.0 и OIDC для корпоративной авторизации, а также представлен формальный фреймворк для расширений. Разработчики должны выполнить миграцию из-за изменений, нарушающих совместимость. Обновление также включает новые списания токенов, расширяя возможности для трейдеров.
MCP больше не похож на интерфейс плагина производителя, он начинает напоминать общую трубу. Труба будет прочнее, но и менее податлива.

Автор статьи, источник: 0x9999in1, ME News



Кратко

  • 28 июля 2026 года MCP выпустил пятую версию спецификации2026-07-28, которая официально объявлена крупнейшим обновлением с момента создания протокола. Единственное ключевое изменение: удаление сессий из протокольного уровня.
  • initialize/initialized Handshake is gone,Mcp-Session-Id header is gone. Each request carries its own protocol version, client identity, and capability declarations in _meta. Any request can land on any instance; a simple round-robin load balancer is sufficient.
  • Это не оптимизация производительности, а ошибка архитектуры. Сессии с сохранением состояния и общее хранилище сессий когда-то были самой дорогой статьей счетов на серверах MCP.
  • Статус не исчез. Его перенесли из транспортного уровня в параметры инструмента, назвав «явным дескриптором». Модель видит его и, следовательно, может им управлять.
  • Интерфейсы взаимодействия (MCP Apps) и длинные задачи (Tasks) официально включены в версионную расширяемую архитектуру; основной протокол больше не расширяется для новых возможностей. Аутентификация приближается к реальному миру OAuth 2.0 и OIDC, а расширения для корпоративного управления авторизацией одновременно перешли в стабильную версию.
  • Это требует реальных затрат: это breaking change. Roots, Sampling, Logging и старая передача HTTP+SSE официально объявлены устаревшими, предоставлено как минимум 12-месячное переходное окно.
  • Одно предложение для оценки: MCP больше не похож на плагин-интерфейс производителя, он начинает напоминать общую трубу. Труба будет прочнее, но и менее податлива.

Первые две удаленные строки —这才是此次改版的重点

Сначала скажем один контринтуитивный факт.

Самая важная часть этого обновления, называемого «крупнейшим обновлением в истории», — это не то, что было добавлено, а то, что было удалено.

initialize и initialized эта пара рукопожатий существовала с момента появления MCP 28 ноября 2024 года.Mcp-Session-Id Этот заголовок запроса является основой всех схем развертывания после внедрения удаленного MCP. 28 июля оба элемента были одновременно удалены.

Как выглядит новый запрос? Очень простой.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search

Имена методов и инструментов вынесены в HTTP-заголовки. Шлюзы, ограничители скорости и WAF больше не должны распарсивать тело JSON, чтобы угадать, что именно требуется — достаточно посмотреть заголовки. Версия протокола, информация о клиенте и объявления возможностей помещаются в _meta и отправляются вместе с запросом. Хотите заранее узнать, какие возможности есть у сервера? Добавлена новая server/discover, но она является необязательной.

Что это значит? Это значит, что сервер MCP наконец превратился в обычную HTTP-нагрузку.

По словам Сина Робертса, вице-президента по искусственному интеллекту Netlify: «Безсостоятельная архитектура делает MCP полноценным HTTP-нагрузкой, не требуя обхода управления сессиями». Cloudflare выражается еще резче, утверждая, что эта версия заставляет инфраструктуру агентов работать так же, как и остальная часть веба: безсостоятельно, кэшируемо, маршрутизируемо и масштабируемо глобально.

Звучит как стандартная рекламная риторика производителя. Но на этот раз всё иначе, потому что речь идёт о конкретном событии: сессия исчезла, поэтому Lambda может работать, Workers могут работать, краевые узлы могут работать.

Два. Вязкость сессий — это реальный потолок для масштабирования агентов

Почему так сильно пошли на жесткие меры?

У старой модели было неизбежное физическое ограничение: сессия привязывалась к экземпляру, обрабатывающему рукопожатие.

Все вынуждены делать одно и то же: либо включать сессии с сохранением состояния, чтобы балансировщик нагрузки запоминал, на какой сервер направлять каждый клиент, либо настраивать общий хранилище, такое как Redis, чтобы сохранять состояние сессий и делать его доступным для всех экземпляров.

Оба этих пути работают, но оба предполагают уплату скрытого налога.

Сессионная привязка делает масштабирование некрасивым. Когда экземпляр нужно отключить, все его сессии обрываются. При резком росте трафика новые экземпляры не могут взять на себя существующие сессии, и нагрузка всегда распределена неравномерно. Путь с использованием общего хранилища дороже: вы вводите состояние в промежуточное ПО только для задачи, которая по сути сводится к «запоминанию имени клиента», и вам ещё нужно обеспечить его отказоустойчивость.

Когда масштаб мал, это не проблема. Когда масштаб растет, это становится проблемой.

Понять масштаб можно по цифрам. В декабре 2025 года, в годовщину появления MCP, ежемесячное количество загрузок SDK составляло 97 миллионов. К моменту этого выпуска в июле 2026 года Anthropic сообщила, что ежемесячное количество загрузок превысило 400 миллионов, а на официальном блоге указано «приближается к пятистам миллионам» — рост в четыре раза за год. Суммарное количество загрузок SDK для TypeScript и Python каждое превысило порог в один миллиард.

В каталоге собственного подключателя Claude от Anthropic сейчас перечислено более 950 серверов MCP. Данные компании по наблюдаемости Honeycomb лучше всего демонстрируют, что агенты уже реально работают: почти 20% всех их интерактивных запросов в месяц инициируются агентами.

Удвоение за полгода. Под такой кривой любая "скрытая налоговая" нагрузка в архитектуре будет усиливаться до явных расходов.

Таким образом, официальная формулировка — «одна из самых востребованных функций разработчиками». Не мы хотим изменить, а те, кто использует это в продакшене, уже не могут больше терпеть.

Три: состояние не исчезло, его перенесли перед моделью

Здесь есть недоразумение, которое необходимо прояснить.

Протокол является безсостоянием, это не означает, что ваше приложение также безсостояно.

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

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

Остановитесь и подумайте о значении этого предложения.

Раньше логика проектирования была такой: состояние — это задача инфраструктуры, модель не должна об этом заботиться. Сейчас логика обратная: состояние является частью цепочки рассуждений модели, и его скрытие приводит к неточным выводам модели.

Скрытое состояние делает модель глупой. Этот вывод получен не из эстетики архитектуры, а из полутора лет производственных инцидентов.

Та же логика была применена к пути, при котором сервер инициирует запросы. Раньше, когда инструмент выполнял действия, он должен был спросить пользователя: «Подтвердите удаление этих 3 файлов?», и для этого использовался постоянный SSE-поток для отправки запроса обратно на клиент. После перехода на безсостоятельную архитектуру этот поток исчез, и на его место пришли Multi Round-Trip Requests (MRTR).

Механизм не сложен. Сервер возвращает тип результата «требуется ввод», вместе с вопросом, который он задает, и строкой requestState. Клиент собирает ответы и повторно отправляет исходный вызов с inputResponses и неизменной requestState. Поскольку вся необходимая информация для продолжения содержится в requestState, повторная попытка, даже если она попадет на другую машину, сможет продолжиться.

Руководитель продукта Supabase Inian Parameshwaran сказал честно: поддержка elicitation долгое время была в их дорожной карте, но из-за того, что Supabase MCP изначально работает в безсостоятельном режиме, это было невозможно. После MRTR это стало возможным: инструмент может сначала подтвердить стоимость перед созданием проекта и спросить перед удалением данных.

Здесь я хочу поднять вопрос, который не акцентирован в официальной документации, но с которым вы обязательно столкнетесь на практике:requestState хранится и возвращается клиентом, поэтому он по своей природе находится за пределами доверенной зоны. Если сервер будет обрабатывать его как доверенный вход и сразу десериализовывать — он откроет себе уязвимость. Подпись, шифрование и установка срока действия — эти три меры, по моему мнению, очень скоро станут стандартной практикой в сообществе. Это мое суждение, а не требование спецификации.

Четвертый этап: расширенная рамка — протокол начинает учиться «не поправляться»

Второй настоящий ставкой стало превращение расширения рамок из обычая в институт.

Обратное DNS-именование, согласование возможностей через extensions, отдельные репозитории ext-* с авторизованными сопровождающими, версии независимы от основной спецификации. Звучит скучно, но это решает проблему, с которой сталкиваются все успешные протоколы: ядро становится все тяжелее.

Два расширения теперь официально утверждены.

Приложения MCP позволяют серверу напрямую отправлять интерфейс взаимодействия в диалог. Не просто текст, не структурированный JSON, а полноценный HTML-интерфейс, работающий в песочнице iframe. Можно использовать графики, формы, селекторы и т.д. Ключевая идея заключается в том, что инструменты должны заранее объявлять шаблоны интерфейса, чтобы клиент мог предварительно загрузить их и провести безопасную проверку до отображения чего-либо. Операции на интерфейсе по-прежнему осуществляются через обычный канал JSON-RPC для вызова инструментов.

Задачи: обработка второй половины проблемы — длительные задачи. Они были переведены из экспериментальной функции в официальное расширение, и их жизненный цикл был переработан в состояние без сохранения:tools/call возвращает дескриптор задачи, клиент использует tasks/get для опроса, дополненный новыми tasks/update и tasks/cancel.

Примечательно, что tasks/list был удален. Причина проста: без сессии операция «получить список всех задач» больше не безопасна — вы не можете определить, кому принадлежит «все».»

Это расширение предоставлено AWS. Вице-президент агентного ИИ Amazon Свами Сивасубраманиан заявил, что новые спецификации и безсостоятельное ядро уже интегрированы в Bedrock AgentCore. С другой стороны, вице-президент инженерного подразделения Foundry Тина Шухман отметила, что MCP позволил им расширить интеграции с десятков до тысяч; Foundry toolbox объединяет инструменты через единый MCP-эндпоинт, централизуя управление, аутентификацию и наблюдаемость.

Протокол, который AWS, Microsoft, Google Cloud и Cloudflare используют в качестве основы для построения своих решений. Это уже не просто спецификация плагина какой-либо компании.

Пять: настоящая боль — не в подключении, а в идентичности

В официальном блоге есть честное признание: за прошедший год реализаторы сообщили, что наибольшее количество времени уходит на получение разрешений.

Эта версия добавила шесть SEP в авторизацию — всё не очень яркое, но необходимое. Сервер авторизации должен возвращать параметр iss в соответствии с RFC 9207, и клиент должен проверять его перед обменом кода; это закрывает уязвимость, связанную с атаками путем путаницы серверов авторизации. При динамической регистрации клиент должен объявлять application_type, и теперь обратные вызовы localhost для настольных и CLI-приложений больше не будут отклоняться без причины. Учетные данные привязаны к issuer, который их выдал, и не могут использоваться на других серверах авторизации.

Более значимым сигналом является то, что динамическая регистрация клиентов (DCR) официально устарела, и направление смещается в сторону документа по метаданным идентификатора клиента (CIMD). DCR всё ещё работает и сохраняет обратную совместимость, но будет удалён в будущих версиях.

В тот же день расширение对企业-уровневого управления доступом (EMA) перешло в стабильную версию. Это событие может иметь большее значение для корпоративных ИТ, чем безсостоятельность.

В старой модели каждый сотрудник должен был отдельно авторизовываться для каждого сервера. При устройстве на работу приходилось вручную подключаться к каждому сервису по очереди. Команда безопасности не могла применять единые политики — права доступа выдавались каждым пользователем самостоятельно, без централизованного управления и аудиторских следов. Ещё хуже то, что рабочие и личные аккаунты смешивались, и не существовало механизмов, обязывающих использовать корпоративные удостоверения.

EMA превращает собственного провайдера идентичности предприятия в орган принятия решений. В основе лежит утверждение ID-JAG, выданное IdP при едином входе, которое клиент использует для получения маркера доступа от сервера авторизации MCP. Пользователь не проходит через какие-либо страницы согласия на любом отдельном сервере.

Okta — первый поддерживаемый IdP, использующий его Cross App Access. На стороне клиента все продукты Claude и VS Code уже интегрированы. На стороне сервера поддерживаются Asana, Atlassian, Canva, Figma, Granola, Linear, Supabase, Slack находится в процессе интеграции. Оценка руководителя инженерной команды Linear Тома Мура довольно милая: «Войдите один раз — и все подключители MCP настраиваются автоматически. Это волшебно».

Магия заключается не в опыте, а в управлении. Доступ к принятию решений наконец вернулся в панель управления IdP, и аудиторская цепочка охватывает все коннекторы.

Но я должен полностью высказать свою мысль: состояние и EMA решают вопросы идентичности и масштаба, но не всю проблему безопасности агентов. Эти две цифры из отчета Cisco «Состояние безопасности ИИ к 2026 году» остаются неизменными: 83% организаций планируют внедрить возможности агентов, но только 29% считают себя готовыми. Проблемы, такие как инъекции подсказок, отравление описаний инструментов и использование агентов в качестве прыжковой площадки для перемещения по сети, не исчезнут просто потому, что протокол удалил сессию.

Хорошая новость в том, чтоMcp-Method и Mcp-Name после внедрения стоимость выполнения стратегии шлюзом снизилась. Стандарт также требует, чтобы сервер отклонял запросы с несовпадающими заголовками и телом, что блокирует класс ошибок несоответствия маршрутизации и безопасности. Это существенное улучшение в оборонительной позиции. Но на этом всё.

Шесть: Цена: Это разрушительное изменение, счет уже выставлен

Я не люблю говорить только о прибыли, не упоминая счет.

Эта версия является breaking change. Функции Roots, Sampling и Logging одновременно переведены в статус устаревших. Старая передача HTTP+SSE также официально объявлена устаревшей. В спецификации также введена формальная политика жизненного цикла функций: Active → Deprecated → Removed, каждый этап — не менее 12 месяцев.

Есть также мелкие, но кусающиеся изменения: схемы ввода-вывода инструментов теперь поддерживают полный словарь JSON Schema 2020-12, oneOfanyOf и условия теперь работают; код ошибки «Ресурс не найден» изменён с пользовательского -32002 на стандартный JSON-RPC -32602. Если вы жёстко закодировали -32002 в своём коде, эту строку необходимо изменить.

Самые большие затраты на миграцию, как прямо указали официальные лица: разработчики, зависящие от идентификаторов сессий.

Так что расписание стоит повторить. Кандидат на выпуск был заблокирован 21 мая, а официальный выпуск состоялся 28 июля — было выделено целых десять недель для проверки разработчиками SDK и реализаторами клиентов. Все четыре SDK Tier 1 (TypeScript, Python, Go, C#) поддержали новую версию в тот же день, а SDK для Rust находился в бета-версии.

Десятинедельное окно открытой верификации + 12-месячный переходный период по выводу из эксплуатации + стандартизированный SEP должны быть предварительно протестированы в наборе тестов на совместимость, прежде чем будут окончательно утверждены. Вместе эти три пункта составляют самую профессиональную часть этого обновления в моем понимании.

Это не замалчивание разрушительных изменений и не перекладывание ответственности за них на сообщество.

Требование согласованности особенно важно. В будущем, чтобы добавить новые функции в стандарт, сначала опишите проверяемые сценарии. Это способ связать «намерение дизайна» и «фактическую реализацию», чему многие протоколы научились после серьезных ошибок.

Интересно, что миграция принесла и положительную доходность. Главный технический директор Manufact, стоящий за открытым фреймворком mcp-use, Энрико Тониато, привел конкретные цифры: благодаря новому SDK v2 и разделению клиента и сервера, размер пакета сократился примерно на 83%, а скорость увеличилась на 25%.

Одновременно оптимизировали архитектуру и уменьшили размер пакета. Такое бывает не часто.

Семь. Мое суждение

Как вы оцениваете это обновление?

Мой первый вывод: это признание ошибки, и причем красивое.

Первоначальная двухсторонняя состояние-ориентированная архитектура MCP была разработана для локальных сценариев. Ваш редактор подключен к серверу, работающему на локальной машине, выполняет рукопожатие и поддерживает одно соединение — это совершенно логично. Проблема возникла после запуска удаленного MCP, когда эта модель была перенесена в облачную среду, и все начали накладывать на нее патчи. Сессии с привязкой — это патч, хранение сессий в Redis — это патч, поддержка долгоживущего соединения для elicitation — тоже патч.

Когда патчей становится слишком много, пора менять фундамент. По словам соавтора протокола Дэвида Сории Парра, эта версия включает в себя все уроки последних 18 месяцев. Ник Купер, основной разработчик, выразился точнее: MCP исполнилось полтора года, и он поглощает десятилетия опыта проектирования веб-протоколов, становясь более зрелым протоколом.

Второе соображение: настоящим переломным моментом этого обновления является управление, а не технология.

Timeline needs to be double-checked. On November 25, 2024, Anthropic open-sourced MCP. On December 9, 2025, MCP was donated to the newly established Agentic AI Foundation under the Linux Foundation, a targeted fund initiated by Anthropic, Block, and OpenAI, with support from Google, Microsoft, AWS, Cloudflare, and Bloomberg. Eight months later, the first major version was released.

Протокол, изобретенный одним производителем, после передачи прошел свою самую болезненную операцию, а не впал в тупик комитета. Сам факт этого является подтверждением эффективности открытого управления.

Из списка платформ экосистемы также видно, что акцент изменился. Figma говорит о синхронизации дизайна и кода, Intuit — о предоставлении надежного финансового интеллекта для ста миллионов потребителей и корпоративных клиентов, Zoom — о безопасной интеграции интеллекта встреч в платформы ИИ. Это не язык разработчиков, а язык продуктовых линеек.

Третий вывод, и, на мой взгляд, самый важный для того, чтобы его высказать: зрелость протокола имеет цену — эту цену называют «безропотность».

Безсостояние, маршрутизируемость, кэшируемость, отслеживаемость. W3C Trace Context теперь передается через фиксированные ключи в _meta, что обеспечивает совместимость с OpenTelemetry для распределенного трассирования из коробки. Эти термины вы уже встречали в истории развития HTTP, REST и gRPC.

MCP становится трубой, о которой вы не будете говорить. Как никто не обсуждает, насколько сегодняшний TCP захватывающий.

Это хорошо? Я считаю, что да. Победа на уровне данных никогда не принадлежит самому впечатляющему дизайну, а принадлежит самому надежному. В тот момент, когда сессия была удалена, MCP пожертвовал частью элегантности ради возможности масштабирования в горизонтальном направлении за счет балансировки нагрузки по кругу.

Масштабирование агентов — это не проблема того, насколько умна модель. Проблема — в вещах, о которых никто не хочет говорить: куда сохранять сессии, как наследовать идентичность, остаются ли задачи после отключения и сколько раз нужно нажать кнопку согласия, чтобы десять тысяч сотрудников подключились к тысяче серверов.

Эта версия значительно сдвинула вперед эти события.

Что касается волнения, труба не отвечает за обеспечение волнения. Она отвечает только за то, чтобы не протекала, когда вы на неё не смотрите.

Источник ссылки

  1. Блог Model Context Protocol, «Спецификация от 2026-07-28», 28 июля 2026 года. https://blog.modelcontextprotocol.io/posts/2026-07-28/
  2. Блог Model Context Protocol, «Предприятие-управляемая авторизация: Zero-touch OAuth для MCP», 2026 г. https://blog.modelcontextprotocol.io/posts/enterprise-managed-auth/
  3. Claude от Anthropic, «Привнесение MCP 2026-07-28 в Claude», 2026 год, 28 июля. https://claude.com/blog/bringing-mcp-2026-07-28-to-claude
  4. Блог MCP Servers, «MCP Specification от 2026-07-28: Безсостоятельная, расширяемая будущность», 2026 год. https://blog.mcpservers.org/posts/mcp-spec-2026-07-28
  5. Linux Foundation, «Linux Foundation объявляет о создании Agentic AI Foundation», 9 декабря 2025 г. https://linuxfoundation.org/press/linux-foundation-announces-the-formation-of-the-agentic-ai-foundation
  6. Anthropic, «Пожертвование Model Context Protocol и создание Agentic AI Foundation», декабрь 2025 г. https://anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
  7. Cisco, «State of AI Security 2026», 2026 г. https://blogs.cisco.com/ai/cisco-state-of-ai-security-2026-report
  8. IT之家, «Самое крупное обновление с момента выхода: выпущен стандарт MCP 2026-07-28, переход на «безсостоятельный» ядро», 29 июля 2026 г. https://www.ithome.com/0/983/102.htm
Отказ от ответственности: Информация на этой странице может быть получена от третьих лиц и не обязательно отражает взгляды или мнения KuCoin. Данный контент предоставляется исключительно в общих информационных целях, без каких-либо заверений или гарантий, а также не может быть истолкован как финансовый или инвестиционный совет. KuCoin не несет ответственности за ошибки или упущения, а также за любые результаты, полученные в результате использования этой информации. Инвестиции в цифровые активы могут быть рискованными. Пожалуйста, тщательно оценивайте риски, связанные с продуктом, и свою устойчивость к риску, исходя из собственных финансовых обстоятельств. Для получения более подробной информации, пожалуйста, ознакомьтесь с нашими Условиями использования и Уведомлением о риске.