MCP 2025-06-18: What Breaks in Agents Already Plugged via Model Context Protocol

The 2025-06-18 revision of the Model Context Protocol is the first since 2025-03-26 to touch things that are already running in production. It's not a list of cosmetic features: there's resource removal, a change from SHOULD to MUST, and a new authorization model that forces a rethink of how the client obtains tokens. According to the official changelog, there are three fronts that really matter for those who built MCP servers and clients: authorization (OAuth + resource indicators), elicitation, and structured tool output. This text separates what's a breaking change from what's an optional addition.

What Disappears: JSON-RPC Batching

The most direct contract-breaking change is the removal of JSON-RPC batching support (PR #416). In the previous spec, a client could send an array of requests in a single message and receive an array of responses. That's over.

If your server or client parses expecting an array at the root of the message, it now needs to handle each request individually. In practice, those who used the official SDK without workarounds probably won't feel anything, since batching was rarely used. The risk lies in homegrown implementations that optimized round-trips by grouping calls: those stop working against a peer that has already adopted 2025-06-18.

The migration recommendation is trivial to describe and tedious to audit: search your code for where you build or unpack arrays of JSON-RPC messages and replace it with single-message sending. There's no negotiable fallback here, the feature simply no longer exists in the spec.

Authorization: MCP Server Is Now an OAuth Resource Server

This is the most structural change, and the one that requires the most work. The spec now classifies MCP servers as OAuth Resource Servers (PR #338) and requires protected resource metadata so the client can discover the corresponding Authorization Server. Add to that PR #734, which requires clients to implement Resource Indicators per RFC 8707.

The problem RFC 8707 solves is concrete: without resource indicators, a malicious MCP server could receive an access token and reuse it against another API for which the token is also valid. The resource indicator ties the token to the intended resource. When the client requests the token, it includes the resource parameter pointing to the target MCP server:

POST /token
grant_type=authorization_code
&code=...
&resource=https://mcp.exemplo.com

The Authorization Server then issues a token with audience restricted to that resource. If the server tries to reuse that token elsewhere, audience validation fails.

What breaks here:

• Servers that handled their own built-in authorization need to separate the roles: whoever validates the token (Resource Server) is not whoever issues it (Authorization Server). If you coupled the two, there's refactoring ahead.
• Clients that requested tokens without resource now end up, in the best case, with tokens the server rejects, and in the worst case, still work but with the security hole the spec now considers unacceptable.
• It's necessary to expose the protected resource metadata endpoint so the client can automatically discover the Authorization Server. Without it, the client doesn't know where to send the OAuth flow.

The spec also clarifies security considerations in a new best practices page, a sign that the committee is treating MCP as a serious attack surface, no longer as a lab prototype. For those building in Brazil and plugging agents into internal company APIs, this is the part the security team will look at before approving any deployment.

Elicitation: The Server Can Ask the User for Data Mid-Conversation

Elicitation support (PR #382) is an addition, not a breaking change, but it changes how agent flows are designed. Previously, if a server needed information that wasn't included in the call, it could only fail or guess. Now it can request additional information from the user during the interaction.

The obvious use case: a booking tool that notices the date is missing and, instead of returning an error, triggers an elicitation asking the user for the date through the client. The client is the one that renders this request, so the experience depends on the client implementing the feature. Old servers ignore it; new servers gain a path to multi-step dialogs without inventing a protocol on top.

The security concern is evident, and the spec itself signals caution: elicitation is a vector for a malicious server to ask for sensitive data ("give me your API key") while pretending to be a legitimate part of the flow. The client implementation needs to make clear that the request comes from the server, not the application.

Structured Tool Output and Resource Links

The spec adds structured tool output (PR #371). Until now, a tool's return was essentially text or content blocks, and it was up to the model to interpret it. With structured output, the tool can return typed data that the client consumes predictably, without relying on the LLM to parse free text. For those building pipelines where one tool's result feeds another, this reduces the chance of parsing errors along the way.

Complementing this, PR #603 adds resource links in tool call results: a tool can return a reference to a resource instead of dumping the entire content into the response, useful for large files or data that the client fetches on demand.

Smaller Changes That Can Still Bite

Two small changes have the potential to break things quietly:

• The MCP-Protocol-Version header is now required in subsequent HTTP requests after version negotiation (PR #548). A client that doesn't send the header may be rejected by a strict server.
• SHOULD became MUST in Lifecycle Operation. What was a recommendation is now a requirement. Implementations that took shortcuts in the connection lifecycle may no longer be compliant.

On the side of risk-free additions: a _meta field in more interface types (PR #710), a context field in CompletionRequest to include already-resolved variables (PR #598), and a title field for a friendly display name, freeing up name as a programmatic identifier (PR #663). This last one is good news for client UX, which previously had to choose between a readable name and a stable one.

What to Do About It

For those who already have MCP in production, the safest migration roadmap is to prioritize by impact: first audit authorization, since that's where the security hole and the heaviest refactoring live; then remove any dependency on batching; then add the required version header and review the lifecycle. Elicitation, structured output, and resource links come in as incremental improvements, adopted as the client supports them.

What remains open is the pace of adoption by SDKs and major clients (Claude Desktop, IDEs with MCP support). A spec only truly breaks when both sides update, and as long as there's an old client talking to a new server, version negotiation becomes the battlefield. It's worth following the full changelog on GitHub before assuming your stack is compliant.