MCP 2026-07-28 Руководство по миграции: серверы без состояния

Кратко: MCP 2026-07-28 удаляет сеансы на уровне протокола и обязательное начальное рукопожатие. Командам в продакшне следует найти скрытые зависимости от сеансов, перейти на метаданные протокола в каждом запросе, внедрить многораундовые запросы, обновить политики шлюзов и провести канареечное развертывание нового протокола перед выводом из эксплуатации устаревшего поведения.

Спецификация Model Context Protocol, выпущенная 28 июля 2026 года, вводит крупнейшее архитектурное изменение в MCP со времён добавления поддержки удалённого транспорта.

Теперь протокол использует статeless-ядро «запрос–ответ». Обязательный обмен initialize и notifications/initialized удалён, Mcp-Session-Id исключён, а каждый запрос несёт протокольную информацию, необходимую для его обработки.

Релиз также вводит многораундовые запросы, HTTP-заголовки маршрутизации, кэшируемые ответы списков, более строгую авторизацию, фреймворк расширений и формальный цикл устаревания. Смотрите официальное объявление о релизе MCP 2026-07-28 и полный список изменений спецификации для деталей на уровне протокола.

Эти изменения упрощают масштабирование удалённых MCP-серверов за стандартной HTTP-инфраструктурой. Они не делают существующее приложение статeless автоматически.

Продакшн-сервер всё ещё может зависеть от in-memory рабочих пространств, закреплённой маршрутизации, привязанных к сессии учётных данных, длительных потоков или взаимодействий, инициируемых сервером. Это руководство фокусируется на поиске и замене таких зависимостей.

Для более вводного пошагового руководства читайте How to Create an MCP Server for Claude Code перед началом миграции.

Кому нужно мигрировать?

Объём работ зависит от того, как MCP используется в вашей системе.

Локальному серверу, не сохраняющему состояние между запросами, может потребоваться только обновление SDK и тестирование совместимости.

Удалённому развёртыванию, использующему сессии, OAuth, стриминг или запросы, инициируемые сервером, нужна поэтапная миграция.

Что изменилось в MCP 2026-07-28?

1. Проведите аудит текущей реализации

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

Mcp-Session-Id
initialize
notifications/initialized
sessionId
ctx.sessionId
extra.sessionId
sticky_session
sticky-session
elicitation/create
sampling/createMessage
roots/list
resources/subscribe
resources/unsubscribe
logging/setLevel
tasks/result
tasks/list
Last-Event-ID

Затем ответьте на вопросы:

1. Отклоняет ли сервер вызовы, пока инициализация не завершена?
2. Выбирает ли ID сессии пользователя, учётные данные, рабочее пространство или разговор?
3. Может ли другой инстанс сервера продолжить процесс, начатый первым?
4. Требует ли балансировщик привязки сессии?
5. Выполняет ли инструмент побочный эффект до запроса подтверждения?
6. Парсирует ли шлюз тело для определения метода или инструмента?
7. Хранятся ли OAuth-учётные данные без указания их эмитента?
8. Зависит ли клиент от переподключения SSE или повторной доставки сообщений?
9. Меняются ли списки инструментов или ресурсов в зависимости от соединения?
10. Какие устаревшие функции всё ещё получают продакшн-трафик?

Не удаляйте Mcp-Session-Id, пока не поймёте, что приложение хранит за ним.

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

2. Замените скрытое состояние сессии

MCP 2026-07-28 удаляет сессии на уровне протокола, а не состояние приложения.

Состояние, требуемое между вызовами, должно использовать один из трёх паттернов.

Явные дескрипторы

Возвращайте сгенерированный сервером дескриптор из одного инструмента и требуйте его в последующих вызовах.

{
  "resultType": "complete",
  "content": [
    {
      "type": "text",
      "text": "Workspace created."
    }
  ],
  "structuredContent": {
    "workspaceHandle": "ws_7f93a2"
  }
}

Позднейший запрос передаёт дескриптор как обычный аргумент:

{
  "name": "update_workspace",
  "arguments": {
    "workspaceHandle": "ws_7f93a2",
    "status": "approved"
  }
}

