Версии и совместимость

Здесь описано, как клиент и сервер согласуют протокол: версию, объявляемую в каждом запросе, необязательные расширения и совместимость с прежними версиями, где было рукопожатие. Согласования-рукопожатия больше нет. Каждый запрос несёт свою версию, а сервер принимает или отклоняет каждый запрос независимо.

Термины#

Согласование версии#

Каждый запрос объявляет версию в _meta, а по HTTP ещё и в заголовке MCP-Protocol-Version (подробнее). Если сервер не реализует запрошенную версию (неизвестную ему или известную, но отключённую), он ДОЛЖЕН ответить ошибкой UnsupportedProtocolVersionError со списком поддерживаемых версий:

{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32022,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2026-07-28", "2025-11-25"],
      "requested": "1900-01-01"
    }
  }
}

Клиенту СЛЕДУЕТ выбрать из supported общую версию и повторить запрос либо показать пользователю ошибку, если совместимой версии нет.

Серверы ДОЛЖНЫ реализовывать server/discover. Клиенты МОГУТ вызвать его до других запросов, чтобы заранее узнать версии, но не обязаны: можно сразу вызвать любой метод и обработать UnsupportedProtocolVersionError.

Согласование расширений#

Клиенты и серверы могут договариваться о необязательных расширениях. Расширения объявляются в поле extensions возможностей. Это словарь «идентификатор расширения → настройки». Идентификатор ДОЛЖЕН подчиняться правилам именования ключей _meta с обязательным префиксом.

Пример клиента, который объявляет расширение MCP Apps (io.modelcontextprotocol/ui):

{
  "capabilities": {
    "roots": {},
    "extensions": {
      "io.modelcontextprotocol/ui": {
        "mimeTypes": ["text/html;profile=mcp-app"]
      }
    }
  }
}

Пример расширения Tasks (io.modelcontextprotocol/tasks):

{
  "capabilities": {
    "tools": {},
    "extensions": {
      "io.modelcontextprotocol/tasks": {}
    }
  }
}

Каждое расширение определяет схему своих настроек, а пустой объект значит поддержку без дополнительных настроек. Если одна сторона поддерживает расширение, а другая нет, поддерживающая сторона ДОЛЖНА либо вернуться к поведению базового протокола, либо отклонить запрос подходящей ошибкой. Расширениям СЛЕДУЕТ описывать, как они ведут себя в таком случае.

Совместимость с версиями на основе рукопожатия#

Сервер, который хочет поддерживать и прежних клиентов (ждущих initialize), и современных (с метаданными в запросах), МОЖЕТ реализовать оба поведения. Клиент, которому нужно работать с серверами обоих видов, определяет эпоху сервера способом, зависящим от транспорта.

• stdio. Отправить пробный server/discover и откатиться, если пришла любая ошибка, не распознанная как современная.
• Streamable HTTP. Отправить современный запрос и при 400 Bad Request проверить тело, прежде чем откатываться (подробнее).

В обоих случаях распознанная современная ошибка JSON-RPC (например, UnsupportedProtocolVersionError) означает современный сервер: нужно повторить запрос с поддерживаемой версией, а не откатываться. Всё остальное означает прежний сервер.

Эпоха — свойство сервера, а не отдельного запроса. Клиентам СЛЕДУЕТ кэшировать результат на время жизни процесса сервера (stdio) или источника (HTTP) и МОГУТ сохранять его между перезапусками той же конфигурации, повторяя пробу, если предположение перестало работать.

Сервер, который поддерживает только современные версии, СЛЕДУЕТ называть поддерживаемые версии в любой ошибке на запрос initialize, на любом транспорте: у прежних клиентов нет способа перейти вперёд, и это сообщение может оказаться единственным, что они смогут показать пользователю.

Матрица совместимости#

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

Та же матрица в виде таблицы: