MCP supports local process communication through stdio and remote communication through Streamable HTTP. Custom transports must preserve the protocol's message and security requirements.
- Optional discovery
server/discover obtains a capability snapshot, protocol version, and tools, resources, and prompts metadata.
- Independent request
tools/call includes per-request protocol metadata. HTTP also carries the required method and name headers.
- Result
The server returns a result, structured content, or a typed error. Discovery is not authority to execute.
The protocol described in this article is stateless. Do not assume the legacy initialize/initialized handshake.
How to read this model
A capability catalogue and two request terminals. The object is a teaching analogy. Inspecting a part highlights its role; it does not execute or simulate the software. Cabinet trays are records, workpieces are data, and latches are checks. Unless an explanation states a quantity, compartments and sample workpieces do not denote data counts. Part dimensions are not a quantitative scale.
Stdio fits local, process-owned servers
With stdio, the host launches or connects to a local server process. JSON-RPC messages travel through standard input and output. Logs must not corrupt the protocol stream, so local servers write diagnostic output to standard error.
The host controls the process lifecycle. It also decides which environment variables, files, and credentials the child process receives.
Streamable HTTP fits remote servers
Streamable HTTP sends MCP requests to an HTTP endpoint. Remote deployment adds normal web concerns: TLS, authentication, authorization, origins, rate limits, request size, load balancing, and denial-of-service protection.
In protocol revision 2026-07-28, Streamable HTTP requests include routing headers such as Mcp-Method and Mcp-Name. Gateways can route or meter calls without parsing the JSON body. The server must reject a mismatch between headers and body.
The modern lifecycle has no handshake session
The 2026-07-28 revision removed initialize, initialized, and the Mcp-Session-Id transport session. Every request carries its protocol version and relevant client capabilities in _meta.
The optional server/discover method lets a client inspect server capabilities before another request. A client can also send a self-describing request directly.
This design lets ordinary load balancers send independent requests to any compatible server instance. Application-level state remains explicit through handles, durable stores, or tool arguments.
Caching replaces some long-lived coordination
List and resource-read results can include ttlMs and cacheScope. The client uses those fields to decide how long the result remains fresh and whether it can be shared across authorization contexts.
Notifications use an opt-in subscriptions/listen stream in the modern revision. Do not confuse a notification stream with a protocol session.
Older examples use a different era
MCP revisions through 2025-11-25 use an initialization handshake and stateful session model. They can issue server-to-client requests during an active operation. Many existing SDK examples and deployments still use that lifecycle.
Name the revision in documentation, tests, and telemetry. A compatibility layer may support both eras, but the application should not mix their wire behavior in one explanation.
The legacy HTTP plus SSE transport is deprecated for new implementations in the 2026-07-28 release. Use Streamable HTTP for new remote servers.
Sources
Last verified: September 23, 2026.