Это делает зависимость видимой в контракте инструмента и позволяет любому совместимому инстансу сервера обработать запрос.

Общее хранилище

Используйте базу данных, распределённый кэш, объектное хранилище или долговечную систему задач, когда:

• нескольким воркерам нужно одно и то же состояние;
• процесс должен пережить перезапуск;
• состояние слишком велико для дескриптора;
• процесс длится дольше одного запроса;
• требуется транзакционность или одноразовая семантика.

Защищённый requestState

MRTR может вернуть непрозрачное значение requestState, которое клиент возвращает при повторе исходного запроса.

Так как значение проходит через клиента, защитите его HMAC или аутентифицированным шифрованием. Привяжите его к аутентифицированному субъекту, исходной операции, важным параметрам, времени истечения и нонсу при необходимости защиты от повторов.

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

3. Переход на самодостаточные запросы и discovery

Современные MCP-запросы включают контекст протокола в _meta.

Вызов инструмента по Streamable HTTP может выглядеть так:

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json
Authorization: Bearer <token>
{
  "jsonrpc": "2.0",
  "id": "req-101",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": {
      "query": "stateless MCP migration"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "example-client",
        "version": "2.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "elicitation": {}
      }
    }
  }
}

Серверы, нацеленные на новый протокол, должны реализовать server/discover, который объявляет поддерживаемые версии, возможности и идентичность сервера. Клиенты могут вызывать его перед другой операцией или использовать для определения необходимости отката к наследию.

Прочитайте официальную документацию server/discover для контракта ответа.

Согласование версии в TypeScript SDK

Одно обновление TypeScript SDK не переключает клиента на новый протокол автоматически.

Клиент, использующий SDK v2, должен явно включить это:

const client = new Client(
  {
    name: "my-client",
    version: "1.0.0"
  },
  {
    versionNegotiation: {
      mode: "auto"
    }
  }
);

await client.connect(transport);

В автоматическом режиме SDK пробует server/discover и может вернуться к старому потоку инициализации при подключении к наследуемому серверу.

Команды, всё ещё использующие @modelcontextprotocol/sdk v1, должны сначала следовать официальному руководству по миграции TypeScript SDK с v1 на v2. Команды, уже использующие v2, должны использовать отдельное руководство по поддержке протокола 2026-07-28.

4. Замените запросы, инициируемые сервером, на MRTR

Ранее MCP мог отправлять запросы вроде elicitation/create, sampling/createMessage или roots/list от сервера к клиенту.

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

Поток таков:

1. Клиент отправляет исходный запрос.
2. Сервер возвращает resultType: "input_required".
3. Клиент собирает запрошенные сведения или одобрение.
4. Клиент повторяет исходную операцию с новым JSON-RPC ID.
5. Повтор включает inputResponses и исходный requestState.
6. Сервер завершает запрос или начинает новый раунд.

Пример ответа:

