Что проверить при интеграции и приёмке MCP после выхода новой спецификации

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

В этой статье разбирается спецификация MCP 2026-07-28 и опубликованная после неё дорожная карта. Данные проверены по состоянию на 05.09.2026. Это не анонс обновления EveryInfra, и текст не означает, что упомянутые изменения уже доступны в EveryInfra или в используемом вами клиенте.

Сначала разграничьте уже выпущенную спецификацию и планы дорожной карты

Мейнтейнеры MCP официально выпустили версию 2026-07-28 в анонсе релиза от 28 июля; одно из главных изменений — ядро протокола без сохранения состояния (stateless). Это не то же самое, что завершённая миграция сервиса: спецификация говорит разработчикам реализаций, чему следовать, а заметки о версиях сервиса и его реальные ответы говорят пользователям, что доступно сейчас.

Новая дорожная карта от 22.08.2026 (https://blog.modelcontextprotocol.io/posts/mcp-roadmap/) предложила такие направления дальнейшего развития, как идентификация агентов, представление результатов и постепенное обнаружение инструментов. Если включить все эти направления в список возможностей последней версии MCP, интеграторы сделают неверные выводы. Дорожная карта помогает понять, куда движется проект, но не заменяет ещё не выпущенные функции клиентов.

В обсуждении этой дорожной карты на Hacker News (https://news.ycombinator.com/item?id=49399591) тоже возникли вопросы о том, сколько новых требований сервисы реализуют на деле, и о постепенной загрузке инструментов. Это ценные направления для дальнейшего изучения, а не исследования внедрения в экосистеме. Нас больше интересует практический вопрос: действительно ли два эндпоинта, которые оба заявляют поддержку MCP, говорят на одном языке протокола?

Stateless-режим устраняет сессии протокола, но не снимает ответственности на уровне бизнес-логики

Согласно официальному списку изменений (https://modelcontextprotocol.io/specification/2026-07-28/changelog), в новой версии убраны прежнее рукопожатие инициализации и идентификаторы сессий на уровне протокола. Приложения, которым нужно сохранять состояние между вызовами, могут использовать явные прикладные идентификаторы. Иначе говоря, протокол больше не полагается на скрытые сессии в соединениях, чтобы помнить весь контекст, а у приложений по-прежнему могут быть свои задачи, ресурсы и состояние.

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

Рассмотрим гипотетический сценарий: агент запускает задачу формирования отчёта, и клиент отключается. После переподключения пользователю нужно знать, сформирован ли исходный отчёт, а не только то, может ли он переподключиться. Без идентификаторов задач и способа запросить результат пользователи могут отправить ту же работу повторно, даже если соединения в протоколе стали проще.

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

Если HTTP проще администрировать, это ещё не значит, что заголовков запроса достаточно

Спецификация Streamable HTTP (https://modelcontextprotocol.io/specification/2026-07-28/basic/transports/streamable-http) в новой версии определяет заголовки метаданных запроса, например Mcp-Method, и использует Mcp-Name для применимых методов. Соответствующие поля в заголовке и в теле должны совпадать. Спецификация по-прежнему допускает SSE-ответы в рамках запроса, поэтому это изменение нельзя упрощённо пересказывать как «MCP больше не использует потоковые ответы».

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

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

Точно так же HTTP 200 означает лишь, что ответ получен штатно, а не обязательно то, что бизнес-задача выполнена. Инструменты могут вернуть бизнес-ошибку, ждать ввода или выдавать промежуточные результаты. Важнее передать эти состояния пользователю, чем показывать все ответы одинаково успешными. О том, как спроектировать классификацию ошибок, читайте в статье на нашем сайте об обработке ошибок API и самовосстановлении (https://everyinfra.com/build/api-errors-self-healing).

Каталоги можно кешировать, но права доступа нельзя угадывать по кешу

Новая спецификация вводит для ответов с каталогами ttlMs и cacheScope: первое задаёт подсказку о свежести, второе — область общего кеша. Конкретные объекты, к которым они применяются, перечислены в примечаниях о кеше в списке изменений (https://modelcontextprotocol.io/specification/2026-07-28/changelog). Это помогает сократить лишние повторные запросы на получение каталога, но не обещает, что набор инструментов никогда не изменится.

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

Отдельно стоит проверить такой сценарий: права пользователя отозваны, а у клиента остался старый каталог. Хороший пользовательский опыт здесь — не тихое исчезновение инструментов и не молчаливые сбои вызовов, а явный отказ эндпоинта выполнения, объяснение причины в клиенте и обновление каталога в подходящий момент. Не маскируйте изменения прав увеличением времени кеширования.

Если вы строите собственный каталог возможностей, прочитайте статью о том, почему каталогу возможностей в реальном времени нужна проверяемость (https://everyinfra.com/build/live-capability-catalog). Эта статья на нашем сайте рассматривает связь каталога с фактическим поведением и не подразумевает, что все новые механизмы кеширования уже реализованы.

Проблемы с идентичностью не скрыть тем, что соединение установлено

Проверка идентичности сервера авторизации входит в этот раунд изменений спецификации. RFC 9207 (https://www.rfc-editor.org/info/rfc9207/) определяет параметр iss, который помогает клиенту убедиться, что ответ авторизации пришёл от ожидаемого издателя, и предотвращает путаницу серверов авторизации.

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

Мы рекомендуем перед выполнением действий с серьёзными последствиями снова показывать ключевые объекты и последствия. Например, при изменении конфигурации нужно указать окружение и поля, при отправке сообщения — получателей и содержимое. Модели могут помочь подготовить операцию, но авторизация не должна прятаться в расплывчатых описаниях инструментов.

Поэтому наличие OAuth у сервиса, поддержка MCP в клиенте и возможность получить список инструментов сами по себе не могут служить результатом приёмки интеграции для продакшена. Для обнаружения по протоколу, авторизации и выполнения бизнес-задачи нужны отдельные проверяемые подтверждения.

Перед обновлением составьте небольшую и понятную матрицу приёмки

Проверяя реализацию по официальным примечаниям о версиях и совместимости (https://modelcontextprotocol.io/specification/2026-07-28/basic/versioning), перечислите каждую реальную комбинацию использования отдельно, а не заводите одну строку «поддерживает MCP». В каждой строке укажите клиент и его версию, версии протокола, поддерживаемые сервером, используемые транспорт и способ аутентификации, проверенные операции и непроверенные возможности.

В первом раунде не нужно тестировать все инструменты, но нужно охватить сценарии, которые меняют решение о готовности к поставке:

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

Это рекомендуемые нами пункты приёмки интеграции, а не отчёты о тестировании какого-либо продукта. Текущие инструкции по подключению к EveryInfra приведены в статье о приёмке удалённого доступа к MCP (https://everyinfra.com/build/remote-mcp-setup); при чтении учитывайте конкретные версии и границы тестирования и не считайте их доказательством совместимости с 2026-07-28.

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