MCP 2025-06-18: what breaks in agents and integrations when upgrading versions

The official Model Context Protocol specification documents, in the 2025-06-18 revision's changelog, a set of changes that reshape core parts of the protocol used to connect AI agents to external tools and data. The revision was published on June 18, 2025, which means it's already more than a year old. Even so, it's common to find MCP servers and clients in production that still speak the previous revision, 2025-03-26, and that will break (or have already broken, without anyone noticing) when talking to an updated counterpart.

This is the practical problem: MCP has no explicit warning mechanism for when the two ends diverge in version on points of behavior, only during protocol negotiation. This means integration errors show up as a silent failure, a timeout, or a misinterpreted response, not as a clear "incompatible version" message. It's worth mapping out exactly where this happens before updating an SDK in production.

What changed, summarized

The source lists the revision's main changes. The four that most affect code already written are:

Beyond these, the revision also reclassifies MCP servers as OAuth Resource Servers, requires clients to implement Resource Indicators (RFC 8707), and adds support for resource links in tool call results. These are relevant changes for anyone exposing remote MCP servers with authentication, but the immediate impact on agent code lies in the four changes in the table above.

Batching disappears: anyone sending an array breaks

The 2025-03-26 revision inherited from JSON-RPC 2.0 the ability to pack several requests into a single array, useful for reducing round-trips in agents that call several tools in a row. The 2025-06-18 revision removes this support entirely. A payload like this one, valid under the previous revision, is no longer accepted:

[
  { "jsonrpc": "2.0", "id": 1, "method": "tools/call", "params": { "name": "searchDocs", "arguments": { "query": "pricing" } } },
  { "jsonrpc": "2.0", "id": 2, "method": "resources/read", "params": { "uri": "file:///docs/pricing.md" } }
]

A server already migrated to 2025-06-18 doesn't expect to receive an array at the root of the message; parsing fails or the server responds with an invalid request error. Anyone who built an agent orchestrator that groups calls together to save on latency needs to rewrite that part to fire each call as an independent message, whether in sequence or in parallel across multiple connections. There's no longer a protocol shortcut for this: round-trip savings have to come from somewhere else, such as parallelism at the transport layer.

Structured output changes the CallToolResult contract

Before the revision, a tool could only return content blocks (text, image, resource reference). Agents that needed structured data used to serialize JSON inside a text block and parse it manually on the client side. The 2025-06-18 revision formalizes this: a tool can declare outputSchema and return structuredContent alongside (or instead of) the traditional content.

{
  "content": [{ "type": "text", "text": "{\"temperature\": 22, \"unit\": \"C\"}" }],
  "structuredContent": { "temperature": 22, "unit": "C" }
}

The breaking point here is subtle: if the client's code always did JSON.parse(result.content[0].text) to extract data from a tool, it keeps working as long as the server maintains both fields for compatibility. But nothing forces the tool author to keep that redundancy after migrating to outputSchema; many stop populating content with equivalent text, because structuredContent already covers the case. In that scenario, the old parser receives an empty content array or one in a different format, and it breaks without warning. It's worth checking whether the client already reads structuredContent directly before relying on it.

Elicitation: a message type that an old client doesn't know how to handle

Elicitation is the newest feature on the list and also the one that introduces a type of interaction that simply didn't exist before: during a tool call, the server can send elicitation/create asking the client to collect more information from the user, such as confirming a value or choosing an option. This requires explicit capability negotiation in initialize; a client should only receive this type of request if it has declared support for elicitation.

In short: the risk of breakage here is twofold. If the client doesn't implement a handler for elicitation/create, the tool call hangs waiting for a response that never comes, or the client returns a generic unknown-method error. And if the server fires elicitation at a client that hasn't negotiated the capability, the specification itself treats this as a lifecycle violation, something the changelog's shift from SHOULD to MUST makes stricter to tolerate.

The MCP-Protocol-Version header becomes mandatory over HTTP

For anyone using HTTP transport (streamable HTTP, not stdio), the revision now requires every request sent after initialize to include the MCP-Protocol-Version header with the negotiated value. Before, this was a recommendation; now it's a requirement. Gateways, proxies, and load balancers that sit between the MCP client and server and don't pass this header through correctly now produce rejected responses, even if the JSON-RPC payload itself is correct.

The path I would follow to migrate without breaking anything

Before swapping the SDK in production, the roadmap that makes sense to follow is:

1. Update the official SDK (TypeScript or Python) and read the full changelog linked on the project's GitHub, not just the summary.
2. Search the code for any point that assembles an array of JSON-RPC requests and split it into individual calls.
3. In tool handlers, check whether the parser relies only on content[0].text and add reading of structuredContent when the tool declares outputSchema.
4. Check whether the client declares the elicitation capability in initialize and implement a minimal handler for elicitation/create, even if it's just passing the question through to the agent's interface.
5. On HTTP transport, confirm that MCP-Protocol-Version is sent on every request after initialize, including on proxies along the way.
6. Run the integration suite against a server that already speaks 2025-06-18 before promoting the change to production.

When it's fine to wait

If the integration runs only over stdio, locally, without OAuth and without relying on batching, the immediate impact is smaller: most of the authentication and HTTP header changes simply don't apply. Even so, it's worth checking which revision the server announces during initialize; if it already negotiates 2025-06-18, the structuredContent and elicitation changes are already in play, even without HTTP involved. Postponing the migration is reasonable only as long as both ends agree on the same old revision, something the MCP ecosystem tends to stop supporting over time.