What’s New in MCP 2025-06-18: Human-in-the-Loop, OAuth, Structured Content, and Evolving API Paradigms
The latest release of the Model Context Protocol (MCP) — dated 2025-06-18 — introduces powerful enhancements advancing MCP as the universal protocol for AI-native APIs.
Key highlights include:
- Human-in-the-loop support via Elicitation flows
- Full OAuth schema definitions for secure, user-authorized APIs
- Structured Content and Output Schemas — typed, validated results with flexible schema philosophy and MIME type clarity
In this post, we’ll explore these features, why they matter, and close with an observation about how MCP reflects broader shifts in API design in an AI-first world.
1. Human-in-the-Loop Support — Elicitation Flow
A major addition is explicit support for multi-turn, human-in-the-loop interactions through Elicitation Requests.
Rather than a single, one-shot call, MCP now supports a conversational sequence where the tool and client collaborate to clarify and collect missing or ambiguous information.
How it works:
- Client sends a tool request
- Tool (via LLM) returns an
elicitationRequest
— asking for missing or ambiguous inputs - Client prompts the user and gathers additional inputs
- Client sends a
continueElicitation
request with the user-provided info - Tool proceeds with the new info and returns the final result
This workflow enables real-world applications such as:
- Interactive form filling
- Clarifying user intent
- Collecting incremental data
- Confirming ambiguous or partial inputs
For more details, see the Elicitation specification.
2. OAuth Schema Enhancements
Previously, MCP supported OAuth only through simple flags and minimal metadata — leaving full OAuth flow handling to the client implementation.
With this release, MCP now supports complete OAuth 2.0 schema definitions, allowing tools to specify:
authorizationUrl
tokenUrl
clientId
- Required
scopes
Additionally, tools can now explicitly declare themselves as OAuth resource servers.
To enhance security, 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.
These changes enable:
- Fully integrated, secure, user-authorized access
- Improved interoperability with enterprise OAuth providers
- Better protection against token misuse
3. Structured Content & Output Schemas
a) Output Schema — Stronger, Yet Flexible Contracts
Tools can declare an outputSchema
using JSON Schema, enabling precise, typed outputs that clients can validate and parse reliably.
For example, a Network Device Status Retriever tool might define this output schema:
{ "type": "object", "properties": { "deviceId": { "type": "string", "description": "Unique device identifier" }, "status": { "type": "string", "description": "Device status (e.g., up, down, maintenance)" }, "uptimeSeconds": { "type": "integer", "description": "Device uptime in seconds" }, "lastChecked": { "type": "string", "format": "date-time", "description": "Timestamp of last status check" } }, "required": ["deviceId", "status", "uptimeSeconds"] }
A valid response might look like:
{ "structuredContent": { "deviceId": "SW-12345", "status": "up", "uptimeSeconds": 86400, "lastChecked": "2025-06-20T14:23:00Z" }, "content": [ { "type": "text", "text": "{\"deviceId\": \"SW-12345\", \"status\": \"up\", \"uptimeSeconds\": 86400, \"lastChecked\": \"2025-06-20T14:23:00Z\"}" } ] }
This example fits naturally into networking operations, showing how MCP structured content can enhance AI-assisted network monitoring and management.
b) MIME Type Support
Content blocks can specify MIME types with data, enabling clients to correctly render images, audio, files, etc.
Example:
{ "type": "image", "data": "base64-encoded-data", "mimeType": "image/png" }
c) Soft Schema Contracts — Pragmatism with an Eye on the Future
MCP embraces a pragmatic approach to schema adherence, recognizing the probabilistic nature of AI-generated outputs and the need for backward compatibility.
“Tools SHOULD provide structured results conforming to the output schema, and clients SHOULD validate them.
However, flexibility is key — unstructured fallback content remains important to handle variations gracefully.”
This soft contract approach means:
- Tools are encouraged to produce schema-compliant outputs but are not strictly required to do so every time.
- Clients should validate and parse structured data when possible but also handle imperfect or partial results.
- This approach helps developers build robust integrations today, despite inherent AI uncertainties.
Looking forward, as AI models improve and standards mature, MCP’s schema enforcement may evolve towards stricter validation and guarantees, better supporting mission-critical and enterprise scenarios.
For now, MCP balances innovation and reliability — providing structure without sacrificing flexibility.
Conclusion: REST → MCP, SQL → NoSQL — An Evolutionary Analogy?
Watching MCP’s evolution reminds me of broader trends in API and data design.
Traditional REST APIs enforced rigid, versioned schemas — much like how SQL databases require strict schemas.
NoSQL databases introduced schema flexibility, enabling rapid iteration and tolerance for unstructured data.
Similarly, MCP is moving towards:
- Flexible, evolving schema guidance rather than brittle contracts
- Coexistence of structured and unstructured content
- Designed tolerance for AI’s probabilistic, sometimes imperfect outputs
I don’t claim this is a perfect analogy, but it’s a useful lens to reflect on how APIs must evolve in an AI-first world.
Is MCP simply REST for AI? Or something fundamentally different — shaped by human-in-the-loop collaboration and LLM behavior?
I’d love to hear your thoughts and experiences.
Ready to dive in?
Explore the full spec and changelog here:
#MCP #ModelContextProtocol #AIAPIs #Elicitation #OAuth #StructuredContent #SoftSchemas #APIEvolution #NoSQL #REST #AIIntegration
Good Blog post Neelesh, MCP is much more than what REST/ HTTP is for Web2.0 since MCP prefers Composability Over Integration (which HTTP does mostly)
1) REST requires pre-built integrations
2) MCP enables runtime composition of Agentic capabilities