MCP в Claude Code после перехода на stateless: 6 шагов подключения по HTTP

Что такое MCP в Claude Code и зачем ему stateless transport?

Если отбросить лишние термины, схема выглядит так:

• Claude Code получает задачу от тебя.
• MCP-клиент Claude Code обращается к подключённому MCP-серверу.
• MCP-сервер отдаёт внешний инструмент или данные.
• Claude Code использует результат в работе.

Например, подключённый сервер может дать доступ к базе данных, системе мониторинга или другому сервису. MCP здесь не заменяет Claude Code и не превращает его в отдельную программу. Он добавляет внешний доступ.

Спецификация от 28 июля 2026 выкидывает обязательную сессию. Вместо неё - каждый запрос сам за себя. Старый вариант держался на обязательном handshake, идентификаторе сессии и живом двустороннем соединении. Новый отправляет каждый запрос самостоятельно.

Для тебя это не означает обязательную замену всего конфига одним махом. Изменение прежде всего касается удалённого HTTP MCP-сервера и способа, которым он обменивается запросами. Конкретное заявление о массовой ручной миграции уже работающих .mcp.json в найденных материалах отсутствует.

Если удалённый сервер уже работает через подходящий HTTP-вариант, сначала проверь подключение. Не переписывай конфигурацию только потому, что вышла новая спецификация.

Что произойдёт с session ID?

Раньше подключение начиналось с обязательного handshake. Я напомню, как это работало: клиент и сервер обменивались служебными данными, после чего сервер связывал запросы с транспортной сессией. Её обозначал заголовок Mcp-Session-Id.

В MCP 2026-07-28 этот слой убрали:

• обязательного initialize больше нет;
• обязательного initialized больше нет;
• заголовок Mcp-Session-Id больше не нужен;
• запрос сам содержит сведения о версии протокола, клиенте и возможностях в _meta.

Схема стала проще:

Было:
initialize -> session ID -> запросы внутри сессии

Стало:
самостоятельный запрос + _meta -> самостоятельный ответ

Это и есть разница между stateful и stateless transport в практическом смысле. Сервер больше не обязан помнить транспортную сессию между вызовами.

Но слово stateless легко понять слишком широко. Оно не означает, что серверу запрещено хранить прикладное состояние. Допустим, инструмент запускает длительную задачу. Сервер может создать handle, вернуть его в ответе, а следующий вызов получит этот идентификатор как аргумент.

Вместо скрытой транспортной связи появляется явная передача состояния:

{
  "handle": "task-abc-123",
  "action": "continue"
}

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

Вот где это реально помогает: любой запрос может попасть на любой экземпляр сервера за обычным round-robin load balancer. Общая память сессий между экземплярами для транспортного уровня не нужна.

HTTP MCP и stateless transport: в чём разница?

Тут смешиваются три разных понятия.

Поэтому фраза «HTTP MCP стал stateless» не означает, что слово HTTP исчезло. Наоборот, HTTP остаётся каналом, а stateless меняет поведение запросов внутри него.

Я смотрю на это так. Зачем это удалённым серверам:

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

Авторы MCP прямо связывают переход с надёжностью и масштабированием удалённых серверов. Локальный процесс, запущенный через stdio, от этого автоматически удалённым не становится.

SSE не исчезает в тот же день. Для legacy HTTP+SSE заявлен переходный период минимум 12 месяцев. Подробнее о переходе читай в разборе stateless-транспорта. Но для нового удалённого сервера я бы не выбирал SSE, если есть обычный HTTP endpoint с поддержкой нужной версии протокола.

Здесь есть граница ответственности. Claude Code может показать, что сервер доступен. Это не доказывает полную совместимость сервера с новой спецификацией. В найденном changelog Claude Code есть подтверждение поддержки Streamable HTTP с версии 1.0.27, но отдельного подтверждения полной реализации всех изменений 2026-07-28 для версии v2.1.226 нет.

После смены транспорта сервер может продолжать хранить данные приложения. Например, task_id, browser_id или другой handle могут вести к состоянию в хранилище. Исчезает не состояние вообще, а скрытая привязка к транспортной сессии.

Как подключить MCP к Claude Code после перехода?

1. Подготовь URL удалённого сервера.

   Нужен адрес MCP endpoint, который отдаёт поставщик сервера. Если впервые настраиваешь MCP, начни с подключения первого инструмента. Для удалённого подключения используй URL, а не локальную команду запуска.

   Общий проектный конфиг Claude Code хранится в файле .mcp.json. Я бы сначала открыл уже существующий файл и посмотрел, какие серверы там описаны. Рабочие строки не трогай без причины.

2. Добавь сервер с типом HTTP.

   В конфиге укажи имя сервера, type: "http" и URL.

   Минимальный пример:

   json

   Скопировать

   {
     "mcpServers": {
       "example": {
         "type": "http",
         "url": "https://example.com/mcp"
       }
     }
   }

   Если у сервера нужна авторизация, используй способ, который описал его поставщик. В фактуре нет универсального блока для всех вариантов авторизации, поэтому я не буду добавлять выдуманные поля.

3. Перезапусти Claude Code.

   Закрой текущий процесс и запусти его снова после изменения .mcp.json. Так ты уберёшь ситуацию, когда Claude Code продолжает работать со старым содержимым конфигурации.

   После запуска открой команду:

   Скопировать

   /mcp

   Она нужна для проверки подключения в интерфейсе Claude Code.

