MCP 2025-06-18 Requires OAuth Resource Server and Cuts JSON-RPC Batching: Here's What Breaks in the Migration

The Model Context Protocol (MCP) had its second formal revision published on June 18, 2025, replacing the 2025-03-26 revision. The official changelog lists changes that are not cosmetic: authentication, transport format and tool output format changed at the same time. For anyone who deployed an MCP server still on the previous revision and hasn't updated the SDK since then, the list of things that break is larger than it seems at first glance.

The angle here isn't to announce the spec, which is already nearly a year and a half old. It's to simulate the migration of a local MCP server from the 2025-03-26 revision to 2025-06-18 and map, point by point, where the code stops working.

What changes, in a table

Each row in this table is a real breaking point for anyone with a custom server or client, not just one generated by an updated official SDK.

OAuth Resource Server: the authentication puzzle

The heaviest change is the classification of the MCP server as an OAuth Resource Server (PR #338). Before, a server could accept an access token without exposing where that token came from. Now it needs to publish protected resource metadata, pointing to the corresponding Authorization Server, just like a standard resource server in any OAuth 2.0 flow.

In practice, this means a server that only validated a fixed bearer token against a hardcoded list stops being compatible with clients that strictly follow the new spec. The client, in turn, is now required to implement Resource Indicators per RFC 8707 (PR #734), precisely to prevent a malicious server from capturing a token issued for another resource and reusing it.

In short: if the server only exposes a simple API key endpoint, it still technically works, but it stops benefiting from the protections the spec added against token leakage between different MCP servers. In an environment with multiple MCP servers connected to the same client (an increasingly common scenario in agent stacks), this is the difference between a token leaking from one server to another or not.

In the migration roadmap I'd follow on a local test server, the first step would be exposing the protected resource metadata endpoint (usually at /.well-known/oauth-protected-resource) and only then touching anything else, because without it the handshake doesn't even start properly with an updated client.

No more JSON-RPC batching: goodbye to the request array

The previous revision allowed sending multiple JSON-RPC calls in a single array, saving round-trips. The 2025-06-18 revision removed this support (PR #416) with no direct replacement. Any code that builds a payload like this:

[
  {"jsonrpc": "2.0", "id": 1, "method": "tools/list"},
  {"jsonrpc": "2.0", "id": 2, "method": "resources/list"}
]

starts receiving a protocol error, because the updated server expects one JSON-RPC message at a time, not an array. The fix is mechanical, but it can be scattered across several parts of a legacy integration: replacing batching with sequential calls, accepting the extra latency, or parallelizing on the client side by opening multiple HTTP requests instead of a single batched one.

For servers that relied on batching to reduce network cost in high-latency environments (quite common in integrations running outside the data centers of major cloud providers, a typical case for part of Brazil's infrastructure), this is the change that weighs most heavily on performance, even though it isn't the flashiest one.

Structured output: tools no longer return just text

PR #371 added support for structured output in tools, and PR #603 added resource links to tool call results. Before, an MCP tool returned a content block with free text, leaving it to the model to interpret. Now it's possible to declare an outputSchema in the tool definition and return data that follows that schema, in addition to referencing external resources directly in the result instead of embedding everything as text.

This changes the contract for anyone implementing a tool. A definition that used to be just:

{
  "name": "get_weather",
  "description": "Returns the current weather"
}

can now declare the expected output format, and the client consuming that tool can validate the response against a schema instead of parsing free text. Anyone who built custom parsing logic on top of an MCP tool's text response (a regex to extract a number from a sentence, for example) loses that workaround, because structured output already delivers the data in the right format, and keeping the old parsing running in parallel becomes unnecessary technical debt.

Other changes that catch out anyone who doesn't read the full changelog

The list of minor changes in the official MCP changelog has items that seem small in isolation, but together they change the behavior of any serious integration:

• The MCP-Protocol-Version header became mandatory in HTTP requests following the initial negotiation (PR #548); without it, strict servers reject the call.
• The protocol moved from SHOULD to MUST on the lifecycle operation, closing a loophole for implementations that ignored the initialization step.
• Support for elicitation was added (PR #382), allowing the server to request additional information from the user mid-interaction, instead of failing or assuming a default value.
• The _meta field reached more interface types (PR #710), and a title field was added for a friendly name, separating the programmatic identifier from the visible label (PR #663).
• CompletionRequest gained a context field, allowing completion requests to include variables already resolved earlier (PR #598).

When it's worth migrating now and when it's worth waiting

If the MCP server runs behind a maintained official SDK (TypeScript or Python), much of these changes is absorbed by bumping the dependency version, and the manual work is concentrated on publishing the OAuth metadata and reviewing any direct use of batching. Whoever implemented the protocol by hand, without an SDK, has five fronts (auth, batching, structured output, version header and lifecycle) to review one by one before pointing an updated client at that server.

For MCP servers that only run on a local network, with no external exposure and no multiple clients sharing a token, the pressure to adopt the full OAuth Resource Server flow is lower: the spec recommends it, but a closed development environment can live with simplified authentication for longer without real risk. The point to watch is not letting that simplification leak into production just because it worked in local testing.