Создавайте с CometAPIНужен один API для нескольких моделей?Протестируйте рабочий процесс в Playground, затем создайте API-ключ, когда модель и стоимость подойдут для вашего сценария.
MCP 2026-07-28 Руководство по миграции: серверы без состояния
Узнайте, как выполнить миграцию на MCP 2026-07-28, включая транспорт без сохранения состояния, MRTR, заголовки маршрутизации, кэширование, изменения в OAuth, обновления SDK.
Кратко: MCP 2026-07-28 удаляет сеансы на уровне протокола и обязательное начальное рукопожатие. Командам в продакшне следует найти скрытые зависимости от сеансов, перейти на метаданные протокола в каждом запросе, внедрить многораундовые запросы, обновить политики шлюзов и провести канареечное развертывание нового протокола перед выводом из эксплуатации устаревшего поведения.
Спецификация Model Context Protocol, выпущенная 28 июля 2026 года, вводит крупнейшее архитектурное изменение в MCP со времён добавления поддержки удалённого транспорта.
Теперь протокол использует статeless-ядро «запрос–ответ». Обязательный обмен initialize и notifications/initialized удалён, исключён, а каждый запрос несёт протокольную информацию, необходимую для его обработки.
Эти изменения упрощают масштабирование удалённых MCP-серверов за стандартной HTTP-инфраструктурой. Они не делают существующее приложение статeless автоматически.
Продакшн-сервер всё ещё может зависеть от in-memory рабочих пространств, закреплённой маршрутизации, привязанных к сессии учётных данных, длительных потоков или взаимодействий, инициируемых сервером. Это руководство фокусируется на поиске и замене таких зависимостей.
Отклоняет ли сервер вызовы, пока инициализация не завершена?
Выбирает ли ID сессии пользователя, учётные данные, рабочее пространство или разговор?
Может ли другой инстанс сервера продолжить процесс, начатый первым?
Требует ли балансировщик привязки сессии?
Выполняет ли инструмент побочный эффект до запроса подтверждения?
Парсирует ли шлюз тело для определения метода или инструмента?
Хранятся ли OAuth-учётные данные без указания их эмитента?
Зависит ли клиент от переподключения SSE или повторной доставки сообщений?
Меняются ли списки инструментов или ресурсов в зависимости от соединения?
Какие устаревшие функции всё ещё получают продакшн-трафик?
Не удаляйте Mcp-Session-Id, пока не поймёте, что приложение хранит за ним.
Сервер, убирающий заголовок, но оставляющий состояние в локальной памяти, может работать в разработке и эпизодически сбоить, когда запросы распределяются по нескольким инстансам.
2. Замените скрытое состояние сессии
MCP 2026-07-28 удаляет сессии на уровне протокола, а не состояние приложения.
Состояние, требуемое между вызовами, должно использовать один из трёх паттернов.
Явные дескрипторы
Возвращайте сгенерированный сервером дескриптор из одного инструмента и требуйте его в последующих вызовах.
Это делает зависимость видимой в контракте инструмента и позволяет любому совместимому инстансу сервера обработать запрос.
Общее хранилище
Используйте базу данных, распределённый кэш, объектное хранилище или долговечную систему задач, когда:
нескольким воркерам нужно одно и то же состояние;
процесс должен пережить перезапуск;
состояние слишком велико для дескриптора;
процесс длится дольше одного запроса;
требуется транзакционность или одноразовая семантика.
Защищённый requestState
MRTR может вернуть непрозрачное значение requestState, которое клиент возвращает при повторе исходного запроса.
Так как значение проходит через клиента, защитите его HMAC или аутентифицированным шифрованием. Привяжите его к аутентифицированному субъекту, исходной операции, важным параметрам, времени истечения и нонсу при необходимости защиты от повторов.
Никогда не доверяйте неподписанному requestState только потому, что клиент вернул его без изменений.
3. Переход на самодостаточные запросы и discovery
Современные MCP-запросы включают контекст протокола в _meta.
Вызов инструмента по Streamable HTTP может выглядеть так:
Серверы, нацеленные на новый протокол, должны реализовать server/discover, который объявляет поддерживаемые версии, возможности и идентичность сервера. Клиенты могут вызывать его перед другой операцией или использовать для определения необходимости отката к наследию.
Прочитайте официальную документацию server/discover для контракта ответа.
Согласование версии в TypeScript SDK
Одно обновление TypeScript SDK не переключает клиента на новый протокол автоматически.
Клиент, использующий SDK v2, должен явно включить это:
поведение, если клиент не поддерживает запрошенную возможность.
Не завершайте покупку, удаление, списание средств или внешний запись до возврата input_required.
Используйте поэтапную операцию или ключ идемпотентности, чтобы повторы не дублировали действие. См. официальную спецификацию MRTR для полной модели взаимодействия.
5. Обновите шлюзы, кэширование и авторизацию
Изменения инфраструктуры тесно связаны и должны тестироваться вместе.
Валидируйте маршрутизирующие заголовки MCP
Streamable HTTP POST-запросы теперь включают:
MCP-Protocol-Version
Mcp-Method
Mcp-Name
Эти заголовки позволяют шлюзам маршрутизировать, учитывать, авторизовывать и ограничивать трафик без парсинга каждого JSON-тела.
Они могут поддерживать такие политики, как:
ограничение частоты по инструментам;
отдельные политики для методов листинга и исполнения;
отдельные пулы воркеров для дорогих инструментов;
ограниченный доступ к высокорисковым операциям;
метрики задержки и ошибок по инструментам;
отнесение инфраструктурных затрат.
Значения всё равно поставляет клиент. Сравнивайте их с JSON-RPC-телом перед применением политики.
Запрос не должен иметь возможность указать низкорисковый инструмент в Mcp-Name, вызывая другой инструмент в теле. Несоответствия заголовков и тела должны отклоняться и логироваться.
Используйте кэш-ключи с учётом авторизации
Новый протокол добавляет ttlMs и cacheScope к кэшируемым результатам, включая:
tools/list
prompts/list
resources/list
resources/templates/list
resources/read
Ключ кэша обычно должен включать:
protocol version
server identity
method
request parameters
authenticated principal or tenant
authorization scope
cacheScope
server configuration version
Не переиспользуйте приватную запись кэша между пользователями или тенантами только потому, что TTL ещё не истёк.
Также важен детерминированный порядок инструментов. Стабильный каталог избегает лишних промахов кэша и может улучшить повторное использование кэша подсказок модели, когда определения инструментов вставляются в подсказки.
Ужесточите обработку OAuth-эмитента
Во время миграции авторизации:
валидируйте возвращаемое значение iss относительно эмитента, записанного для потока;
привязывайте хранимые клиентские учётные данные к эмитенту;
никогда не переиспользуйте учётные данные с другим сервером авторизации;
задавайте корректный application_type при DCR;
готовьте новые интеграции к Client ID Metadata Documents.
Dynamic Client Registration остаётся для обратной совместимости, но более не рекомендуется как предпочтительный подход регистрации.
6. Мигрируйте уведомления, задачи и устаревшие функции
Старый HTTP GET-путь для уведомлений и поток resources/subscribe/resources/unsubscribe заменены на subscriptions/listen.
Клиенты открывают долго живущий поток ответа на POST и выбирают категории уведомлений, которые им нужны. Уведомления о прогрессе и логах, специфичные для запроса, остаются привязанными к потоку ответа того запроса, который они описывают.
Для мульти-инстансных развёртываний используйте общий шина событий, когда уведомления, сгенерированные на одном инстансе, должны попасть в подписку, подключённую к другому.
Расширение Tasks
Долгие операции вынесены из экспериментального ядра протокола в:
io.modelcontextprotocol/tasks
Расширение использует:
tasks/get для опроса;
tasks/update для обновлений от клиента серверу;
долговечные дескрипторы задач;
subscriptions/listen для выбранных обновлений.
Старые паттерны tasks/result и tasks/list не следует переносить в новую реализацию.
Устаревшие функции
Следующие функции устарели:
Функция
Рекомендуемое направление
MCP 2026-07-28
Действие при миграции
Roots
Передавайте директории через аргументы инструментов, URI ресурсов или конфигурацию
Нет обязательного рукопожатия
Убрать ворота инициализации для современных запросов
Sampling
Интегрируйтесь непосредственно с API провайдеров моделей
Нет сеансов на уровне протокола
Сделать необходимое состояние явным
Logging
Используйте stderr для stdio или OpenTelemetry в продакшне
Необязательный вызов server/discover
Реализовать discovery и согласование версии
Dynamic Client Registration
Переходите к Client ID Metadata Documents
Включён в _meta запроса
Отправлять метаданные протокола в каждом запросе
Устаревший HTTP+SSE
Мигрируйте на Streamable HTTP
Заголовки Mcp-Method и Mcp-Name
Обновить маршрутизацию, политику и наблюдаемость
Устаревшие значения includeContext
Опустите поле или используйте "none"
Многораундовые запросы
Обрабатывать input_required и повторы
Кэширование списков
Многократное получение каталогов
ttlMs, cacheScope, детерминированный порядок
Добавить авторизационно-осознанное кэширование
Уведомления
GET-стрим и подписки на ресурсы
subscriptions/listen
Перенести уведомления об изменениях в новый поток
Устаревшая функциональность остаётся доступной в период устаревания, но её не следует внедрять в новых реализациях. Политика жизненного цикла MCP предусматривает минимум двенадцать месяцев на устаревание; это не означает, что каждая функция имеет одинаковую подтверждённую дату удаления.
Не меняйте клиентов, серверы, шлюзы, кэширование и авторизацию в одном незаметном релизе.
Рекомендуемый порядок миграции
Инвентаризируйте версии протокола, SDK, сессии, трафик SSE, DCR-клиентов и устаревшие методы.
Обновите непроизводственные SDK.
Добавьте server/discover и согласование версии.
Замените скрытые зависимости от сессий.
Реализуйте и обезопасьте MRTR.
Добавьте валидируемые заголовки маршрутизации и разделённые кэши.
Протестируйте границы эмитентов в авторизации.
Канареечно разверните современный протокол рядом с устаревшим путём.
Выводите старое поведение из эксплуатации только после анализа телеметрии.
Совместимость во время канареечного этапа
Современный клиент + современный сервер
→ Используют MCP 2026-07-28
Современный клиент + наследуемый сервер
→ Пробует и откатывается при поддержке
Наследуемый клиент + сервер с двумя версиями
→ Продолжает по устаревшему пути
Неподдерживаемая комбинация
→ Возвращает понятную ошибку версии протокола
Релиз новой спецификации MCP — это не одновременный переход всей экосистемы. Клиенты, серверы, SDK и хостинговые платформы будут мигрировать с разной скоростью.
Телеметрия для записи
Сигнал
Что показывает
Версия протокола на запрос
Принятие и несовместимые комбинации
Успех discovery и частота откатов
Поведение согласования версии
Отсутствующие или неверные MCP-заголовки
Устаревшие клиенты или ошибки шлюза
Несоответствия заголовков и тела
Баги клиентов или попытки обхода политики
MRTR запрошено и завершено
Надёжность интерактивных процессов
MRTR отклонено или истекло
Сценарии отказов пользователей и клиентов
Сбои проверки request-state
Подмена, повтор или истечение
Предотвращение дублирования операций
Эффективность контроля идемпотентности
Процент попаданий кэша по области
Безопасное снижение трафика
Сбои валидации эмитента
Проблемы конфигурации OAuth
Трафик HTTP+SSE
Оставшаяся работа по миграции транспорта
Трафик устаревших методов
Данные для планирования вывода
Задержка инструментов и доля принятых задач
Видимая пользователю надёжность
Успешные одноразовые запросы tools/call недостаточны для измерения миграции. Процесс, который стабильно истекает по времени, запрашивает ненужный ввод или дублирует внешний запись, всё ещё считается провалом в продакшне.
Как CometAPI вписывается в архитектуру MCP
MCP не заменяет API моделей. Эти два слоя решают разные задачи интеграции.
Слой
Основная ответственность
MCP
Соединять агентов с инструментами, ресурсами, подсказками, одобрениями и задачами
Унифицированный API моделей
Соединять приложения с моделями, учётными данными, учётом и биллингом
Оркестрация приложения
Решать, когда и как вызывать модели и инструменты
Типичная продакшн-архитектура выглядит так:
Application or agent
↓
MCP clients and servers
Tools, resources, approvals, tasks
↓
Unified model API
GPT, Claude, Gemini, DeepSeek, and other models
MCP стандартизирует взаимодействие агентов с инструментами и контекстом. Он не стандартизирует цены на модели, учётные данные провайдеров, конечные точки инференса или отказоустойчивость провайдеров.
Это разделение особенно полезно при миграции с устаревшей возможности Sampling. Если MCP-сервер или потребляющий его агент всё ещё нуждается в инференсе модели, приложение может вызывать API модели напрямую вместо зависимости от прежнего потока MCP Sampling.
Когда помогает унифицированный шлюз моделей
Унифицированный шлюз моделей снижает операционные затраты, когда:
нескольким MCP-серверам нужен доступ к разным провайдерам моделей;
разные инструменты требуют разных моделей;
команды хотят менять модели без переписывания интеграций под конкретных провайдеров;
учётные данные, использование и биллинг нужно централизованно управлять;
доступ к моделям должен оставаться независимым от изменений транспорта MCP.
CometAPI предоставляет совместимую с OpenAI конечную точку, которую можно использовать как слой доступа к моделям за MCP-приложениями. Это держит логику провайдеров моделей отдельно от инструментов MCP, ресурсов и оркестрации задач.
Например, инструмент MCP может вызвать модель через тот же совместимый с OpenAI клиент, который используется в другом месте приложения:
MCP-сервер остаётся ответственным за контракт инструмента, авторизацию, состояние и обработку результата. Шлюз моделей управляет выбором модели, доступом к провайдеру и ответами инференса.
Разделение этих слоёв даёт две практические выгоды:
Клиенты и серверы MCP могут мигрировать на новый протокол без изменения слоя интеграции с моделями.
Провайдеров моделей можно менять без переработки инструментов MCP или поведения транспорта.
Поддерживать subscriptions/listen при необходимости.
Сервер
Удалить ворота инициализации для современных запросов.
Убрать зависимости от Mcp-Session-Id.
Реализовать server/discover.
Заменить скрытое состояние дескрипторами или общим хранилищем.
Возвращать resultType.
Заменить запросы, инициируемые сервером, на MRTR.
Защитить requestState.
Валидировать все inputResponses.
Добавить идемпотентность для побочных эффектов.
Возвращать детерминированные списки.
Публиковать консервативные подсказки кэширования.
Мигрировать долгие операции в расширение Tasks.
Шлюз и инфраструктура
Валидировать запросные заголовки MCP.
Сравнивать заголовки с телом запроса.
Удалить ненужную закреплённую маршрутизацию.
Тестировать запросы через несколько инстансов.
Разделять кэши по границам авторизации.
Добавить общую шину уведомлений при необходимости.
Отслеживать трафик наследия и устаревших функций.
Сохранять путь отката на канареечном этапе.
FAQ
Что такое MCP 2026-07-28?
MCP 2026-07-28 — спецификация Model Context Protocol от 28 июля 2026 года. Она вводит stateless-ядро протокола, многораундовые запросы, HTTP-заголовки маршрутизации, кэшируемые результаты, изменения авторизации, расширения и формальный цикл устаревания.
Удалён ли Mcp-Session-Id?
Да. Новый транспорт Streamable HTTP больше не использует Mcp-Session-Id.
Приложения всё ещё могут сохранять состояние через явные дескрипторы, общее хранилище, долговечные задачи или защищённые значения request-state.
Удалено ли начальное рукопожатие MCP?
Да. Современные запросы больше не требуют обмена initialize и notifications/initialized.
Серверы должны реализовать server/discover, хотя клиентам не нужно вызывать его перед каждой операцией.
Означает ли stateless MCP, что инструменты не могут сохранять состояние?
Нет. Stateless относится к уровню протокола.
Инструмент может сохранять состояние, но обработка запроса не должна зависеть от скрытой привязки транспорта или одного конкретного процесса сервера.
Что такое MRTR?
Многораундовые запросы позволяют серверу запросить дополнительный ввод от клиента или пользователя без отправки запроса, инициированного сервером, по постоянно открытому двунаправленному соединению.
Сервер возвращает input_required, а клиент повторяет исходную операцию с запрошенными ответами.
Удалён ли HTTP+SSE немедленно?
Нет. Он помечен как устаревший, а не немедленно удалён.
Новые серверы должны использовать Streamable HTTP, а существующим системам следует измерить и мигрировать оставшийся трафик HTTP+SSE.
Используют ли клиенты TypeScript SDK v2 MCP 2026-07-28 автоматически?
Нет. TypeScript SDK v2 требует явной конфигурации согласования версии для использования современного протокола.
Используйте автоматическое согласование, если клиент должен работать как с современными, так и с наследуемыми серверами.
Итоговые рекомендации
MCP 2026-07-28 упрощает масштабирование, маршрутизацию, кэширование и наблюдаемость удалённой MCP-инфраструктуры. Основной риск миграции — не просто удаление заголовка или рукопожатия. Это скрытое состояние приложения и логика взаимодействия, которые всё ещё могут от них зависеть.
Перед развёртыванием нового протокола:
Найдите каждую зависимость от инициализации и Mcp-Session-Id.
Перенесите необходимое состояние в явные дескрипторы или общее хранилище.
Реализуйте MRTR со сроком действия, защитой от повторов и идемпотентностью.
Валидируйте заголовки MCP относительно JSON-RPC-тела.
Разделяйте кэши по тенанту и области авторизации.
Ужесточите валидацию OAuth-эмитента.
Измеряйте использование устаревших методов и транспорта.
Проводите канареечное развертывание современного и наследуемого путей перед выводом из эксплуатации.
Относитесь к миграции как к изменению инфраструктуры, а не к обычному обновлению SDK.
Когда слой MCP станет stateless и наблюдаемым, держите доступ к моделям за отдельным интерфейсом. Это позволит протоколу инструментов и слою провайдеров моделей развиваться независимо.
