mcp 2.0 — поисковое название новой эпохи протокола, хотя официальная ревизия MCP названа датой 2026-07-28, а v2 относится, в частности, к TypeScript SDK. Если подрядчик обещает «переход на 2.0», попросите показать версию протокола в обмене клиента и сервера, версию каждой библиотеки и список поддерживаемых возможностей. Версия пакета показывает выпуск библиотеки и оставляет открытым вопрос о работе связки. Официальный анонс MCP фиксирует дату ревизии и перечень изменений.
Имя версии
Официальное имя ревизии протокола — 2026-07-28; v2 у TypeScript SDK обозначает выпуск библиотеки. Проверка начинается с разделения этих двух уровней.
Фраза «MCP 2.0» помогает найти обсуждение обновления, но создаёт ложное ощущение единого номера для всех компонентов. Протокол задаёт формат запросов и ответов, правила транспорта и объявление возможностей. SDK реализует эти правила в конкретном языке и выпускается по собственной схеме версий. Приложение клиента и сервер затем выбирают, какие возможности реально поддержать. Поэтому строка v2 в зависимостях проекта подтверждает версию библиотеки, но совместимость рабочего обмена показывает только проверка сообщений. Репозиторий TypeScript SDK прямо связывает свою ветку v2 с протоколом 2026-07-28. У C# SDK тоже собственная линейка версий пакетов; конкретный выпуск сверяйте по документации библиотеки, отдельно от даты спецификации.
| Надпись | Что обозначает | Где искать подтверждение |
|---|---|---|
| MCP 2026-07-28 | Ревизия спецификации | Заголовок версии протокола и документация |
| TypeScript SDK v2 | Версия библиотеки для клиента или сервера | Зависимости проекта и миграционное руководство |
| «MCP 2.0» | Фраза из поиска или разговора | Уточнение состава обновления |
Одинаковая дата протокола в двух компонентах ещё оставляет вопросы к поддержке функций и настройкам доступа. Команде полезно вести карточку интеграции: язык и версия клиента, язык и версия сервера, транспорт, выбранная ревизия спецификации, обязательные сценарии вызова. Так разговор об обновлении превращается в проверяемое техническое задание. Для общей роли клиента и сервера подойдёт введение в MCP для бизнеса; здесь фокус уже на совместимости конкретной связки.
Карта связки
Составьте матрицу для каждого рабочего соединения. В строке укажите клиентское приложение и версию его SDK, сервер и его SDK, транспорт, целевую ревизию протокола, доступные инструменты и действия с записью. Отдельно пометьте шлюз, если запрос проходит через него: он обязан пропускать нужные заголовки и соблюдать серверные правила доступа. Договорённость о версии между разработчиками полезна, но только тест реального маршрута обнаружит потери заголовков, расхождения схем и запреты на стороне сервера.
В ревизии 2026-07-28 запрос содержит сведения о версии протокола, клиенте и возможностях клиента; для предварительного знакомства с возможностями сервера предусмотрен необязательный вызов server/discover. Обмен initialize/initialized и заголовок Mcp-Session-Id выведены из новой ревизии. Для Streamable HTTP добавлены заголовки Mcp-Method и Mcp-Name, которые помогают шлюзу маршрутизировать вызов по метаданным. Описание изменений также говорит о новом порядке работы с запросами, требующими дополнительного ввода. Эти особенности подтверждают журналом фактического обмена.
- Запишите, какую ревизию протокола заявляет клиент в запросе и какую принимает сервер.
- Сверьте необходимые capabilities с реальным поведением инструмента и ответом сервера.
- Проверьте правила доступа на сервере для чтения, записи и подтверждения действий.
- Зафиксируйте поведение шлюза при передаче версии и имени вызываемого метода.
Если клиент или сервер остался на прежней ревизии, подготовьте отдельный сценарий совместимости и явное решение о поддерживаемых сочетаниях. Принимать решение по одному номеру SDK рискованно: библиотека даёт строительные блоки, а приложение может задействовать лишь часть функций. Выбор клиента как отдельного компонента разобран в материале о MCP-клиенте.
Проверка обмена
Предлагаемый пилот начинается в тестовом контуре с сервером, где есть безвредный инструмент чтения и отдельная операция записи с подтверждением. Разработчик фиксирует ожидаемые запросы и ответы до запуска. Для точного сравнения заголовков и полей используйте скрипт или сетевой журнал с удалёнными секретами. Языковая модель пригодится для объяснения расхождения в журнале и гипотезы о причине; инженер сверяет гипотезу с документацией и реальным ответом сервера. В тестовых данных исключите рабочие ключи, личные сведения и действия в производственной системе.
- Отправьте вызов чтения с заголовком MCP-Protocol-Version и проверьте принятую сервером ревизию.
- Сравните объявленные возможности с доступными методами и выполните разрешённый вызов инструмента.
- Сымитируйте запрос на дополнительное подтверждение и проверьте ответ клиента по правилам выбранной ревизии.
- Попробуйте операцию записи без серверного разрешения, затем с разрешённой ролью и явным подтверждением человека.
- Повторите проверки через рабочий шлюз и сохраните обезличенный журнал обмена.
Для запроса, который требует ответа пользователя посреди вызова, новая ревизия описывает Multi Round-Trip Requests: сервер возвращает запрос на ввод, клиент прикладывает ответ при повторном вызове. Наличие такой возможности у конкретной связки следует проверять отдельно. Подтверждение в интерфейсе показывает волю человека, а сервер всё равно сверяет роль, область доступа и допустимость операции. Промпт модели способен сформулировать действие, но разрешение остаётся за приложением и сервером. Критерий приёмки — предсказуемое поведение при разрешённом вызове и понятный отказ при запрещённом.
Хотите проверить совместимость вашего MCP-клиента и сервера?
Выход из сессий
Отказ от Mcp-Session-Id в новой ревизии влияет на архитектуру сервера шире, чем замена заголовка. Раньше приложение могло связывать последовательность вызовов со скрытым состоянием транспортной сессии. Теперь каждый запрос должен содержать достаточные сведения для обработки, а нужное состояние прикладного процесса можно передавать явным идентификатором в аргументе инструмента. Например, черновик заявки получает собственный идентификатор, который следующий вызов передаёт серверу. Сервер по нему заново проверяет права и состояние заявки. Сама запись хранится в прикладной системе по её правилам.
Проверьте код клиента и сервера на ожидание старого рукопожатия initialize/initialized, зависимость от заголовка сессии и сохранение данных только в памяти процесса. Затем проверьте повтор вызова, переход запроса на другой экземпляр сервера и истечение прикладного идентификатора. Ошибки здесь проявляются даже при успешном базовом вызове tools/list. Для узкой миграции заголовка уже существует отдельный материал о legacy session id; этот обзор связывает отказ от сессии с остальной ревизией, возможностями клиента и приёмкой интеграции.
Параллельно проверьте кэширование списков: новая ревизия описывает ttlMs и cacheScope для результатов списка и чтения ресурсов. Клиенту нужен понятный способ обновлять каталог инструментов при изменении прав или состава сервера. Также проверьте маршрутизацию по Mcp-Method и Mcp-Name на шлюзе: заголовки помогают определить метод, но решение о доступе остаётся серверным. Для проектирования собственных инструментов полезна статья о MCP-сервере, где речь о его функциях и границах.
Если старое приложение опирается на транспортную сессию, сначала опишите хранимое состояние и владельца каждого идентификатора. Затем выбирайте способ переноса на прикладной уровень и тестируйте отзыв доступа отдельно от корректности ответов.
Критерии приёмки
Результатом пилота предложите сделать таблицу поддерживаемых сочетаний клиента и сервера, обезличенные образцы запросов, перечень включённых возможностей и список отклонений. Для каждого отклонения запишите симптом, уровень возникновения и решение владельца интеграции. Например, отсутствие ожидаемого заголовка относится к транспорту или шлюзу; отказ записи при правильной форме запроса может быть штатным итогом проверки прав. Такой журнал помогает разделить ошибку совместимости, ошибку конфигурации и верный запрет.
Обновление библиотеки без проверки рабочих сценариев оставляет риск: клиент может заявить новую ревизию, но обходить критичный путь вызова, а сервер может отвечать на чтение и отклонять нужный процесс подтверждения. Приёмка должна охватывать разрешённые и запрещённые действия, прикладное состояние, поведение после смены прав и повторную попытку. Решение о выпуске принимает владелец системы вместе с инженером, который проверяет журнал, конфигурацию и документацию. Модель может помочь описать различия между ответами, но итоговый статус сверяет человек.
Отдельной строкой укажите цену работ качественно: она зависит от числа связок, состояния старого кода, роли шлюза и объёма проверок безопасности. Смету оценивают по составу работ и критериям приёмки, без обещаний результата по одному номеру версии. Если требуется внешняя оценка архитектуры, изложите схему соединений и проблемные вызовы при обращении за консультацией по внедрению ИИ. Для проверки самого сценария агентного действия пригодится разбор тестов и отката. Название «MCP 2.0» остаётся разговорным ярлыком; совместимость подтверждают журнал обмена и тесты.
Выберите одну рабочую связку клиента и сервера, запишите фактическую ревизию протокола и проверьте чтение, запись с подтверждением и отказ по правам. Расширяйте матрицу после фиксации понятных критериев приёмки.