MCP: the June 2025 protocol revision breaks servers built for the previous version

The 2025-06-18 revision of the Model Context Protocol, published on June 18, 2025, removes batch call sending, requires explicit version negotiation, and adds elicitation and structured output. Anyone maintaining an MCP server needs to review their code.

The Model Context Protocol (MCP), the open standard Anthropic uses to connect models to external tools in products like Claude Desktop and which editors like Cursor have also adopted, underwent a formal revision on June 18, 2025. The official MCP changelog (modelcontextprotocol.io) lists the changes relative to the previous revision, from March 26, 2025. More than sixteen months later, the point that most affects anyone who already had a server in production isn't any new feature: it's what the revision removed.

What the 2025-06-18 revision changed, in order of impact

The changelog groups the changes into "major changes" and "other schema changes." The ones that affect compatibility are these:

• Removal of support for JSON-RPC batching (sending multiple calls in a single array).
• Support for structured output in tool results (structured tool output).
• MCP servers are now classified as OAuth Resource Servers, with their own discovery metadata.
• MCP clients are required to implement Resource Indicators (RFC 8707) to prevent a malicious server from capturing access tokens.
• Support for elicitation, allowing the server to request additional information from the user in the middle of an interaction.
• Support for resource links in tool call results.
• Mandatory MCP-Protocol-Version header in HTTP requests following the initial negotiation.
• Change from "SHOULD" to "MUST" in the protocol's lifecycle operations.

What really breaks: the end of JSON-RPC batching

