• Specification

• Key Changes

• Architecture

• Schema Reference

1. stdio, communication over standard in and standard out
2. Streamable HTTP

​

stdio

• The client launches the MCP server as a subprocess.
• The server reads JSON-RPC messages from its standard input (stdin) and sends messagesto its standard output (stdout).
• Messages are individual JSON-RPC requests, notifications, or responses.
• Messages are delimited by newlines, andMUST NOT contain embedded newlines.
• The serverMAY write UTF-8 strings to its standard error (stderr) for anylogging purposes including informational, debug, and error messages.
• The clientMAY capture, forward, or ignore the server’sstderr outputandSHOULD NOT assumestderr output indicates error conditions.
• The serverMUST NOT write anything to itsstdout that is not a valid MCP message.
• The clientMUST NOT write anything to the server’sstdin that is not a valid MCPmessage.

​

Streamable HTTP

​

Security Warning

1. ServersMUST validate theOrigin header on all incoming connections to prevent DNS rebinding attacks
   • If theOrigin header is present and invalid, serversMUST respond with HTTP 403 Forbidden. The HTTP responsebodyMAY comprise a JSON-RPCerror response that has noid
2. When running locally, serversSHOULD bind only to localhost (127.0.0.1) rather than all network interfaces (0.0.0.0)
3. ServersSHOULD implement proper authentication for all connections

​

Sending Messages to the Server

1. The clientMUST use HTTP POST to send JSON-RPC messages to the MCP endpoint.
2. The clientMUST include anAccept header, listing bothapplication/json andtext/event-stream as supported content types.
3. The body of the POST requestMUST be a single JSON-RPCrequest,notification, orresponse.
4. If the input is a JSON-RPCresponse ornotification:
   • If the server accepts the input, the serverMUST return HTTP status code 202Accepted with no body.
   • If the server cannot accept the input, itMUST return an HTTP error status code(e.g., 400 Bad Request). The HTTP response bodyMAY comprise a JSON-RPCerrorresponse that has noid.
5. If the input is a JSON-RPCrequest, the serverMUST eitherreturnContent-Type: text/event-stream, to initiate an SSE stream, orContent-Type: application/json, to return one JSON object. The clientMUSTsupport both these cases.
6. If the server initiates an SSE stream:
   • The serverSHOULD immediately send an SSE event consisting of an eventID and an emptydata field in order to prime the client to reconnect(using that event ID asLast-Event-ID).
   • After the server has sent an SSE event with an event ID to the client, theserverMAY close theconnection (without terminating theSSE stream)at any time in order to avoid holding a long-lived connection. The clientSHOULD then “poll” the SSE stream by attempting to reconnect.
   • If the server does close theconnection prior to terminating theSSE stream,itSHOULD send an SSE event with a standardretry field beforeclosing the connection. The clientMUST respect theretry field,waiting the given number of milliseconds before attempting to reconnect.
   • The SSE streamSHOULD eventually include a JSON-RPCresponse for theJSON-RPCrequest sent in the POST body.
   • The serverMAY send JSON-RPCrequests andnotifications before sending theJSON-RPCresponse. These messagesSHOULD relate to the originating clientrequest.
   • The serverMAY terminate the SSE stream if thesessionexpires.
   • After the JSON-RPCresponse has been sent, the serverSHOULD terminate theSSE stream.
   • DisconnectionMAY occur at any time (e.g., due to network conditions).Therefore:
     • DisconnectionSHOULD NOT be interpreted as the client cancelling its request.
     • To cancel, the clientSHOULD explicitly send an MCPCancelledNotification.
     • To avoid message loss due to disconnection, the serverMAY make the streamresumable.

​

Listening for Messages from the Server

1. The clientMAY issue an HTTP GET to the MCP endpoint. This can be used to open anSSE stream, allowing the server to communicate to the client, without the client firstsending data via HTTP POST.
2. The clientMUST include anAccept header, listingtext/event-stream as asupported content type.
3. The serverMUST either returnContent-Type: text/event-stream in response tothis HTTP GET, or else return HTTP 405 Method Not Allowed, indicating that the serverdoes not offer an SSE stream at this endpoint.
4. If the server initiates an SSE stream:
   • The serverMAY send JSON-RPCrequests andnotifications on the stream.
   • These messagesSHOULD be unrelated to any concurrently-running JSON-RPCrequest from the client.
   • The serverMUST NOT send a JSON-RPCresponse on the streamunlessresuming a stream associated with a previous clientrequest.
   • The serverMAY close the SSE stream at any time.
   • If the server closes theconnection without terminating thestream, itSHOULD follow the same polling behavior as described for POST requests:sending aretry field and allowing the client to reconnect.
   • The clientMAY close the SSE stream at any time.

