MCP 2025-06-18: elicitation and the new authorization rules can break old agents without warning

The Model Context Protocol, the standard that connects AI agents to tools and external data sources, underwent a specification revision on June 18, 2025. It replaced the previous revision, from March 26, 2025, and brought changes that are not cosmetic: they rewrote how server and client negotiate version, how authorization works, and how a server can request extra information in the middle of a task. The official MCP changelog (modelcontextprotocol.io) lists the changes, but it doesn't dramatize the size of the impact for anyone who already has an agent running.

Almost a year and a half later, a good part of the teams that stood up MCP servers in early 2025 are still on the old client. The problem is that these changes don't break with an explicit error: they break by omission. A field the client doesn't recognize is ignored, not rejected. A header missing from the HTTP request can lead the server to interpret the wrong protocol version. The agent keeps running, just with less capability than the server offers, or worse, with an open security flaw.

Elicitation: the server can now stop and ask

The most visible change in the revision is support for elicitation (PR #382 in the spec repository), which gives the MCP server the ability to ask the user for additional information in the middle of an interaction, instead of failing or assuming a default value. Before, if a tool needed data that wasn't included in the call, the common practice was for the server to return an error or for the client to simply not support the case.

With elicitation, the server sends an elicitation/create message with a schema of what it needs, and the client decides how to collect this from the user (form, prompt, dialog). The response carries an action, which indicates whether the user accepted, declined, or canceled the request:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "elicitation/create",
  "params": {
    "message": "Preciso do CEP para calcular o frete",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "cep": { "type": "string", "title": "CEP" }
      },
      "required": ["cep"]
    }
  }
}

The client's response follows the same id and returns an action with the collected content:

{
  "jsonrpc": "2.0",
  "id": 7,
  "result": {
    "action": "accept",
    "content": { "cep": "01310-100" }
  }
}

The practical risk: a client that doesn't implement this method doesn't know what to do with the elicitation/create message. Depending on how the client handles unknown methods, the tool can hang waiting for a response that never arrives, or the server interprets silence as refusal and proceeds with incomplete data. Neither case shows up as an error in the log the way a dev expects.

Authorization: the MCP server became a Resource Server

The second structural change is about security. The revision began classifying MCP servers as OAuth Resource Servers (PR #338), requiring them to expose protected resource metadata pointing to the corresponding Authorization Server. This formalizes something that used to be implicit: the MCP server doesn't authenticate anyone on its own, it delegates to an OAuth provider and only validates the token it receives.

Along with that came a strict requirement for anyone implementing a client: MCP clients need to implement Resource Indicators as defined in RFC 8707 (PR #734). This RFC defines how the client indicates, in the token request, which specific resource that token is valid for. Without it, the specification makes the reason clear: a malicious server could obtain a token issued for another resource and reuse it improperly.

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

MCP specification changelog, 2025-06-18 revision

This isn't an API tweak, it's a fix to the threat model. A client that still doesn't pass the Resource Indicator in the authorization flow is potentially vulnerable to the scenario the change exists to close, even if the integration keeps working day-to-day with no visible symptom.

JSON-RPC batching is out of the protocol

The revision removed support for JSON-RPC batching (PR #416), that is, the possibility of sending multiple calls in a single array of requests. Clients or servers that still build batched payloads stop having those messages recognized by the other end. There's no soft deprecation warning here: the capability simply no longer exists in the current spec, so any code that depends on it needs to be rewritten for individual calls.

The header the spec now requires

Another change that tends to go unnoticed: when using HTTP transport, the negotiated protocol version now needs to be specified via MCP-Protocol-Version in subsequent requests (PR #548). Before, version negotiation happened once and remained implicit in the session. Now every HTTP call after the handshake carries this header.

A client written before this change simply doesn't populate the header, because it never had to. The changelog doesn't detail the server's exact behavior in the absence of the header, which by itself is a reason to test: behavior can vary between server implementations, and assuming it "will work the same way" is gambling without knowing the rule.

Other schema changes that affect integration

The list of smaller changes also has a cumulative effect:

• Structured tool output (PR #371): tool responses can come with structured output, not just free text, which changes how the client needs to parse the result.
• Resource links in tool results (PR #603): a tool can return a link to a resource instead of the entire content, requiring the client to know how to fetch that resource afterward.
• title field (PR #663): separates the display name (title) from the programmatic identifier (name), so code that used name to show text to the user may need to migrate to title.
• _meta field (PR #710): added to more interface types, with its own usage rules that older clients ignore by default.
• A change from SHOULD to MUST in a connection lifecycle operation, making mandatory something that used to be a recommendation.

None of these changes break things on its own, but together they form a compatibility surface quite different from the March revision.

The checklist I'd follow to test this today

In an agent with an MCP server already in production, the most direct way to validate exposure to these changes would be:

1. Check the protocol version the client announces at handshake and compare it with 2025-06-18 in the documentation of the SDK used.
2. Simulate a tool call that triggers elicitation/create and observe whether the client handles the message or silently ignores it.
3. Review the authorization flow: does the client send the RFC 8707 Resource Indicator parameter in the token request, or does it still assume a generic token?
4. Search the code for any batched JSON-RPC array being sent and replace it with individual calls.
5. Check whether HTTP requests after the handshake carry the MCP-Protocol-Version header.

None of these tests requires rewriting the agent from scratch. But skipping this check means discovering the problem through a user complaint, not through an error log.

When this still isn't urgent

Agents that only consume internal MCP servers, controlled by the same team, with updated SDKs on both sides, have already absorbed most of these changes without manual effort, because official SDKs tend to implement the current revision. The risk is concentrated in integrations with third-party MCP servers, homegrown client implementations, or code written directly against the March 2025 revision and never revisited since. In these cases, the gap between what the server expects and what the client understands is where the agent fails without warning.