MCP Specification Changelog: Version History and Evolution

The MCP specification has evolved through several versions since its initial release on November 5, 2024, with each iteration adding capabilities, improving security, and refining the protocol based on real-world adoption feedback. The most significant change was the introduction of Streamable HTTP transport in the 2025-03-26 specification, which replaced the original HTTP+SSE transport with a more flexible, production-ready mechanism for remote server communication. This changelog covers every specification version, the key changes in each, breaking changes developers must address, and a look at what is coming next.

Understanding the specification history is essential if you are building or maintaining MCP servers. For the foundational concepts behind the protocol, see our complete MCP guide.

Version Timeline Overview

Spec Version	Release Date	Highlights
2024-11-05	November 5, 2024	Initial public release of MCP
2024-11-25	November 25, 2024	Public announcement and ecosystem launch
2025-03-26	March 26, 2025	Streamable HTTP transport, OAuth 2.1, audio content
2025-06-18	June 18, 2025	Tool annotations, elicitation, structured output
2025-11-05 (draft)	Late 2025	JSON-RPC batching, resource links, event streams

Each specification version uses a date-based identifier (YYYY-MM-DD) rather than semantic versioning. The version is exchanged during the initialization handshake between client and server, allowing both sides to negotiate which features are available.

2024-11-05: The Initial Release

The inaugural MCP specification established the core protocol that the ecosystem is built on. This version defined:

Core Architecture

Host-Client-Server model: The three-role architecture where hosts (AI applications) contain clients that connect to servers
JSON-RPC 2.0 messaging: All communication uses the JSON-RPC 2.0 wire format for requests, responses, and notifications
Capability negotiation: The initialization handshake where client and server declare their supported features

Transport Layer

stdio transport: For local servers running as child processes. The client spawns the server and communicates over standard input/output
HTTP with SSE transport: For remote servers. Used HTTP POST for client-to-server messages and Server-Sent Events for server-to-client messages

Three Primitives

The specification defined three core primitives that servers can expose:

Primitive	Control	Description
Tools	Model-controlled	Functions the AI model can invoke (e.g., "search_files", "run_query")
Resources	Application-controlled	Data sources the host application can read (e.g., file contents, database records)
Prompts	User-controlled	Prompt templates the user can select and parameterize

Additional Features

Sampling: Allows servers to request LLM completions through the client (server-initiated AI inference)
Roots: Mechanism for clients to inform servers about relevant filesystem or URI boundaries
Progress tracking: Notifications for long-running operations
Logging: Structured log messages from server to client
Pagination: Cursor-based pagination for list operations

2025-03-26: Streamable HTTP and OAuth 2.1

This was the most significant specification update, driven by the need to support production-grade remote server deployments. The community had identified several limitations in the original HTTP+SSE transport that made it difficult to deploy behind load balancers, API gateways, and in serverless environments.

Streamable HTTP Transport (Replacing HTTP+SSE)

The biggest change was the introduction of Streamable HTTP as a replacement for the original HTTP+SSE transport.

What changed:

Aspect	Old HTTP+SSE	New Streamable HTTP
Client-to-server	HTTP POST to one endpoint	HTTP POST to one endpoint
Server-to-client	Dedicated SSE endpoint (GET)	SSE stream on the POST response, or standalone SSE
Session management	Implicit via SSE connection	Explicit via Mcp-Session-Id header
Connection requirement	Client had to maintain persistent SSE connection	No persistent connection required
Serverless compatible	Difficult	Yes
Load balancer friendly	Problematic with sticky sessions	Standard HTTP routing

Why it mattered: The original HTTP+SSE transport required clients to open a persistent SSE connection before sending any requests. This was problematic for serverless deployments (where processes are short-lived), for load balancers (which struggled with persistent connections), and for environments with strict timeout policies. Streamable HTTP makes every interaction a standard HTTP request-response, with optional SSE streaming on the response body when the server needs to send multiple messages.

Migration impact: This was a breaking change for remote server deployments. Servers using the old HTTP+SSE transport needed to be updated. The stdio transport was unaffected.

# Old HTTP+SSE flow:
# 1. Client opens GET /sse (persistent SSE connection)
# 2. Server sends endpoint URL via SSE
# 3. Client sends POST to that endpoint
# 4. Server sends responses via SSE

# New Streamable HTTP flow:
# 1. Client sends POST /mcp with JSON-RPC message
# 2. Server responds with JSON (single) or SSE stream (multiple messages)
# 3. Optional: Client opens GET /mcp for server-initiated messages

OAuth 2.1 Authentication

The 2025-03-26 spec added a formal authentication framework for remote MCP servers based on OAuth 2.1 (which combines the best practices of OAuth 2.0 with PKCE and other security improvements).

Key additions:

Authorization flow: Standard OAuth 2.1 authorization code flow with PKCE
Dynamic client registration: Clients can register with servers automatically
Token handling: Bearer tokens sent via standard Authorization headers
Protected Resource Metadata: Servers advertise their auth requirements at a well-known endpoint

This was a major step toward enterprise readiness, enabling MCP servers to authenticate users, enforce access controls, and integrate with existing identity providers. See our MCP security model guide for details.

Audio Content Type

The specification added audio as a content type alongside text and image, enabling MCP servers to return audio data from tool calls. This opened up use cases for voice processing, music generation, and audio analysis tools.

Additional Changes

