MCP-транспорты: сравнение STDIO, SSE и Streamable HTTP для AI-агентов

Главное отличие: где живёт сервер

Три MCP-транспорта отличаются не деталями протокола, а тем, где и как запущен сервер. Это определяет всё остальное: количество клиентов, безопасность, конфигурацию, отладку и стоимость поддержки.

Rollbrains формулирует главный принцип: если сервер и клиент на одной машине и клиент же запускает сервер — это STDIO. Если сервер работает как независимый процесс где-то в сети — это Streamable HTTP. Третьего не дано.

В 2026 году спецификация MCP (ревизия 2025-11-25) определяет ровно два стандартных транспорта. HTTP+SSE (ревизия 2024-11-05) помечен как deprecated — Marius Bughiu из StartDebugging подсчитал, что 82% конфигурационных файлов Claude Desktop, Cursor и VS Code используют STDIO, а оставшиеся 18% — Streamable HTTP или SSE.

Разберём каждый транспорт по отдельности.

STDIO — локальный транспорт по умолчанию

STDIO — самый простой и безопасный транспорт. Клиент запускает MCP-сервер как дочерний процесс и общается с ним через stdin/stdout, передавая JSON-RPC сообщения, разделённые символом новой строки. Никаких портов, никакого TLS, никакого auth.

Как это работает на практике

Когда вы пишете в конфиге Claude Desktop:

{
"mcpServers": {
  "filesystem": {
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"]
  }
}
}

Claude Desktop запускает npx как дочерний процесс, дожидается его готовности, шлёт JSON-RPC по stdin и читает ответы из stdout. Всё. Никакого HTTP, никакого ожидания порта, никаких CORS-заголовков.

Что важно знать

STDIO-сервер работает с правами того пользователя, который его запустил. Секреты передаются через переменные окружения в том же конфиге. Сервер живёт, пока жив клиент — закрыл Cursor, умер и сервер.

Roo Code Docs отмечают главное ограничение: один STDIO-сервер обслуживает ровно одного клиента. Если вам нужно расшарить один MCP-сервер между несколькими IDE или агентами на разных машинах — STDIO не подходит.

Streamable HTTP — современный удалённый транспорт

Streamable HTTP (спецификация 2025-11-25) — это транспорт для всего, что работает по сети. Один MCP-endpoint (обычно /mcp) принимает POST-запросы и может опционально открывать GET-поток с SSE для server-to-client сообщений.

MCPcat называет это «подходом с одним эндпоинтом»: клиент делает POST с JSON-RPC запросом, сервер отвечает. Если серверу нужно отправить несколько сообщений (например, прогресс выполнения долгой операции), он открывает SSE-сессию, и клиент получает поток через GET-запрос к тому же /mcp endpoint'у.

Главные отличия от STDIO

Сервер работает как независимый процесс — его не запускает клиент. Он может быть развёрнут:

• на отдельном VPS с Docker
• в Kubernetes как микросервис
• за TLS-терминатором (nginx, Cloudflare)
• с OAuth / Bearer-аутентификацией

Один сервер обслуживает множество клиентов одновременно. Ginger Labs пишет, что Streamable HTTP снижает требования к развёртыванию в два раза — вместо двух эндпоинтов (как в SSE) нужен один, а сессионные заголовки позволяют балансировщику корректно маршрутизировать трафик.

Сессионный заголовок Mcp-Session-Id

Для long-lived соединений Streamable HTTP использует заголовок Mcp-Session-Id. Клиент получает его в первом ответе сервера и передаёт в последующих запросах. Это решает проблему, которая мучила разработчиков SSE: при перезапуске сервера или ребалансировке клиент просто создаёт новую сессию — никаких виснущих соединений.

HTTP+SSE (legacy) — почему устарел

HTTP+SE — это транспорт ревизии 2024-11-05, который использовал два отдельных эндпоинта: GET-эндпоинт для долгоживущего SSE-стрима и POST-эндпоинт, адрес которого клиент получал из первого endpoint-ивента SSE.

ChatForest объясняет, почему это было проблемой: SSE-соединение — это HTTP-соединение, которое сервер не закрывает годами. На каждое открытое соединение — отдельный поток в nginx, отдельный file descriptor, отдельный процесс в uWSGI. При 1000 клиентов — 1000 вечно открытых соединений. Балансировщики ненавидят это. Кеширующие прокси не понимают. Cloudflare разрывает такие соединения через 100 секунд.

