On MCP stdio, where do the protocol version and client capabilities travel?

## The gap stdio has to fill A stdio message is one compact line of JSON followed by a newline. That is the entire framing — there is no header block, no length prefix, no metadata envelope of any kind. Anything the transport needs to say about a message therefore has to be *in* the message. The Streamable HTTP binding has somewhere else to put such things and uses it: a `MCP-Protocol-Version` header on the request, which MUST match the value inside the body or the server rejects the call. Stdio has no equivalent surface, so the in-body copy is the only copy. ## What travels in `_meta` Under revision 2026-07-28 each request's `params._meta` object carries: - **`io.modelcontextprotocol/protocolVersion`** — REQUIRED on every request. The revision date string the client is speaking. - **`io.modelcontextprotocol/clientCapabilities`** — REQUIRED on every request. An empty object `{}` is perfectly legal and means "I support none of the optional client features". - **`io.modelcontextprotocol/clientInfo`** — optional, and clients SHOULD send it. It is self-reported and explicitly **untrusted**: useful for logs, never for an authorization decision. - **`io.modelcontextprotocol/logLevel`** — optional; without it a server MUST NOT emit `notifications/message`. Results travel the other way with `io.modelcontextprotocol/serverInfo` in their `_meta`, SHOULD-level and equally untrusted. A handful of `_meta` keys are reserved by the specification, among them `progressToken`, `io.modelcontextprotocol/subscriptionId`, and the W3C Trace Context names `traceparent`, `tracestate` and `baggage`. ## Why per request, not once at startup Before revision 2026-07-28 the answer was different: the client opened with an `initialize` request stating its version and capabilities, the server replied with its own, the client sent `notifications/initialized`, and everything afterwards was interpreted in the light of that exchange. 2026-07-28 removed that handshake and made MCP a stateless protocol — every request is self-contained and carries its own protocol version and capabilities, and servers **MUST NOT** rely on prior requests over the same connection to establish context. On stdio this is more counter-intuitive than on HTTP, because the subprocess really is long-lived and really does belong to one client. The spec closes that door explicitly: an open connection, such as a stdio process, is **not** a conversation or a session. Spawning the process is not a handshake. Nothing about request N may be inferred from request N-1, even though they came down the same pipe from the same client seconds apart. ## What a server may and may not do with it A server reads the version and capabilities from the request it is serving and answers that request accordingly. If the client's declared version is one the server cannot speak, it rejects that request with `UnsupportedProtocolVersionError` (`-32022`), whose `data` names both what was requested and what is supported — the client can retry at a supported version rather than tearing the process down. If the request needs a client capability the client has not declared, the server returns `MissingRequiredClientCapabilityError` (`-32021`), naming the capabilities it needs in `data.requiredCapabilities`. A missing required `_meta` field is invalid params, `-32602`. What a server must not do is cache the first request's `_meta` and apply it to the rest. Beyond being a rule violation, it is wrong in practice: a single client may legitimately vary what it declares between calls, and a stdio process may outlive the assumptions made at spawn time. ## Practical consequences on stdio **Every request is bigger.** A few hundred bytes of metadata rides on each call. On a local pipe that is irrelevant, and it is the price of self-contained requests. **Client libraries should inject it centrally.** Hand-assembling `_meta` at every call site guarantees someone forgets it and gets `-32602` back. Put it in the transport layer. **Identity is not authentication.** `clientInfo` and `serverInfo` are strings each side chose for itself. On stdio the meaningful trust boundary is which binary the client launched, with what arguments and environment — not what the process claims to be called. **Detecting the server's era takes a call.** Over HTTP a client can read a rejection's status and body to tell a legacy server from a modern one. On stdio there is no such out-of-band channel, so the client has to send something and interpret what comes back.