What are JSON-RPC batch requests, and are they still supported in current MCP?

4 minadvancedmcpjson-rpcbatchingversioning

Quick Answer

JSON-RPC 2.0 allows batching — sending an array of multiple request/notification objects in a single message instead of one object per message, with the server replying with a corresponding array of results. Earlier MCP spec revisions permitted batching, but the 2025-06-18 spec revision removed support for JSON-RPC batching entirely — every message is now sent and processed individually. This was done to simplify implementations (batch handling adds real complexity around partial failures, ordering, and streaming responses) and because the Streamable HTTP transport's ability to stream multiple messages over one logical request/response already covers the main use case batching was solving.

Detailed Answer

This is a good example of the spec actively removing a feature, rather than only ever adding one. It's a common trip-up point when reading older MCP tutorials or blog posts that predate the change.

What batching looked like when it existed

// A single message carrying multiple requests
[
  {"jsonrpc": "2.0", "id": 1, "method": "tools/list"},
  {"jsonrpc": "2.0", "id": 2, "method": "resources/list"}
]

// Server replies with a matching array
[
  {"jsonrpc": "2.0", "id": 1, "result": {"tools": [...]}},
  {"jsonrpc": "2.0", "id": 2, "result": {"resources": [...]}}
]

Why it was removed in the 2025-06-18 revision

It added meaningful implementation complexity for uncertain benefit. Servers had to handle partial failures within a batch, preserve correct ordering, and reconcile batching with streaming responses over Streamable HTTP.
The Streamable HTTP transport already lets a server send multiple messages in response to a single logical request, via an SSE upgrade. That covers most of what batching was used for — getting several pieces of information back efficiently — without needing client-side batch construction.
Fewer message shapes to support means simpler, more uniform SDK and server implementations, and fewer edge cases when testing interoperability between independently written clients and servers.

Practical implication

If you're implementing or reviewing an MCP server today, don't build batch-request handling expecting current clients to use it. Don't assume an older tutorial's batching example still applies — check which spec version you're targeting. A server or client built against the 2025-06-18 spec (or later) should assume one JSON-RPC message per HTTP POST body, or per stdio line, full stop.