Streamable HTTP

Коротко: Один из типов транспорта, по которым общаются клиент и сервер MCP (наряду с stdio и более старым SSE). При Streamable HTTP обмен идёт обычными HTTP-запросами к конечной точке (обычно /mcp).

Подробнее: В отличие от stdio (где клиент сам запускает процесс сервера, например node server.js), при Streamable HTTP клиент подключается к уже работающему серверу по URL — хорошо подходит, когда сервер (как здесь плагин Obsidian) и так работает как часть другого приложения.

Наш контекст: MCP-сервер Obsidian работает по адресу http://127.0.0.1:27200/mcp как конечная точка Streamable HTTP, которую мы подключили командой claude mcp add --transport http.

Подробности

Замена SSE

В 2025 году Streamable HTTP заменил более старый транспорт SSE (server-sent events) в качестве рекомендуемого стандарта MCP для сетевых соединений. Основное отличие: SSE требовал двух отдельных соединений (одно для сообщений от клиента к серверу через обычный POST, отдельное постоянно открытое для сообщений от сервера к клиенту) — Streamable HTTP объединяет оба через одну и ту же конечную точку /mcp, при этом один ответ при необходимости всё ещё может быть доставлен как поток (несколько сообщений друг за другом) вместо единого полного ответа. Это упрощение также значительно уменьшает сложность инфраструктуры на стороне сервера: вместо одновременного управления двумя разными типами соединений (включая вопрос, как синхронизировать оба при обрыве соединения) достаточно одной классической конечной точки HTTP.

stdio и сетевые транспорты

При транспорте stdio (альтернативе без сети) клиент сам запускает процесс сервера как дочерний и общается через его стандартный ввод/вывод — это работает, только если клиент и сервер запущены на одной машине. Streamable HTTP становится необходим, когда сервер работает независимо от клиента (как здесь плагин Obsidian, который запускается, как только работает сам Obsidian, независимо от того, активен ли сейчас сеанс Claude) или когда клиент и сервер должны находиться на разных машинах. Практическое преимущество stdio: поскольку клиент сам запускает и останавливает процесс, никому не нужно заниматься управлением жизненным циклом (сервер работает только пока нужен) — при сетевых транспортах вроде Streamable HTTP сервер, напротив, должен работать и оставаться доступным сам по себе, независимо от того, подключён ли сейчас клиент.

Управление сеансами и аутентификация

Поскольку Streamable HTTP работает на обычных HTTP-запросах, можно напрямую использовать стандартные веб-механизмы: сеансами можно управлять через идентификатор сеанса (например, в заголовке), а аутентификация идёт по обычным шаблонам HTTP, таким как bearer-токен в заголовке Authorization — как у классического REST API. Это практическое преимущество перед stdio, где по природе не нужна «аутентификация» в классическом смысле (клиент сам запустил сервер и работает в том же контексте безопасности), но где, в свою очередь, нет встроенного механизма на случай, если она понадобится.

Когда какой транспорт уместен

Эмпирическое правило: stdio для серверов, запускаемых чисто локально и один раз на экземпляр клиента (например, инструмент доступа к файловой системе), Streamable HTTP для серверов, существующих как самостоятельная постоянно работающая служба и потенциально используемых несколькими клиентами одновременно или в разное время — как здесь плагин Obsidian, работающий независимо от жизненного цикла отдельного сеанса Claude Code.

См. также: MCP (Model Context Protocol), Bearer-токен, HTTP