Files

T

retoor 251c3dc2ba research: mcp-client-support subject (106 sources, 3 conclusions)

- wire spec: lifecycle, stdio + Streamable HTTP transports, tools,
  utilities, legacy SSE, versioning, changelog (14 Tier 1)
- client ecosystem: Claude Code/VS Code/Cursor/Codex configs,
  mcp-remote, Smithery, registries, Glama (12 Tier 1)
- security/ops: authorization draft, trust model, poisoning,
  rug pulls, production hardening (12 Tier 1) + 68 Tier 2 cards
- conclusions: minimal stdlib client on 2025-11-25, normalizer +
  resolver agent for pasted configs/GitHub URLs, untrusted-until-
  consent trust model; nothing built yet
- audit PASS (14 subjects, 797 sources, 32 conclusions)

2026-10-18 19:23:02 +02:00

4.8 KiB

Raw Blame History

Transports: stdio + Streamable HTTP (2025-11-25)

Metadata

Field	Value
Institute	Molodetz Institute - Research & Retrieval Division
Subject	mcp-client-support
Document type	Source Dossier
Tier	1
Source title	Transports (MCP Specification v2025-11-25)
Source URL	https://modelcontextprotocol.io/specification/2025-11-25/basic/transports
Source publisher / author	Model Context Protocol authors (Anthropic-donated open project; site docs)
Source type	standard
Source date (published)	2025-11-25 (version stamp; no other publish date stated)
Date researched	2026-10-18
Researched by	tai (agent), model: Claude Sonnet 5, on behalf of retoor
Research method	gather-subagent direct page fetch, parent synthesis from evidence pack
Confidence	High
Status	Active

Summary

This page defines the two standard transports for 2025-11-25: stdio (newline-delimited JSON-RPC, stdout reserved for messages, stderr for logs) and Streamable HTTP (every client JSON-RPC message is a new POST; client must send Accept for both JSON and SSE and support both response types). It specifies session handling via the Mcp-Session-Id header, the MCP-Protocol-Version header on all requests after initialization, an optional standalone GET SSE stream, and a back-compat probe for the old HTTP+SSE transport.

Key findings

"MCP uses JSON-RPC to encode messages. JSON-RPC messages MUST be UTF-8 encoded." Two standard transports: stdio, Streamable HTTP. "Clients SHOULD support stdio whenever possible."
stdio: "Messages are delimited by newlines, and MUST NOT contain embedded newlines"; the server "MAY write UTF-8 strings to stderr"; "The server MUST NOT write anything to its stdout that is not a valid MCP message"; "The client MUST NOT write anything to the server's stdin that is not a valid MCP message."
Streamable HTTP: "Every JSON-RPC message sent from the client MUST be a new HTTP POST request to the MCP endpoint"; the client "MUST include an Accept header, listing both application/json and text/event-stream"; the body "MUST be a single JSON-RPC request, notification, or response."
POST of a request returns either Content-Type: text/event-stream (SSE) or application/json; "The client MUST support both."
Session: the server "MAY assign a session ID at initialization time, by including it in an Mcp-Session-Id header on the HTTP response containing the InitializeResult"; the client "MUST include it in the Mcp-Session-Id header on all of their subsequent HTTP requests"; on HTTP 404 with a session id, the client "MUST start a new session"; the client "SHOULD send an HTTP DELETE… to explicitly terminate the session."
"the client MUST include the MCP-Protocol-Version: <protocol-version> HTTP header on all subsequent requests"; missing header means the server "SHOULD assume protocol version 2025-03-26"; invalid or unsupported value yields 400 Bad Request.
The client "MAY issue an HTTP GET to the MCP endpoint" to open a standalone SSE stream; the server "MUST NOT send a JSON-RPC response on the stream unless resuming."
Back-compat probe: POST an InitializeRequest; on 400/404/405, GET the URL and if an endpoint event arrives, use the old HTTP+SSE transport.

Pros / strengths

stdio framing is specified tightly enough to implement with stdlib only (subprocess plus newline-delimited JSON), with stdout/stdin purity rules that make message/log separation unambiguous.
Streamable HTTP requirements are explicit about the parts clients usually get wrong: dual Accept types, both response content types mandatory to support, session header echo, protocol-version header, and the 404-means-restart rule.
The back-compat probe gives a concrete algorithm for talking to pre-2025-03-26 servers without guessing.

Cons / limitations / caveats

No explicit author names or publish dates appear on the page; the date above is the version stamp in the URL, per the pack's Uncertainty notes.
Streamable HTTP is the heavy lift for a stdlib client: urllib POST plus dual-type Accept, both response parsers, Mcp-Session-Id/MCP-Protocol-Version header handling, and SSE parsing are all mandatory.
Session lifecycle has a sharp edge (404 with a session id forces a fresh session), and the optional standalone GET stream adds complexity a minimal client should defer.

Relevance to tai

Directly sizes the transport work: stdio framing is trivially stdlib (subprocess plus newline-delimited JSON), while Streamable HTTP needs urllib POST with Accept for both types plus Mcp-Session-Id/MCP-Protocol-Version header handling and SSE parsing. Confirms stdio-first as the correct minimal-client order since clients SHOULD support stdio whenever possible.

Changelog

Date	Change
2026-10-18	Initial dossier created.

4.8 KiB Raw Blame History