Communication Lifecycle, JSON-RPC, and Transports

MCP communication follows a lifecycle with initialization, message exchange, and termination.

During initialization, the client connects to the server. The client and server can negotiate capabilities so the client knows which tools, resources, prompts, and other features are available.

During message exchange, the client makes requests and the server returns responses. The model may request a tool or resource, the server processes the request, and the client integrates the result into the model's workflow. MCP also supports features such as tool invocation, result handling, request cancellation, progress tracking, authentication, rate limiting, and user consent and control.

During termination, the client and server end their interaction.

The structured message format used for this communication is JSON-RPC. It provides a predictable way for components to exchange requests, results, and errors. MCP builds its capability negotiation and tool, resource, and prompt interactions on top of this structured communication.

A transport handles the underlying movement of messages. The transport depends on whether the server is local or remote.

For a local server, standard input and standard output can connect the host and server on the same machine. The analogy is two people working in the same kitchen and passing written notes directly. There is no need for a remote service between them.

For a remote server, server-sent events and streamable HTTP are described as connection options. JavaScript implementations also include WebSocket streaming support.

A stateful connection remembers information across an interaction. The restaurant analogy is a seated diner and a waiter. The waiter remembers the table and earlier order, so the diner can ask for the same drink again without restating everything.

A stateless interaction treats each request independently. The fast-food analogy is a customer who places a new order and receives a new ticket each time. The cashier does not rely on the details of the previous order, so each request must contain what is needed.

Streamable HTTP is presented as the preferred remote transport because it can support both stateful and stateless interaction. This allows a server to maintain continuity when needed while also supporting independent requests when that pattern is more appropriate. In one no-code implementation interface, the older server-sent-events option is shown as deprecated and streamable HTTP is selected for the new connection.