[RFC] Explicitly require JSON-RPC batch support

[jspahrsummers]

Following up on discussion around the Streamable HTTP transport, this codifies a requirement that MCP implementations MUST support JSON-RPC batching in the new draft protocol revision. Until now, batching wasn't mentioned at all in the spec, and our SDKs have not generally supported it (which technically puts us out of compliance with JSON-RPC).

This required some modification to the language around the Streamable HTTP transport—good thing it's still a draft! Basically, if a POST request contains zero JSON-RPC requests, the response should be HTTP 202 Accepted; otherwise, the server can respond with one JSON object (which may itself be a batch—i.e., an array of objects) or an SSE stream.

As a minor cleanup thing, I also coalesced multiple different docs pages that all had slightly varying explanation of the core message types of JSON-RPC.

[JosephMoniz]

This implies mutual exclusion between requests/notifications and responses. Is that the intent?

It seems interesting to support the batching of all of them in a single batch. The structure of JSON-RPC supports this.

[jspahrsummers]

That is indeed the intent, based on how JSON-RPC defines batching in https://www.jsonrpc.org/specification#batch.

I don't think plain JSON-RPC permits mixing the two, although it's not really a bidirectional spec, so hard to say. My main concern here would be remaining compatible with any off-the-shelf JSON-RPC libraries that one might happen to grab.

[daviddenton]

There is a wrinkle/complexity in SDK and client implementations regarding to how this relation to an original request is transmitted inside the message - especially if the messages are replayed as the response to a stream GET request. For progress to requests we have progress tokens whereas there is no such facility for the Sampling. Maybe we could specify using a Progress Token inside of the meta of the SamplingRequest in this case? This would be consistent at least with progress.

As an example - consider the possibility that Claude Desktop gains the ability to do Sampling/Progress - since it communicates purely through a serialised stream of StdIO - there is no way to relate a Sampling Request to an outgoing request.

[jspahrsummers]

"Relate to" is specified quite loosely, on purpose. There doesn't need to be an identifier that links the two, this is basically just saying that servers should not abuse the per-request SSE stream to send unrelated requests.

[daviddenton]

A neat (and probably simple to implement from the server-side) enhancement here might be for replayability to be available to clients via HTTP GET with the last-message-id and session id headers. This would return a JSONRPC batch array in the response.

Considerations:

• The batch size would probably need to be limited (and maybe controlled though a query parameter).
• Semantics for "more messages available" or "latest event id" via a header in the response.

[jspahrsummers]

A neat (and probably simple to implement from the server-side) enhancement here might be for replayability to be available to clients via HTTP GET with the last-message-id and session id headers. This would return a JSONRPC batch array in the response.
…
Semantics for "more messages available" or "latest event id" via a header in the response.

Resumability is already supported with Last-Event-Id, but this is part of SSE, so shouldn't be extended to apply to JSON-RPC batching. SSE will remain an important part of the transport spec, and I don't want to port or duplicate its capabilities in other ways.

The batch size would probably need to be limited (and maybe controlled though a query parameter).

Limits can be implementation-defined. I don't follow how a query parameter would work here?

[dsp-ant]

I wish we had separated the addition of batching and reformatting a bit more, this was not super easy to read through and understand the exact delta.

[jspahrsummers]

I wish we had separated the addition of batching and reformatting a bit more, this was not super easy to read through and understand the exact delta.

They are separated per commit.

[atesgoral]

A JSON-RPC peculiarity that might throw implementers is that a response to a batch request may be collapsed into a single object if it ends up being an array with a single object. Maybe we can make a note of that somewhere.

[jspahrsummers]

Hmm, my interpretation of the spec is that an array is required unless an overall error (like a parse error) occurs—in which case, a single response object can be used to indicate that error.

[flyflypeng]

From the discussion in this https://github.com/modelcontextprotocol/specification/pull/206， I still don't understand why batch support is being added, or is it just to improve JSON-RPC compatibility?