{
  "jsonrpc": "2.0",
  "id": "delete-1",
  "result": {
    "resultType": "input_required",
    "inputRequests": {
      "confirm_delete": {
        "method": "elicitation/create",
        "params": {
          "mode": "form",
          "message": "Delete project project_123?",
          "requestedSchema": {
            "type": "object",
            "properties": {
              "confirmed": {
                "type": "boolean"
              }
            },
            "required": ["confirmed"]
          }
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Клиент повторяет исходную операцию:

{
  "jsonrpc": "2.0",
  "id": "delete-2",
  "method": "tools/call",
  "params": {
    "name": "delete_project",
    "arguments": {
      "projectId": "project_123"
    },
    "inputResponses": {
      "confirm_delete": {
        "action": "accept",
        "content": {
          "confirmed": true
        }
      }
    },
    "requestState": "protected-expiring-state"
  }
}

Продакшн-реализация MRTR должна определить:

• максимум раундов;
• срок действия request-state;
• поведение отмены и отклонения;
• валидацию схемы ответов;
• проверки авторизации при каждом повторе;
• защиту от повторов;
• идемпотентность побочных эффектов;
• поведение, если клиент не поддерживает запрошенную возможность.

Не завершайте покупку, удаление, списание средств или внешний запись до возврата 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 предусматривает минимум двенадцать месяцев на устаревание; это не означает, что каждая функция имеет одинаковую подтверждённую дату удаления.

Изучите официальный реестр устаревших функций перед установлением срока вывода из эксплуатации.

7. Безопасно выкатывайте миграцию

Не меняйте клиентов, серверы, шлюзы, кэширование и авторизацию в одном незаметном релизе.

Рекомендуемый порядок миграции

1. Инвентаризируйте версии протокола, SDK, сессии, трафик SSE, DCR-клиентов и устаревшие методы.
2. Обновите непроизводственные SDK.
3. Добавьте server/discover и согласование версии.
4. Замените скрытые зависимости от сессий.
5. Реализуйте и обезопасьте MRTR.
6. Добавьте валидируемые заголовки маршрутизации и разделённые кэши.
7. Протестируйте границы эмитентов в авторизации.
8. Канареечно разверните современный протокол рядом с устаревшим путём.
9. Выводите старое поведение из эксплуатации только после анализа телеметрии.

Совместимость во время канареечного этапа

Современный клиент + современный сервер
→ Используют MCP 2026-07-28

Современный клиент + наследуемый сервер
→ Пробует и откатывается при поддержке

Наследуемый клиент + сервер с двумя версиями
→ Продолжает по устаревшему пути

Неподдерживаемая комбинация
→ Возвращает понятную ошибку версии протокола

Релиз новой спецификации MCP — это не одновременный переход всей экосистемы. Клиенты, серверы, SDK и хостинговые платформы будут мигрировать с разной скоростью.

Телеметрия для записи

Успешные одноразовые запросы tools/call недостаточны для измерения миграции. Процесс, который стабильно истекает по времени, запрашивает ненужный ввод или дублирует внешний запись, всё ещё считается провалом в продакшне.

Как CometAPI вписывается в архитектуру MCP

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 клиент, который используется в другом месте приложения:

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.COMETAPI_KEY,
  baseURL: "https://api.cometapi.com/v1"
});

export async function summarizeResource(content: string) {
  const response = await client.chat.completions.create({
    model: "your-selected-model",
    messages: [
      {
        role: "system",
        content: "Summarize the supplied resource clearly and concisely."
      },
      {
        role: "user",
        content
      }
    ]
  });

  return response.choices[0]?.message?.content ?? "";
}

MCP-сервер остаётся ответственным за контракт инструмента, авторизацию, состояние и обработку результата. Шлюз моделей управляет выбором модели, доступом к провайдеру и ответами инференса.

Разделение этих слоёв даёт две практические выгоды:

1. Клиенты и серверы MCP могут мигрировать на новый протокол без изменения слоя интеграции с моделями.
2. Провайдеров моделей можно менять без переработки инструментов MCP или поведения транспорта.

Для подробностей реализации см. CometAPI Quickstart, документацию API и руководство по приложениям с несколькими моделями.

Контрольный список миграции MCP 2026-07-28

Клиент

• Обновить до совместимого SDK.
• Включить современное согласование версии.
• Поддержать server/discover.
• Включать метаданные протокола в каждый запрос.
• Обрабатывать resultType.
• Поддерживать или явно отклонять MRTR.
• Использовать новый JSON-RPC ID для повторов.
• Сохранять и возвращать requestState.
• Валидировать OAuth-эмитентов.
• Хранить учётные данные по эмитенту.
• Учитывать подсказки кэширования.
• Поддерживать 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.

1. Перенесите необходимое состояние в явные дескрипторы или общее хранилище.
2. Реализуйте MRTR со сроком действия, защитой от повторов и идемпотентностью.
3. Валидируйте заголовки MCP относительно JSON-RPC-тела.
4. Разделяйте кэши по тенанту и области авторизации.
5. Ужесточите валидацию OAuth-эмитента.
6. Измеряйте использование устаревших методов и транспорта.
7. Проводите канареечное развертывание современного и наследуемого путей перед выводом из эксплуатации.

Относитесь к миграции как к изменению инфраструктуры, а не к обычному обновлению SDK.

Когда слой MCP станет stateless и наблюдаемым, держите доступ к моделям за отдельным интерфейсом. Это позволит протоколу инструментов и слою провайдеров моделей развиваться независимо.