SSE Transport

SSE Transport establishes a long-lived HTTP connection from the client to the server. Once connected, the server can asynchronously push messages (JSON-RPC notifications, responses) to the client at any time. This is ideal for scenarios where the server is the primary source of events, such as streaming log updates, real-time notifications, or the results of long-running tool executions. The client sends requests over the same connection, but the server's ability to push independently is the defining characteristic.

• Client Role: Initiates and maintains the connection, sends requests.
• Server Role: Listens for requests, processes them, and can push messages without a direct client request.

SSE is built on standard HTTP/1.1, making it broadly compatible with existing web infrastructure, proxies, and firewalls without requiring special protocols like WebSockets. It uses a simple text-based stream format where messages are sent as a sequence of data: fields, terminated by two newlines. For MCP, each JSON-RPC message is framed within this format. This simplicity reduces implementation complexity compared to bidirectional protocols, as it relies on a standard EventSource API on the client side and straightforward text streaming on the server side.

The SSE protocol includes a built-in reconnection mechanism. If the connection drops, the client's EventSource will automatically attempt to reconnect after a brief delay. The server can suggest a retry time using the retry: field. For MCP, this necessitates that both client and server are stateless or can gracefully recover session state after a disconnect. The client must be prepared to re-issue any necessary initialization requests (like capability negotiation) upon reconnection. This makes SSE Transport robust for network-unstable environments but requires careful design to avoid side effects from duplicated operations.

SSE Transport is particularly suited for scenarios where the MCP server is a remote process or a web service accessible via HTTP, as opposed to a local subprocess. It is the standard transport for connecting to MCP servers hosted on different machines or in cloud environments. For example, a company could host a centralized MCP server exposing internal APIs and databases, and multiple AI assistant clients (like Claude Desktop) could connect to it securely over the network using SSE. It aligns with web architecture patterns, making it easier to secure, scale, and load balance than direct stdio connections.

SSE Transport differs fundamentally from Stdio Transport, which is the other primary MCP transport.

• Communication Model: SSE is network-based (client-server over HTTP); Stdio is local (parent-child process via standard streams).
• Directionality: SSE allows server push; Stdio is strictly request-response over the duplex stream.
• Use Case: SSE is for remote, web-accessible servers; Stdio is for integrating local scripts, command-line tools, and filesystem-based resources where the server is spawned as a subprocess by the client.
• Complexity: SSE requires an HTTP server; Stdio requires process lifecycle management.

MCP leverages the SSE event stream format to frame its JSON-RPC messages. Each MCP message is sent as a distinct SSE event. The basic format is:

codeCopy
data: <JSON-RPC Message>

The double newline delimits events. For MCP, the event: field is typically omitted, making the data: field contain the complete JSON-RPC object. The client and server must correctly serialize/deserialize JSON to/from this text stream and handle the framing to avoid message corruption. This lightweight framing is less complex than length-prefixed binary formats but requires careful handling of newlines within the JSON payload itself.

An MCP Transport is the underlying communication layer responsible for the bidirectional exchange of JSON-RPC messages between an MCP client and server. It defines the physical or logical channel and the framing protocol for data.

• Primary Types: Includes Stdio Transport (for local processes), SSE Transport (for web/remote servers), and Named Pipes (for inter-process communication on the same host).
• Abstraction Layer: Decouples the core MCP protocol logic from the specifics of how bytes are sent and received, enabling flexibility across different deployment environments.
• Framing: Each transport must implement a message framing method to delimit individual JSON-RPC messages within the byte stream, ensuring reliable parsing.

Stdio Transport is an MCP communication method where the client and server exchange JSON-RPC messages over standard input (stdin) and standard output (stdout) streams.

• Local Integration: Primarily used for integrating with local command-line tools, scripts, or daemons running as child processes.
• Framing Protocol: Messages are typically delimited by newline characters (\n) and must conform to the JSON-RPC specification.
• Use Case: Ideal for scenarios where the MCP server is a standalone executable that the client spawns and manages directly, offering simple configuration and low latency on a single machine.

JSON-RPC is a stateless, lightweight remote procedure call protocol encoded in JSON. It serves as the universal message format for all communication within the Model Context Protocol.

• Request-Response Model: Defines structures for requests (method invocation with id), responses (result or error with matching id), and notifications (one-way messages without an id).
• MCP Mapping: Core MCP operations—like tools/list, resources/list, or tools/call—are implemented as specific JSON-RPC methods.
• Transport Agnostic: The same JSON-RPC message structure is used over Stdio, SSE, or any other compliant transport, ensuring protocol consistency.

Message Framing refers to the technique used to delineate the boundaries of individual, complete JSON-RPC messages within a continuous transport stream.

• Problem Solved: Transports like stdio or TCP are byte streams; framing allows the receiver to know where one message ends and the next begins.
• Transport-Specific Implementation:
  • Stdio: Often uses newline separation (\n).
  • SSE: Uses the formal Server-Sent Events format, where each message is an event: field followed by a data: field containing the JSON-RPC payload.
• Critical for Reliability: Correct framing is essential to prevent parsing errors and ensure the integrity of the MCP session.

Connection Pooling is a client-side performance optimization where a cache of active, reusable connections to MCP servers is maintained.

• Reduces Overhead: Avoids the latency and resource cost of repeatedly establishing new transport sessions (e.g., new HTTP handshakes for SSE) for each interaction.
• Manages State: The pool manages the lifecycle of connections, handling reconnection logic in case of network failure or server restart.
• SSE Relevance: Particularly beneficial for SSE Transport, where maintaining a long-lived HTTP connection is resource-intensive. A pool allows multiple client components to share a single, stable SSE connection to a remote server.

Capability Negotiation is the initial handshake process in an MCP session where the client and server exchange their supported protocol versions and feature sets.

• Initialization: Occurs immediately after the transport connection is established, via the initialize and initialized JSON-RPC exchange.
• Declared Capabilities: The server announces which MCP features it provides (e.g., resources, tools, prompts). The client declares which of these it intends to use.
• Transport Role: The chosen transport (SSE, Stdio, etc.) is the conduit for this negotiation. It ensures both parties agree on a compatible protocol version before any substantive data exchange begins, preventing runtime errors.