Атлассиан Rovo установил дедлайн 30 июня 2026 года для прекращения поддержки SSE-транспорта в своих интеграциях. Google и Microsoft, по неофициальным данным, сделали то же самое. Если ваш MCP-сервер всё ещё использует HTTP+SSE — миграция на Streamable HTTP не вопрос выбора, а вопрос времени.

Поддержка SSE в MCP SDK не удалена — спецификация сохраняет обратную совместимость. Но в новой ревизии 2026-07-28 планируется полностью убрать SSE как отдельный transport mode и оставить только stateless requests плюс опциональное SSE-streaming внутри Streamable HTTP.

Сравнительная таблица

Сводка различий между тремя транспортами — на основе спецификации MCP Transports (2025-11-25):

Как выбрать транспорт под свою задачу

Универсальное правило простое: локальный инструмент — STDIO, удалённый сервис — Streamable HTTP. Но есть нюансы.

STDIO берём, когда:

Вы пишете MCP-сервер для Claude Desktop, VS Code, Cursor или любого другого IDE-агента, который запускается на машине разработчика. Это 80% случаев. STDIO не требует разворачивать HTTP-сервер, настраивать TLS или думать об аутентификации. В документации Claude Code все примеры конфигурации — STDIO: command + args, без портов и урлов.

Единственное, что может пойти не так — spawn npx ENOENT, когда клиент не находит Node.js. Решается явным указанием пути или использованием Python/FastMCP с mcp.run(transport='stdio').

Streamable HTTP берём, когда:

Сервер нужен не одному разработчику, а всей команде. Или он работает в CI/CD, на продакшен-сервере, или расшаривается между несколькими AI-агентами. PADISO приводит пример: MCP-сервер для доступа к общей базе знаний компании — каждый агент стучится к нему по HTTP, а не запускает свою копию.

Также Streamable HTTP — единственный выбор, если MCP-сервер должен быть доступен из браузера (веб-клиенты MCP), или если вы деплоите сервер в Kubernetes с горизонтальным масштабированием.

SSE — только для легаси

Никаких новых серверов на SSE. Только backward compatibility. Если старый сервер ещё жив — спланируйте миграцию в этом квартале. Reddit-обсуждение MCP-сообщества сходится: Streamable HTTP — это просто SSE, сделанный правильно.

Миграция с SSE на Streamable HTTP

Переезд с HTTP+SSE на Streamable HTTP — не переписывание сервера, а замена транспорта. FastMCP и Python SDK поддерживают оба режима одной строкой:

# FastMCP — меняем только последнюю строку
from fastmcp import FastMCP

mcp = FastMCP("my-server")

@mcp.tool()
def my_tool(x: int) -> int:
    return x * 2

# Было (SSE)
# mcp.run(transport="sse")  

# Стало (Streamable HTTP)
mcp.run(transport="streamable-http")

Для TypeScript SDK (v1.29.x) аналогично: McpServer с передачей транспорта в конструктор или через server.connect(transport).

Если сервер использует кастомную реализацию SSE — смотрите документацию SDK по миграции. Спецификация MCP гарантирует, что JSON-RPC сообщения не меняются — меняется только способ их передачи.

После миграции проверьте: клиент шлёт POST на /mcp, сервер отвечает, сессионные заголовки передаются. Сессии, открытые до деплоя, умрут — клиент создаст новые.

Что дальше: ревизия спецификации 2026-07-28

Следующая ревизия MCP-спецификации (2026-07-28, статус release candidate) вводит важное изменение: Streamable HTTP становится полностью stateless. Сервер может не хранить сессии — каждый POST-запрос самодостаточен.

Это развязывает руки для развёртывания через serverless-функции (AWS Lambda, Cloudflare Workers), где хранить состояние между запросами — отдельный вызов. Клиент в таком случае либо создаёт сессию на каждый запрос, либо использует токен для восстановления контекста.

SSE как отдельный транспортный режим будет полностью удалён из спецификации. Останется только STDIO и Streamable HTTP. SSE-стриминг внутри Streamable HTTP сохранится как опциональная возможность — сервер может отправить несколько JSON-RPC сообщений в одном HTTP-ответе, используя multipart или потоковую передачу.

Для разработчиков это означает: в новых проектах пишите сразу на Streamable HTTP. Через год переписывать не придётся.

Что ещё важно знать