Before the revision, a client could pack multiple JSON-RPC calls into a single array and send them all at once, saving round-trips. The 2025-06-18 revision removed this support (PR #416 in the changelog). A server or client that still builds this array of requests simply won't get a valid response from the other side, because message validation in the new version expects a single object, not a list.

In practice, if your local MCP server (for example, one you connected to Claude Desktop via claude_desktop_config.json) was written with a lib or SDK that still builds batches, the fix is to replace each batched call with sequential calls, one JSON-RPC request at a time. There's no backward-compatibility flag: anyone who migrates the server to an updated version of the official MCP SDK gets this behavior automatically, without needing to rewrite the tool's business logic.

Version negotiation: the header that became mandatory

Protocol version negotiation already existed in previous revisions, done in the connection's initialize message. What changes now is that, when the transport is HTTP, the client is required to resend the negotiated version in every subsequent request, via the MCP-Protocol-Version header:

POST /mcp HTTP/1.1
Host: localhost:3001
MCP-Protocol-Version: 2025-06-18
Content-Type: application/json

{"jsonrpc":"2.0","method":"tools/call","id":7,"params":{...}}

A server strict about the new revision can (and should, given the change from SHOULD to MUST in the changelog) reject HTTP requests without this header, even if the initial initialize went fine. This breaks integrations that stored the negotiated version somewhere but never resent it on every subsequent call, a common pattern in prototypes built before June 2025.

Elicitation: the server can pause and ask

Editor's note: the method names, fields, and code examples in this and the next section (elicitation and structured output) generically illustrate the use of the features announced in the official changelog, but the source doesn't specify these exact names, nor were they run in a real environment. Validate before using in production.

Before the revision, an MCP server only had two paths when it was missing a piece of data to complete a task: guess or fail. The elicitation feature (PR #382) provides a third path: the server sends a request to the client asking the user to fill in a value, described as a JSON schema, and tool execution only continues after the response arrives.

In a typical server written with an SDK that implements this feature, this can show up as a call the tool's handler makes back to the client before returning its final result, in a format close to this (illustrative):

const resposta = await server.elicitInput({
  message: "Qual repositório devo usar para o deploy?",
  requestedSchema: {
    type: "object",
    properties: {
      repositorio: { type: "string" }
    },
    required: ["repositorio"]
  }
});

The point to watch for anyone migrating: clients that still speak the 2025-03-26 revision don't know how to respond to this request, because the method didn't exist. The server needs to check the version negotiated in initialize before trying to use elicitation, and fall back to an alternative behavior (asking for the data as a parameter of the tool itself, for example) when the client is older.

Structured output: no longer returning only text

The other feature that changes how an MCP tool is written is support for structured output (PR #371). Up through the previous revision, the result of a tool call was, in practice, free text inside the content field. Now the tool definition can declare an output schema, and the response can carry typed data, instead of the client having to parse text to extract a value (the changelog doesn't detail the exact field names used in this implementation).

This changes the contract for whoever consumes the tool on the other end: an agent that previously had to interpret a sentence like "the deploy completed successfully at commit abc123" can now read something like { status: "success", commit: "abc123" } directly. Servers migrated without declaring this output schema keep working, they just don't gain this benefit; no tool is required to adopt structured output.

What changes for those running locally, in Claude Desktop or Cursor

The protocol version is negotiated per connection: client and server exchange the version each one speaks in the initialize message, and the server responds with the version it will use from then on.

In day-to-day practice with Claude Desktop or Cursor, the behavior depends on which revision the built-in client of each app already negotiates, information that changes with every update to these programs and that the protocol's official changelog doesn't document. The more predictable risk is on the other side: third-party MCP servers, installed via npx or pip, that were written against the previous revision and never updated. One of these servers may accept the connection (the initialize negotiation doesn't fail, it just records the version), but break on the first call that depends on one of the new features or that still tries to use batching.

For anyone maintaining their own MCP server, the migration checklist is short:

1. Update the official SDK (TypeScript or Python) to the version that implements the 2025-06-18 revision.
2. Search the code for any place that builds arrays of JSON-RPC calls and replace them with sequential calls.
3. If the transport is HTTP, confirm that the client resends MCP-Protocol-Version on every request, not just in the handshake.
4. Evaluate whether any tool would benefit from elicitation or structured output, with a fallback path for clients that still negotiate the older version.
5. If the server exposes authentication via OAuth, review the classification as a Resource Server and the validation of Resource Indicators (RFC 8707) before accepting tokens.

The official changelog also lists smaller changes, such as the title field for friendly names in interfaces (separating it from the programmatic name identifier) and the context field in completion requests, which allows reusing already-resolved variables. Neither one breaks compatibility, but they're worth reviewing in servers that display tool names to the end user.

Source 1: Official Model Context Protocol Specification, Changelog for the 2025-06-18 revision (https://modelcontextprotocol.io/specification/2025-06-18/changelog)

Key Changes - Model Context Protocol

Documentation Index Fetch the complete documentation index at: /llms.txt Use this file to discover all available pages before exploring further. Skip to main content This document lists changes made to the Model Context Protocol (MCP) specification since the previous revision, 2025-03-26 .

​ Major changes

Remove support for JSON-RPC batching (PR #416 )

Add support for structured tool output (PR #371 )

Classify MCP servers as OAuth Resource Servers , adding protected resource metadata to discover the corresponding Authorization server. (PR #338 )

Require MCP clients to implement Resource Indicators as described in RFC 8707 to prevent malicious servers from obtaining access tokens. (PR #734 )

Clarify security considerations and best practices in the authorization spec and in a new security best practices page .

Add support for elicitation , enabling servers to request additional information from users during interactions. (PR #382 )

Add support for resource links in tool call results. (PR #603 )

Require negotiated protocol version to be specified via MCP-Protocol-Version header in subsequent requests when using HTTP (PR #548 ).

Change SHOULD to MUST in Lifecycle Operation

​ Other schema changes

Add _meta field to additional interface types (PR #710 ), and specify proper usage .

Add context field to CompletionRequest , providing for completion requests to include previously-resolved variables (PR #598 ).

Add title field for human-friendly display names, so that name can be used as a programmatic identifier (PR #663 )

​ Full changelog For a complete list of all changes that have been made since the last protocol revision, see GitHub . Was this page helpful? Yes No Assistant Responses are generated using AI and may contain mistakes.