MCP 2025-06-18 spec drops batching and requires version header in production

The 2025-06-18 revision of the Model Context Protocol, published by the official specification, removes JSON-RPC batching, requires a version header on every HTTP request, and reclassifies servers as OAuth Resource Servers. Anyone who already has agents running in production needs to check compatibility before updating.

The 2025-06-18 revision of the Model Context Protocol, published by the official specification, removes JSON-RPC batching, requires a version header on every HTTP request, and reclassifies servers as OAuth Resource Servers. Anyone who already has agents running in production needs to check compatibility before updating.

The Model Context Protocol specification had a revision published on June 18, 2025, replacing the previous version from March 26 of the same year. The official MCP changelog lists changes that aren't cosmetic: they remove a transport feature, change the way clients perform OAuth authentication, and add an entirely new capability called elicitation. More than a year later, teams that put MCP servers and clients into production between late 2024 and early 2025 may still be running against the old spec without realizing where it's going to hurt.

This piece details what changes technically in each point of the revision and what to test on an already deployed server before assuming it's compatible.

JSON-RPC batching: support removed

Version 2025-06-18 removes support for JSON-RPC batching (PR #416 in the specification repository). Batching was the feature that allowed grouping multiple tools/call, resources/read, or prompts/get calls into a single JSON-RPC array, saving round-trips between client and server.

Servers that implemented their own logic to unpack request arrays need to remove that code or, at minimum, treat receiving an array as a protocol error. Clients that still send batched requests to a server updated to 2025-06-18 will receive error responses, because the server no longer knows how to interpret that format as valid. In practice, any MCP SDK that queued calls to send together needs to go back to sending one JSON-RPC request at a time.

MCP-Protocol-Version: header becomes mandatory

The revision also requires that, when using HTTP transport, the protocol version negotiated at initialization be repeated in all subsequent requests, via the MCP-Protocol-Version header (PR #548). Previously, negotiation happened only at the initial handshake and the server trusted that the session continued on the same version.

This changes the expected behavior of any proxy, API gateway, or middleware sitting between an MCP client and server. An example of a correct request after the revision:

POST /mcp HTTP/1.1
Host: servidor.exemplo.com
Content-Type: application/json
MCP-Protocol-Version: 2025-06-18

{"jsonrpc":"2.0","id":7,"method":"tools/call","params":{"name":"buscar_pedido","arguments":{"id":"123"}}}

Updated servers that receive requests without this header may reject the call or assume the wrong version. It's worth testing this directly: make a call to the production server without the header and see whether it responds with a version error or silently accepts it, which would be a sign that the server is still on the old spec.

OAuth: MCP server is now a Resource Server

The change with the most security implications is the reclassification of MCP servers as OAuth Resource Servers (PR #338), which now expose protected resource metadata pointing to the corresponding authorization server. A Resource Server is the one that validates and consumes tokens, not the one that issues them (that role belongs to the Authorization Server), and it's this position that the specification now formalizes for MCP servers. Along with this, the specification now requires clients to implement Resource Indicators, per RFC 8707 (PR #734).

In practice this prevents a concrete problem: without a resource indicator, an access token issued for an MCP server could, in theory, be reused against another malicious server posing as a legitimate resource. With resource indicators, the client explicitly states, in the token request, which resource that token is valid for, as described in RFC 8707.

Anyone who implemented their own OAuth flow for their MCP server before June 2025 probably doesn't have the protected resource metadata endpoint, nor do they implement the RFC 8707 Resource Indicators in the tokens received. This doesn't break the basic function, but it leaves the server outside the security guarantee that the current spec assumes. The changelog also points to a new security best practices page and clarifications in the authorization spec itself, which is worth reviewing line by line for anyone maintaining the OAuth layer directly.

Elicitation: server can pause and ask the user for more data

The revision adds support for elicitation (PR #382): the ability for a server, in the middle of an interaction, to ask the user for additional information before continuing. It's a new feature, not a fix, so it doesn't break anything for those who don't use it, but it changes what an MCP client needs to know how to support in order to stay compatible with servers that come to depend on it.

In short: before the revision, an MCP server only had two options when facing an incomplete request, respond with an error or try to guess the missing parameter. With elicitation, it can hand control back to the client by requesting a specific piece of data, in structured form, in the middle of executing a tool. Clients that don't implement the elicitation capability will simply be unable to complete interactions with servers that require it, so checking this during capability negotiation before connecting is important for anyone integrating third-party servers.

Structured output and resource links: less manual parsing

Two changes reduce workarounds on the client side. The first is support for structured tool output (PR #371): instead of returning only free text, a tool can return a structured object that the client consumes directly, without needing to parse strings to extract fields. The second is support for resource links inside a tool call result (PR #603), allowing the response to point to an MCP resource instead of embedding the entire content in the response.

Both are additive: an old server that only returns text continues to work, it just doesn't take advantage of the new format. But teams building generic clients to consume any MCP server need to decide whether to treat these fields as optional (output tolerant of absence) or start requiring them from partner servers.

Other changes that go unnoticed

The revision also changes a SHOULD to a MUST in the protocol's lifecycle operation, which means a previously recommended behavior became mandatory for conformance. In addition:

• The _meta field was added to more interface types, with specific usage rules (PR #710);
• CompletionRequest gained a context field, allowing completion requests to include previously resolved variables (PR #598);
• A title field was added for user-friendly display names, separating the programmatic identifier (name) from the human-readable label (PR #663).

None of these three is destructive on its own, but added to the rest they form a spec with a much larger surface than the one from March 2025.

What to test before trusting compatibility

For anyone maintaining an MCP server or client that has been running since before June 2025, the practical checklist includes: confirming whether the client sends MCP-Protocol-Version on every post-handshake HTTP request; checking whether any flow still depends on JSON-RPC batching; and checking whether the server's OAuth implementation exposes protected resource metadata and implements Resource Indicators (RFC 8707) in tokens. The complete changelog, linked on the specification page itself, lists each PR individually for anyone who needs to audit code against each specific change.

Source

1. Model Context Protocol: Specification Changelog (2025-06-18): https://modelcontextprotocol.io/specification/2025-06-18/changelog