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