The MCP spec version 2025-06-18 shipped on June 18, 2025. Most of the discussion focused on the OAuth changes because those are the ones that break things. But the most conceptually interesting addition is quieter: elicitation - a way for a server to stop mid-tool-call, ask the user a structured question, and continue only after it gets an answer.
That is a small change on paper. It is a larger one in practice.
What elicitation actually does
The protocol now provides a standardized way for servers to request additional information from users through the client during interactions. The client keeps control over user interactions and data sharing while the server gathers information dynamically. Servers request structured data from users with JSON schemas to validate responses.
The key word is nested.
Elicitation allows servers to implement interactive workflows by enabling user input requests to occur nested inside other MCP server features.
A booking tool can pause and ask for travel dates. A file processor can ask for an output format. The server sends an elicitation/create request with a message and a JSON schema; the client surfaces that to the user; the server resumes with a validated response.
Before this, the only way to handle missing context mid-run was to either fail loudly, make an assumption and proceed, or return a result that tells the caller to try again with more arguments. None of those are satisfying. Elicitation gives servers a sanctioned channel for the thing developers were already doing via workarounds.
Elicitation is not a chatbot turn. It is a typed interrupt with a schema on the response.
What changed on the auth side (and why it matters more for production)
The other major shift in 2025-06-18 is less novel but harder to ignore if you are running real servers.
MCP servers are now officially classified as OAuth Resource Servers. This might seem like a small semantic change, but it has significant implications for security and discovery. By defining MCP servers this way, the protocol now includes a mechanism to add protected resource metadata.
Practically: MCP clients are now required to implement Resource Indicators as defined in RFC 8707. This prevents malicious servers from misusing access tokens intended for other resources. If you have ever thought about what happens when an agent connects to a server you do not fully control, that threat model - a rogue server capturing a token scoped to a different service - is exactly what this closes.
The June 2025 spec formalized MCP servers as OAuth Resource Servers and mandated Resource Indicators (RFC 8707). This prevents a token issued for one server from being reused to access a different server.
JSON-RPC batching support has been removed. This is not backward compatible - any MCP client that supports 2025-03-26 might not work with an MCP server that only supports 2025-06-18. Check your client version before cutting over.
The structured tool output piece
The third addition is structured tool output - tools can now return data in predictable, structured formats rather than just plain text responses.
Many agent frameworks already supported structured output for tools declared within the agent itself - now that capability is officially part of the MCP spec as well. This is the least dramatic item on the changelog. It matters for downstream pipelines that need to parse tool results reliably without regex hacks, but it is incremental, not new.
Also worth knowing:
a new resource_link type lets tools point to URIs instead of inlining everything. The client can then subscribe to or fetch that URI as needed.
For large responses - think a code diff or a document - this avoids bloating the context window with content the model may not need.
Where the hype outruns the spec
Elicitation is being described in some corners as "human-in-the-loop, finally solved." That is too strong.
First, elicitation is newly introduced in this version of the MCP specification and its design may evolve in future protocol versions. It is not settled. Second, elicitation should not be used to extract sensitive or personally identifiable information from users. Developers should follow best practices to make sure elicitation prompts stay safe and appropriate, especially as MCP matures. The spec is clear about this. Third, elicitation only works if the client implements it - a client that silently drops elicitation requests will stall the server with no obvious error.
What elicitation actually solves is a narrow, real problem: collecting a small amount of structured input from a user at the moment a tool needs it, without forcing the entire conversation back to a prompt-and-response loop. A teammate like Beagle, wired into Slack, would use this to ask a clarifying question inline - "which channel do you want this posted to?" - rather than surfacing a generic failure.
What to do with this now
If you maintain an MCP server, the practical checklist from this release is short:
- Audit your OAuth flow against the Resource Server classification and add the protected resource metadata endpoint.
- Check whether your client stack implements Resource Indicators (RFC 8707) before upgrading to 2025-06-18.
- If you have tools that currently return plain text and downstream code parses that text, add an output schema.
- Prototype elicitation on one tool where you currently make assumptions. The spec is experimental; the pattern is worth learning early.
The 2025-06-18 release is not a headline rewrite of the protocol. It is the spec catching up to patterns developers were already implementing ad hoc, and tightening the security model in ways that matter for anything beyond a local demo. The elicitation primitive is the genuinely new idea. Watch how it matures before building deep workflows on top of it.