​

Multiple Connections

1. The clientMAY remain connected to multiple SSE streams simultaneously.
2. The serverMUST send each of its JSON-RPC messages on only one of the connectedstreams; that is, itMUST NOT broadcast the same message across multiple streams.
   • The risk of message lossMAY be mitigated by making the streamresumable.

​

Resumability and Redelivery

1. ServersMAY attach anid field to their SSE events, as described in theSSE standard.
   • If present, the IDMUST be globally unique across all streams within thatsession—or all streams with that specific client, if sessionmanagement is not in use.
   • Event IDsSHOULD encode sufficient information to identify the originatingstream, enabling the server to correlate aLast-Event-ID to the correct stream.
2. If the client wishes to resume after a disconnection (whether due to network failureor server-initiated closure), itSHOULD issue an HTTP GET to the MCP endpoint,and include theLast-Event-IDheader to indicate the last event ID it received.
   • The serverMAY use this header to replay messages that would have been sentafter the last event ID,on the stream that was disconnected, and to resume thestream from that point.
   • The serverMUST NOT replay messages that would have been delivered on adifferent stream.
   • This mechanism applies regardless of how the original stream was initiated (viaPOST or GET). Resumption is always via HTTP GET withLast-Event-ID.

​

Session Management

1. A server using the Streamable HTTP transportMAY assign a session ID atinitialization time, by including it in anMCP-Session-Id header on the HTTPresponse containing theInitializeResult.
   • The session IDSHOULD be globally unique and cryptographically secure (e.g., asecurely generated UUID, a JWT, or a cryptographic hash).
   • The session IDMUST only contain visible ASCII characters (ranging from 0x21 to0x7E).
   • The clientMUST handle the session ID in a secure manner, seeSession Hijacking mitigations for more details.
2. If anMCP-Session-Id is returned by the server during initialization, clients usingthe Streamable HTTP transportMUST include it in theMCP-Session-Id header onall of their subsequent HTTP requests.
   • Servers that require a session IDSHOULD respond to requests without anMCP-Session-Id header (other than initialization) with HTTP 400 Bad Request.
3. The serverMAY terminate the session at any time, after which itMUST respondto requests containing that session ID with HTTP 404 Not Found.
4. When a client receives HTTP 404 in response to a request containing anMCP-Session-Id, itMUST start a new session by sending a newInitializeRequestwithout a session ID attached.
5. Clients that no longer need a particular session (e.g., because the user is leavingthe client application)SHOULD send an HTTP DELETE to the MCP endpoint with theMCP-Session-Id header, to explicitly terminate the session.
   • The serverMAY respond to this request with HTTP 405 Method Not Allowed,indicating that the server does not allow clients to terminate sessions.

​

Sequence Diagram

​

Protocol Version Header

​

Backwards Compatibility

• Continue to host both the SSE and POST endpoints of the old transport, alongside thenew “MCP endpoint” defined for the Streamable HTTP transport.
  • It is also possible to combine the old POST endpoint and the new MCP endpoint, butthis may introduce unneeded complexity.

1. Accept an MCP server URL from the user, which may point to either a server using theold transport or the new transport.
2. Attempt to POST anInitializeRequest to the server URL, with anAccept header asdefined above:
   • If it succeeds, the client can assume this is a server supporting the new StreamableHTTP transport.
   • If it fails with the following HTTP status codes “400 Bad Request”, “404 NotFound” or “405 Method Not Allowed”:
     • Issue a GET request to the server URL, expecting that this will open an SSE streamand return anendpoint event as the first event.
     • When theendpoint event arrives, the client can assume this is a server runningthe old HTTP+SSE transport, and should use that transport for all subsequentcommunication.

​

Custom Transports