EN
Связаться
Глава 14

Поймите modern lifecycle редакции 2026-07-28

Редакция 2026-07-28 - не косметическое обновление, а смена мысленной модели. Version и capabilities переехали в метаданные каждого запроса, protocol-level sessions убрали, а multi-round trips, notifications, caching и tasks изменились. Старый initialize-centric подход, где соединение сначала устанавливает сессию, больше нельзя применять по инерции - он тихо сломается на современном сервере.

Клиент теперь явно разрешает согласование редакции.

TypeScript
  const client = new Client(
    { name: "developer-release-client", version: "1.0.0" },
    {
      versionNegotiation: { mode: "auto" },
      enforceStrictCapabilities: true,
      defaultCacheTtlMs: 5_000
    }
  );

А каждый запрос сам несёт version, client info и capabilities в _meta - никакой отдельной сессии для этого не нужно.

JSON
{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "developer-release-client",
        "version": "1.0.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {
        "extensions": {}
      }
    }
  }
}

Что именно поменялось и какое инженерное последствие у каждого пункта, удобно держать рядом.

До modern era · 2026-07-28 · Инженерное последствие

  • Initialize создает protocol session - Каждый request сам описывает version/client/capabilities; Gateway может маршрутизировать request независимо
  • Mcp-Session-Id - Protocol-level session удалена; Business state храните явным handle
  • Server-initiated elicitation/sampling - Multi Round-Trip Request с input_required; Retry исходного request с новым JSON-RPC id
  • Core tasks experiment - Official tasks extension; Core остается компактнее
  • Необязательные cache hints - ttlMs и cacheScope в list/read results; Client проектирует cache явно

Логика изменений одна - сделать протокол stateless и масштабируемым. Раз initialize больше не создаёт сессию, gateway может маршрутизировать любой запрос независимо. Раз Mcp-Session-Id убрали, бизнес-состояние нужно хранить явным handle, а не привязывать к соединению. Server-initiated паттерны заменены на Multi Round-Trip Request с input_required, а необязательные cache-hints (ttlMs, cacheScope) отдают проектирование кэша клиенту.

Проверить, какую редакцию и транспорт выбрать под ваши вводные, помогает конструктор.

Интерактивная лаборатория 4

Версия и transport

Transport: stdio; launcher владеет process и environment. Version: зафиксируйте 2026-07-28 и отклоняйте неизвестные versions.

И главный практический вывод из отказа от сессий.

Не имитируйте удалённую session скрытой памятью процесса. Если операция длительная, верните явный task- или request-handle, храните состояние в durable storage и свяжите его с authorization context. Повторный HTTP-запрос может попасть в другой instance - и вся "память процесса" окажется в другом месте.

Мы поняли современный lifecycle - теперь применим его к удалённому транспорту, где stateless-природа перестаёт быть теорией.

Проверка знаний

Редакция 2026-07-28 убрала protocol-level session. Где теперь держать состояние долгой операции?

Ссылки