Tool annotations: Metadata hints on tools (e.g., readOnlyHint, destructiveHint, openWorldHint) to help clients make UI and safety decisions without relying solely on the model
Completions API refinements: Improved auto-completion support for resource URIs and prompt arguments
Clarified error handling: More detailed specification of JSON-RPC error codes and their meaning

2025-06-18: Structured Output and Elicitation

This specification version focused on giving servers more control over tool output formats and enabling richer human-in-the-loop interactions.

Structured Tool Output

Servers gained the ability to define output schemas for tools, not just input schemas. This lets the AI model know exactly what structure to expect from a tool result, improving reliability and enabling better downstream processing.

{
  "name": "get_stock_price",
  "description": "Get the current price of a stock",
  "inputSchema": {
    "type": "object",
    "properties": {
      "symbol": { "type": "string" }
    },
    "required": ["symbol"]
  },
  "outputSchema": {
    "type": "object",
    "properties": {
      "symbol": { "type": "string" },
      "price": { "type": "number" },
      "currency": { "type": "string" },
      "timestamp": { "type": "string" }
    }
  }
}

Elicitation

A new capability that allows servers to request additional information from the user during tool execution. Previously, if a server needed clarification mid-operation, it had no standard way to ask. Elicitation provides a protocol-level mechanism for this:

Server sends an elicitation request with a message and an input schema
Client presents the request to the user
User provides the requested information (or declines)
Server continues execution with the additional context

Use cases include: confirming destructive operations, requesting missing parameters, choosing between ambiguous options, and multi-step wizard-like workflows.

Tool Annotations Expansion

The tool annotations introduced in 2025-03-26 were expanded with additional hints:

Annotation	Purpose
readOnlyHint	Tool only reads data, does not modify anything
destructiveHint	Tool may perform irreversible operations
idempotentHint	Calling the tool multiple times with the same args produces the same result
openWorldHint	Tool interacts with external systems outside the server's control

These annotations help MCP clients make informed decisions about confirmation dialogs, retry behavior, and safety warnings.

2025-11-05 (Draft): Batching, Resource Links, and Event Streams

The late-2025 draft specification introduced several features aimed at performance optimization and richer data modeling.

JSON-RPC Batching

Support for sending multiple JSON-RPC messages in a single request, reducing round trips for operations that involve multiple independent tool calls. This is particularly valuable for remote servers where network latency is a factor.

Resource Links in Tool Results

Tools can now include resource links in their results, allowing the AI model to discover and access related resources dynamically. For example, a "search_files" tool could return matching file paths as resource links that the model can then read via the resources API.

Event Streams

A formalization of server-initiated event patterns, allowing servers to push notifications about external changes (e.g., a file was modified, a database record was updated) to connected clients.

Improved Error Taxonomy

More granular error codes and structured error data to help clients handle failures gracefully and provide meaningful feedback to users.

Breaking Changes Summary

If you maintain an MCP server, these are the breaking changes to be aware of across specification versions:

Version	Breaking Change	Impact	Migration
2025-03-26	HTTP+SSE transport replaced by Streamable HTTP	All remote servers	Update transport layer to support Streamable HTTP endpoints
2025-03-26	Session management via Mcp-Session-Id header	Remote servers with state	Add session header handling
2025-03-26	OAuth 2.1 for authentication	Remote servers with auth	Implement OAuth 2.1 flow or use SDK support
2025-06-18	Tool result format changes for structured output	Servers using output schemas	Add outputSchema to tool definitions

The stdio transport has remained stable across all versions, making it the most reliable choice for local development. Remote servers have seen more evolution as the protocol adapted to production deployment requirements.

For guidance on building servers that handle these changes, see our guides on building MCP servers in Python and building MCP servers in Node.js.

Version Negotiation in Practice

Every MCP connection begins with an initialization handshake where the client and server negotiate the protocol version and capabilities:

// Client sends:
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "roots": { "listChanged": true },
      "sampling": {}
    },
    "clientInfo": {
      "name": "MyApp",
      "version": "1.0.0"
    }
  }
}

// Server responds:
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-06-18",
    "capabilities": {
      "tools": { "listChanged": true },
      "resources": { "subscribe": true }
    },
    "serverInfo": {
      "name": "my-server",
      "version": "2.0.0"
    }
  }
}

The server responds with the protocol version it supports. If the client requests a newer version than the server supports, the server responds with its latest supported version, and both sides use that version for the session.

What Is Coming Next

Based on public discussions in the MCP specification repository and community channels, several features are under active development or consideration:

Feature	Status	Description
Namespace support	Under discussion	Avoiding tool name collisions when multiple servers are connected
Enhanced multimodal	In progress	Richer support for video, structured documents, and other content types
Federation	Early exploration	Standard for MCP server registries and discovery
Rate limiting	Proposed	Protocol-level rate limiting headers and backpressure
Versioned tool schemas	Proposed	Allowing tools to evolve their schemas without breaking clients

The MCP specification is developed in the open on GitHub. Server developers and the broader community can participate in shaping its evolution.

Staying Up to Date

To keep your MCP servers and integrations current with specification changes:

Watch the spec repository: The official MCP specification is maintained on GitHub with pull requests for every change
Use official SDKs: The TypeScript and Python SDKs from Anthropic are typically updated within days of specification changes
Test against multiple versions: If your server supports both local and remote clients, test against the latest spec version for both transports
Monitor this changelog: We update this page as new specification versions are released