Session not found: почему Claude Desktop теряет сессию при подключении к MCP-серверу Vanessa Automation

Всё выглядит правильно: MCP-сервер поднят, сессия инициализируется, initialize проходит успешно — а потом первый же реальный запрос (tools/list, resources/list, prompts/list) отвечает 404 «Session not found». Сидишь и смотришь на это сообщение, не понимая, куда делась только что созданная сессия. Это не баг в твоём коде. Это столкновение двух протоколов, которые ещё не договорились, кто из них главный.

Что происходит на самом деле

MCP (Model Context Protocol) существует в двух транспортных режимах: Streamable HTTP (новый, статeful, сессионный) и SSE (старый, Server-Sent Events). Vanessa Automation 1.2.x реализует именно SSE-транспорт — это значит, что сервер ждёт долгоживущего HTTP-соединения, через которое сам толкает события.

Claude Desktop при подключении через mcp-remote по умолчанию пытается использовать Streamable HTTP. Он делает POST /mcp для инициализации, получает session ID, а потом отправляет следующий запрос — снова POST /mcp, уже с этим session ID. Vanessa его не находит, потому что для неё сессии не существует: она ждала, что клиент откроет SSE-стрим и подпишется на события.

Результат: 404 Session not found при каждом обращении после initialize.

Правильная схема подключения

Конфигурация в claude_desktop_config.json должна выглядеть так:

{
  "mcpServers": {
    "vanessa": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "http://127.0.0.1:8080/mcp",
        "--transport", "sse"
      ]
    }
  }
}

Ключ — флаг --transport sse. Без него mcp-remote 0.1.x выбирает Streamable HTTP как дефолт, и именно здесь рассыпается вся цепочка.

Если Vanessa запущена на нестандартном пути, проверь endpoint: в версии 1.2.043 это /mcp, но в более ранних сборках встречался /sse. Загляни в настройки Vanessa в разделе «HTTP-сервер» — там будет точный URL.

Дополнительные причины той же ошибки

Версия mcp-remote. В 0.1.37 есть известный баг с переподключением: если SSE-соединение рвётся и клиент переподключается, новый session ID не передаётся обратно корректно. Попробуй 0.1.35 или последний snapshot из репозитория — там это починено.

Firewall и антивирус. SSE-соединение долгоживущее (минуты и часы), некоторые корпоративные фаерволы режут соединения после 30–60 секунд простоя. Vanessa при этом думает, что клиент отключился, и удаляет сессию. Клиент же при следующем запросе ссылается на уже несуществующий ID. Признак именно этой проблемы — ошибка возникает не сразу, а через некоторое время после успешного старта.

Множественные инстанции. Claude Desktop иногда запускает несколько воркеров, каждый из которых инициализирует свою сессию. Если они конкурируют за один порт — часть запросов теряется. Проверь, что Vanessa обслуживает несколько одновременных SSE-соединений (настройка «Максимальное число подключений» в HTTP-сервере).

Проверка работоспособности без Claude

Прежде чем идти дальше, убедись, что MCP-сервер в принципе работает:

curl -N http://127.0.0.1:8080/mcp/sse

Флаг -N отключает буферизацию — ты должен увидеть поток событий в терминале. Если соединение сразу закрывается или возвращает ошибку, проблема в самой Vanessa, а не в mcp-remote.

Если curl работает, а Claude Desktop — нет, вернись к конфигу. Убедись, что node и npx доступны из того пути, откуда запускается Claude Desktop (на Windows это особенно актуально: PATH в системной среде и PATH в терминале могут отличаться).

Если после всего этого ошибка не ушла — посмотри в issues репозитория modelcontextprotocol/mcp-remote. Эта связка Vanessa + Claude Desktop + mcp-remote активно используется и проблемы там отслеживаются. Часто решение уже есть в закрытых issues, просто не задокументировано в readme.