Introducing Gram by Speakeasy. Gram is everything you
need to power integrations for Agents and LLMs. Easily create, curate and host
MCP servers for internal and external use. Build custom tools and remix
toolsets across 1p and 3p APIs. Get on the
waitlist today!
MCP release notes
Each release of the Model Context Protocol (MCP) introduces changes to how LLM applications integrate external tools and context. These updates can improve developer experience, interoperability, and safety, but they may also introduce breaking changes or require adjustments in your implementation.
Note
This page is not an official MCP release notes page. It exists to help
developers understand what changed, why it matters, and how to adopt the
latest MCP revisions. For the full changelog, refer to the official
changelog .
MCP version history
This section summarizes the significant differences between MCP versions. The following table summarizes major changes between MCP versions.
The 2025-06-18 MCP release represents a significant refinement of the Model Context Protocol, introducing structured tool outputs, enhanced OAuth security, and server-initiated user interactions. However, it also removes JSON-RPC batching from the previous version, simplifying protocol implementation while adding new capabilities for better security and data handling.
Key highlights include:
Removal of JSON-RPC batching: The batching feature introduced in 2025-03-26 has been removed, simplifying the protocol implementation
Structured tool output: Tools can now return structured, predictable data formats for better integration
Enhanced OAuth security: MCP servers are now classified as OAuth Resource Servers with additional security requirements
Elicitation capability: Servers can now request additional information from users during interactions
Resource links: Tool results can now reference MCP resources, creating better integration between tools and data
You may choose to remain on the 2025-03-26 version if you need:
JSON-RPC batching support: If your implementation relies on batching multiple requests
Simpler OAuth implementation: The earlier version has less stringent OAuth requirements
What’s new in MCP 2025-06-18?
MCP 2025-06-18 introduces structured tool outputs, removes JSON-RPC batching, enhances OAuth security with Resource Server requirements, and adds elicitation for server-initiated user requests. Here’s a detailed breakdown of the major updates:
Removal of JSON-RPC Batching
One of the most significant changes is the removal of JSON-RPC batching support, which was introduced in 2025-03-26. This decision simplifies the protocol implementation and reduces complexity for both clients and servers. The maintainers mentioned that there was ‘no compelling use case for batching’ , but not all users agreed.
Note
If you were using batching in your 2025-03-26 implementation, you’ll need to
refactor to send individual requests instead of batched ones.
Structured Tool Output
The new structured tool output capability allows tools to return data in predictable, structured formats rather than just plain text responses.
What you need to change: Update your tool definitions to specify Tool.outputSchema and return CallToolResult.structuredContent in your tool implementations.
Enhanced OAuth Security
MCP servers are now classified as OAuth Resource Servers , introducing two MUST requirements for both servers and clients:
Resource Server Discovery: Servers MUST provide metadata to help clients discover the corresponding Authorization Server
Resource Indicators: Clients MUST implement RFC 8707 Resource Indicators to prevent malicious servers from obtaining inappropriate access tokens
What you need to change: Update your server to expose authorization metadata and modify your client to include resource indicators in token requests.
Security Best Practices
The 2025-06-18 release introduces comprehensive security best practices documentation. This covers token validation, resource isolation, and threat mitigation to help prevent common security vulnerabilities in MCP implementations.
MCP Elicitation Support
The new elicitation capability enables servers to request additional information from users during interactions.
Elicitation allows servers to pause tool execution and ask users for specific information using structured JSON schemas. For example, a booking tool might request travel dates, or a file processor might ask for output format preferences.
What you need to change: Enable the elicitation capability and use context.elicit() to request user input when your tools need additional information.
Key features:
Structured requests: Use JSON schemas to define exactly what information you need
User control: Users can accept, reject, or cancel elicitation requests
Simple schemas: Only primitive types (string, number, boolean) are supported for easier client implementation
Security: Servers must not request sensitive information through elicitation
Resource Links in Tool Results
Tools can now return resource links that reference MCP resources, creating better integration between tool outputs and available data sources.
MCP Protocol Version Headers
HTTP requests now require the MCP-Protocol-Version header to enable version negotiation . Clients are responsible for setting this header in all HTTP requests after the initial version negotiation is completed during the handshake.
What you need to change: Update your HTTP client to include the MCP-Protocol-Version header in all requests after connecting.
Title Fields for Better UX
The title field has been added to tools, resources, and prompts to provide human-friendly display names while keeping name as the programmatic identifier. This improves how MCP items appear in client interfaces.
What you need to change: Add title fields to your tools, resources, and prompts for better user experience in clients like VS Code Copilot Chat.
In practice, this means users see “Search repositories” instead of “search_repositories” in their IDE:
Meta Fields: Added _meta field to additional interface types for better extensibility
Completion Context: Added context field to CompletionRequest for LLM-based autocompletion support
MCP 2025-03-26 vs MCP 2024-11-05
The 2025-03-26 release of the Model Context Protocol introduces a more mature and standardized approach to authorization, transport, and tool metadata. It brings significant improvements in security, flexibility, and client compatibility, but it also includes breaking changes that may require updates in existing implementations if you are moving from the 2024-11-05 version.
Key highlights include:
Structured OAuth-style authorization: Authorization is now defined explicitly using a consistent schema, making supporting various auth models and token types easier.
Streamable HTTP transport: The previous HTTP with SSE model has been replaced with a more robust, proxy-friendly HTTP streaming format.
JSON-RPC batching: Developers can now bundle multiple requests in a single call, improving efficiency in complex workflows (note: this was later removed in 2025-06-18).
Tool annotations: Tools can now describe their behavior (for example, read-only, destructive), allowing for safer and more user-aware execution.
You may choose to remain on the 2024-11-05 version if you need:
SSE-based transport compatibility: If you’re invested in SSE infrastructure and can’t yet support chunked HTTP streaming.
Minimal tooling overhead: The earlier version uses simpler schemas and fewer requirements, which may suit prototypes or early integrations.
What’s new in 2025-03-26?
MCP 2025-03-26 introduces the following changes: Authorization framework inspired by OAuth 2.1. and Streamable HTTP replacing HTTP with SSE.
Authorization
The 2024-11-05 version of MCP doesn’t include a standardized authorization model. As a result, developers must implement their own authorization schemes, which leads to inconsistent behaviors and security risks, as tokens are passed directly in the input parameters.
The new model supports role-based access control, dynamic client registration, and standard PKCE-based flows. It also allows for better error handling and smoother integration with existing identity providers.
For example, you might define a tool to make bank transfers as follows:
In MCP 2024-11-05, long-lived connections are handled using server-sent events (SSE). SSE supports server-to-client streaming, but client-to-server communication relies on HTTP POST requests. This means managing two different layers of communication, leading to avoidable complexity in coding and implementation.
With version 2025-03-26, MCP introduces a new transport layer that uses chunked HTTP streaming, replacing SSE. Let’s compare the implementation of a streamable HTTP server to the previous SSE-based server.
Here is an example of a simple server using SSE:
Here is the equivalent server using Streamable HTTP:
Here are some reasons you should consider switching to Streamable HTTP:
Proxy and load balancer compatibility: SSE often breaks under proxies due to connection timeouts and buffering limits. For example, AWS ALB and Cloudflare frequently terminate SSE connections, while Streamable HTTP uses standard chunked encoding and works reliably.
Full-duplex communication: SSE only supports server-to-client messages, requiring separate POSTs for client input. Streamable HTTP enables bidirectional streaming over one connection, simplifying cases like real-time tool execution or chat interfaces.
Other notable changes
Apart from the improvements to authorization and HTTP streaming transport, MCP 2025-03-26 introduces these changes:
Tool calls can now be batched: Clients may send multiple tool invocations in a single JSON-RPC request. Servers that assume one call per request must handle arrays and concurrent execution. (Note: This feature was removed in 2025-06-18)
Tool behavior must now be declared explicitly: Tools can define attributes like readOnly or destructive, which clients are expected to respect. This may impact how tools are displayed or gated in UIs.
Progress updates are now more descriptive: The ProgressNotification object includes an optional message field. Clients that display progress may want to surface these descriptions to users.
Audio is a supported content type: Servers and clients must now handle audio in addition to text and image.
Tools can advertise completion support: Servers can declare that a tool supports input autocompletion. You may need to update your UI to initiate and render completion suggestions accordingly.