I noticed in the latest Spec that batch requests are no longer supported. In my opinion, this is a deviation from JSON-RPC 2.0 spec. Regardless of whether that deviation is merited, I think it's important to be more explicit about this in the documentation. Currently, the Spec/documentation does not state anything about the lack of support for batch requests, except for in the "Key Changes" from the last version. Given that JSON-RPC (a) is part of the base messaging protocol, (b) is widely used and tooling exists for it, and (c) is clear that "the Client MAY send an Array filled with Request objects", I think it's important to be explicit about this deviation.

For instance, the spec does explicitly state:

Unlike base JSON-RPC, the id of a request/response (notifications excluded) MUST NOT be null.

So, there's precedent for some deviation from JSON-RPC, and this deviation is clearly documented in one of the first documents. I think a similar notice should be added regarding the lack of support for batching. In this PR, I've added such language where appropriate.

One point I am unclear is whether MCP currently disallows batch requests or whether it simply no longer requires support for them. I.e. which of the following is correct:

• A server MUST (or SHOULD) not respond to a batch request.
• A server MAY refuse to respond to a batch request.

The "Key Changes" section says "Remove support for JSON-RPC batching" - but I'm not sure which of the above is intended. The stronger, first reading seems implied; on the other hand, PR #416 discusses removing the requirement - which is more suggestive of the weaker, second reading. After reading the relevant sections, I think the first reading is closer to what is intended, but I'm not sure.

Additionally I'm not sure if support for batching is allowed for backwards-compatibility purposes.

So, some of the content of the text proposed in this minor clarification may be incorrect - but I think the need for an explicit statement is still appropriate.

Motivation and Context

It improves the clarity of the schema by making any deviations from JSON-RPC 2.0 more explicit.

How Has This Been Tested?

N/A

Breaking Changes

No - this is only meant to make more explicit what the Spec is already supposed to have declared.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

See the comment here