4. Проверь сервер через CLI.

   Выполни команды проверки по очереди:

   bash

   Скопировать

   claude mcp list
   claude mcp get example

   В первой команде ищи сервер в списке. Во второй проверь, что Claude Code видит настройки именно этого сервера.

5. Вызови тестовый инструмент.

   Одного появления сервера в списке мало. Попроси Claude Code вызвать один узкий инструмент с безопасным чтением данных и покажи результат.

   Проверка MCP-подключенияСкопировать промпт

   Вызови у MCP-сервера example один безопасный инструмент только для чтения. Не изменяй данные и не запускай операции записи. Покажи название вызванного инструмента, переданные аргументы и короткий фактический результат.

   Так ты проверишь не только наличие записи в конфиге, но и рабочий обмен между Claude Code, MCP-клиентом и сервером.

6. Остановись при несовпадении результата.

   Если сервер виден, но тестовый инструмент не отвечает, не переписывай весь конфиг и не добавляй случайные параметры. Сначала переходи к диагностике по уровням: список, ответ инструмента, уведомления, повтор запроса после обрыва.

Эта последовательность не подтверждает полную совместимость сервера с новой спецификацией. Она показывает, где именно ломается подключение.

Подключение MCP руками хорошо показывает одну вещь: ИИ-агент - ему мало дать URL. Нужно уметь читать конфиг, проверять один рабочий сценарий и останавливать опасную автоматическую правку. На практикуме я показываю эту связку руками: как ставить задачу агенту, ограничивать область изменений и принимать результат по выводу команды, а не по словам «готово».

Как обновить MCP config в JSON?

Новая минимальная запись выглядит так:

{
  "mcpServers": {
    "example": {
      "type": "http",
      "url": "https://example.com/mcp"
    }
  }
}

Разбор по строкам:

• mcpServers содержит подключённые серверы;
• example - имя, под которым сервер отображается в Claude Code;
• type: "http" говорит, что подключение идёт к удалённому HTTP-серверу;
• url содержит адрес MCP endpoint.

Переходный SSE-вариант не стоит использовать для нового подключения, если сервер уже предлагает HTTP:

{
  "mcpServers": {
    "legacy-example": {
      "type": "sse",
      "url": "https://example.com/sse"
    }
  }
}

SSE не объявлен мгновенно нерабочим. Для legacy HTTP+SSE есть переходное окно минимум 12 месяцев. Но документация Claude Code называет SSE deprecated и рекомендует HTTP для удалённых MCP-серверов.

Не делай массовую замену строк вслепую. В найденной фактуре нет официального заявления Claude Code, что после 2026-07-28 каждую старую запись в .mcp.json обязательно надо вручную мигрировать. Сначала проверь текущий сервер через /mcp, claude mcp list и claude mcp get <name>.

Если сервер не подключается, сохрани копию рабочего блока и меняй одну вещь за раз. Иначе после сбоя ты не поймёшь, сломал ли URL, тип транспорта, авторизацию или сам сервер.

Что проверить, если MCP-коннектор не работает?

1. Проверь наличие сервера. Если сервер не отображается в /mcp, проблема начинается на уровне конфига или запуска. Сверь имя, type: "http" и URL.

2. Проверь ответ инструмента. Видимый сервер ещё не означает рабочий вызов. Запроси один безопасный инструмент только для чтения и посмотри фактический ответ.

3. Проверь состояние. Если инструмент раньше использовал sessionid, перенеси это состояние в явный параметр или handle. Сервер должен проверять принадлежность handle текущему пользователю или проекту при каждом вызове.

4. Проверь инициализацию и кэш. Если кэш создавался во время initialize, после его удаления подготовку может понадобиться перенести на первый реальный запрос. Иначе подключение формально работает, но ожидаемые данные не появляются.

5. Проверь уведомления. Сервер способен принять остаточный mcp-session-id, но уведомления при этом могут игнорироваться. Поэтому одного успешного вызова инструмента недостаточно, если сценарий зависит от уведомлений, подписок или изменений каталога.

6. Повтори запрос после обрыва. В новой модели оборванный поток теряет выполняющийся запрос. Клиенту может потребоваться повторная отправка с новым ID.

   [!warning] Повтор не всегда безопасен Повторный запрос может запустить операцию ещё раз. Для создания, оплаты или удаления нельзя считать автоматический retry безопасным без идемпотентности или отдельного ключа операции.

7. Проверь сервер, а не только Claude Code. В Claude Code changelog есть поддержка Streamable HTTP, но отдельного подтверждения полной совместимости версии v2.1.226 со всеми возможностями 2026-07-28 нет. Поэтому ошибка может жить на стороне сервера или несовместимого SDK.

Есть ещё один крайний случай. В stateless-режиме сервер не может самостоятельно инициировать запрос клиенту через старую живую сессию. Для сценария с подтверждением или данными от пользователя нужен подходящий механизм MRTR: сервер возвращает input_required, а клиент повторяет исходный вызов с ответами в inputResponses.

Локальный MCP сломается или нет?

Если MCP запускается локально через stdio, он остаётся локальным процессом. Новый релиз сам по себе не превращает его в HTTP-сервис.

Разделяй два случая:

• stdio - локальная команда или процесс;
• http - удалённый сервер по URL.

Для локального сервера не нужно менять запись только потому, что в спецификации появился stateless core. Сначала проверь, что именно подключено в .mcp.json.

Миграция нужна в другом случае: если сервер удалённый и работает через legacy HTTP+SSE или использует скрытое состояние транспортной сессии. Тогда смотри на поддержку type: "http", явные handles и поведение после обрыва запроса.

Вопросы и ответы