Complete MCP Version History: Every Change Explained

If you're building an MCP server, or deciding whether to connect one to your workflow, the version number matters more than you might think. Each of MCP's four spec releases has changed what servers can do, what clients support, and in one case, removed a feature entirely. This is the complete record — what shipped in each release, what broke, and what you actually need to know to make decisions today.

Why Version History Matters

MCP uses date-string versioning. The spec version your server declares in its initialize response determines what features it can use and which clients will talk to it. Build to a version that's too new and older clients will reject your server. Build to a version that's too old and you miss out on features — like structured outputs, OAuth, or MCP Apps — that could meaningfully improve what your server delivers.

The spec also had a genuine breaking change in June 2025. If you haven't checked your implementation against 2025-06-18, there's a real chance something silently broke.

To understand what MCP is before diving into the history, see our plain-English MCP explainer.

Quick Reference: All Four Versions

Version 1: 2024-11-05 — The Launch

Anthropic released the first MCP spec on November 5, 2024. The core idea: instead of building one-off integrations between each AI model and each external tool, define a universal protocol so any MCP-compatible client can talk to any MCP-compatible server. The N×M problem becomes N+M.

The Four Core Primitives

The launch spec defined four primitives that every subsequent version has kept:

• Tools — functions the AI can call. A tool has a name, a JSON Schema description of its inputs, and returns a result. This is the most-used primitive.
• Resources — data the server exposes that the client can read. Think files, database records, API responses. Resources are identified by URIs and can be subscribed to for updates.
• Prompts — pre-written prompt templates a server provides. Useful for standardising how users invoke complex multi-step workflows.
• Sampling — a mechanism for the server to request that the client (the AI model) perform an inference. This enables server-side agentic loops where the server drives reasoning steps.

Transport: stdio and SSE

The original spec supported two transport mechanisms:

• stdio — the server runs as a local process, communicating over standard input/output. This is still the most common approach for local MCP servers and developer tooling.
• SSE (Server-Sent Events) — a unidirectional HTTP streaming mechanism for remote servers. Worked, but had limitations: it couldn't handle bidirectional streaming cleanly, and required clients to open two connections (one SSE stream for server-to-client, one POST endpoint for client-to-server).

The protocol itself uses JSON-RPC 2.0 — a lightweight remote procedure call format built on JSON. All messages between client and server are JSON-RPC requests, responses, or notifications.

Why This Was Significant

Before MCP, connecting Claude to an external tool meant Anthropic writing a custom integration, or developers using Claude's function calling API with bespoke glue code. There was no standard. MCP 2024-11-05 provided the standard. The primitives were deliberately minimal — just enough to cover the common cases without over-engineering for hypothetical needs.

The spec shipped alongside reference SDKs for TypeScript and Python, which meant most developers could build a working server in an afternoon without reading the full protocol spec.

Version 2: 2025-03-26 — The Infrastructure Update

The March 2025 release was the first major revision. It addressed real pain points that had emerged as more developers built production MCP servers: SSE's transport limitations, the absence of any authentication standard, and the inability to signal tool intent to clients.

For a detailed comparison of this release against the original, see our MCP 2024 vs March 2025 guide.

Streamable HTTP Replaces SSE

The biggest change: SSE was replaced by Streamable HTTP as the remote transport mechanism. Streamable HTTP uses a single HTTP connection with chunked transfer encoding, allowing true bidirectional message flow. The awkward two-connection SSE pattern was gone.

This was a breaking change for any server using the SSE transport. If you were running a remote MCP server over SSE and upgraded to the March 2025 spec, your clients needed to be updated to use Streamable HTTP. Servers using stdio were unaffected.

Streamable HTTP also made it easier to deploy MCP servers as standard HTTP services — on any cloud provider, behind any load balancer, without special SSE configuration.

OAuth 2.0 Authentication

The original spec had no authentication story. Any client could connect to any server, and auth was left entirely to the implementation. The March 2025 spec added OAuth 2.0 support, defining how MCP clients authenticate with servers that require credentials.

This was critical for enterprise adoption. Without a standard auth mechanism, every organisation was inventing its own auth layer on top of MCP — defeating the interoperability the protocol was designed to provide.

Tool Annotations

A smaller but practically important addition: tool annotations. Servers can now declare metadata about each tool's behaviour:

• readOnly — the tool only reads data, never modifies state
• destructive — the tool deletes or permanently modifies data
• idempotent — calling the tool multiple times has the same effect as calling it once

These annotations let clients make smarter decisions. A client can show a confirmation UI before calling a destructive tool. An agent framework can safely retry an idempotent tool call after a network failure. Without annotations, clients had no way to know the consequences of invoking a tool without actually invoking it.

JSON-RPC Batching Added

The March 2025 spec added support for JSON-RPC batching — sending multiple requests in a single message and receiving multiple responses. The intent was to reduce round-trip latency for agents that needed to fan out multiple tool calls simultaneously.

This feature was controversial, and as you'll see, it didn't survive to the next release.

Version 3: 2025-06-18 — The Breaking Update

The June 2025 release is the most contentious in MCP's history. It introduced two genuinely useful features — structured tool outputs and elicitation — while simultaneously removing a feature that had shipped just three months earlier. If you're maintaining an MCP server, this is the version most likely to have quietly broken something.

We've written a detailed breakdown of the differences in our MCP March vs June 2025 comparison.

JSON-RPC Batching Removed

The most disruptive change: JSON-RPC batching was removed as a breaking change. Servers and clients that implemented batching per the March 2025 spec now had to strip it out.

The working group's rationale: batching added significant implementation complexity for SDK authors, required careful ordering guarantees that were difficult to test, and didn't provide the latency benefits originally hoped for in practice. Most agent frameworks were achieving parallel tool calls through other means anyway.

If your server was relying on batching, you need to refactor. There is no backwards-compatible path — batching is gone from the protocol.

Structured Tool Outputs

One of the most requested features since the launch: structured tool outputs. Prior to this release, tools returned content — text, images, or other blobs — but with no schema attached. The client had to parse the output or rely on the AI model to extract structure from raw text.

With 2025-06-18, tool definitions can include an outputSchema — a JSON Schema that describes the structure of the tool's return value. When a tool returns structured data, the client gets it as a typed JSON object, not a string to be parsed.

This enables a class of server designs that were previously awkward: data pipeline servers, transformation servers, servers that feed their output directly into another tool call without going through the AI model's text parsing. We have a full explainer on MCP structured tool outputs if you want the technical details.

Elicitation

Elicitation is the ability for an MCP server to pause a tool call and ask the user for additional information mid-execution. Before this feature, if a tool needed clarification — "which of these three files did you mean?" — the only option was to return an error or make a guess.

With elicitation, a server can emit an elicitation request specifying what information it needs and the schema of the expected response. The client presents this to the user, collects the answer, and sends it back to the server, which resumes the tool call with the new information.

This is especially useful for destructive or irreversible operations where confirmation is important, and for tools that need to disambiguate ambiguous inputs. See our elicitation explainer for a full walkthrough.

OAuth Resource Servers

The June 2025 spec refined the OAuth story from March by adding proper OAuth Resource Server support. Servers can now participate in token introspection flows, enabling more standard enterprise SSO integrations where the MCP server acts as an OAuth resource server in a larger identity architecture — rather than being the OAuth authority itself.

Version 4: 2025-11-25 — The Industry Standard Moment

The November 2025 release is the least technically disruptive of the four — no breaking changes, no removed features — but it's arguably the most significant in terms of what it means for the MCP ecosystem.

Read our full breakdown at MCP 2025-11-25: What's New. Here's the summary:

MCP Apps

MCP Apps introduced interactive UI components that MCP servers can render inside Claude conversations. Instead of returning plain text or structured JSON, a server can return an app response — a sandboxed UI component with charts, tables, buttons, and interactive state.

Launch partners included Amplitude, Asana, and Figma, each shipping production MCP Apps that turned Claude into a live interface for their products. A user asking Claude about their Amplitude data gets an interactive analytics dashboard inline, not a text summary.

Linux Foundation Governance

Anthropic donated MCP governance to the Linux Foundation, which created the AI Agents Interoperability Foundation (AAIF). MCP is now governed by a neutral body, not a single company. This removes the biggest enterprise adoption blocker — the perception that MCP is Anthropic's proprietary protocol and could change without community input.

SEP Process

The Specification Enhancement Proposal (SEP) process formalised how spec changes happen. Any developer can submit a SEP. It goes through public review, AAIF board acceptance, reference implementation, and incorporation into a release. The MCP roadmap is now transparent and community-driven.

OpenAI and Google Adoption

Both OpenAI and Google formally adopted MCP in 2025. An MCP server now works with Claude, ChatGPT, and Google Gemini. The "write once, run everywhere" promise of MCP is now real across all three major AI ecosystems.

How to Check Which Spec Version Your MCP Server Targets

There are three places to look:

The Initialize Response

During the MCP handshake, your server sends an initialize result. This result includes a protocolVersion field containing the spec version string. If you intercept or log MCP traffic, this is the authoritative source. A response might look like:

{
  "protocolVersion": "2025-06-18",
  "capabilities": { ... },
  "serverInfo": { "name": "my-server", "version": "1.0.0" }
}

Your SDK Version

If you're using an official MCP SDK (TypeScript or Python), the SDK version maps to a spec version. Check your package.json or pyproject.toml for the @modelcontextprotocol/sdk or mcp package version, then check the SDK's changelog to see which spec version it implements.

Your Server's Documentation or README

Well-maintained MCP servers declare their spec version in their documentation. If yours doesn't, it's worth adding — it helps users understand which clients are compatible.

Compatibility Guide: Which Version Should You Target?

This depends on what you're building and who your users are.

For New Servers Built Today

Target 2025-06-18 as your minimum. This gives you structured outputs, elicitation, and proper OAuth without MCP Apps complexity. Most production clients support 2025-06-18. If you need MCP Apps, target 2025-11-25, but verify that your target client actually supports it.

For Existing Servers on 2024-11-05

Upgrading from 2024-11-05 to 2025-06-18 skips the March release entirely — that's fine, the spec versions are independent releases, not sequential upgrade paths. The main migration work: update your transport if you're using SSE (switch to Streamable HTTP or stay on stdio), and check whether you inadvertently implemented JSON-RPC batching (you probably didn't — it was rare).

For Existing Servers on 2025-03-26

Before upgrading to 2025-06-18, audit for JSON-RPC batching usage. If your server handles batch requests, those handlers need to be removed. Everything else in the June release is additive — you can adopt structured outputs and elicitation incrementally.

For Enterprise or Regulated Environments

Use 2025-11-25. The Linux Foundation governance and the AAIF make MCP a spec you can formally reference in procurement and compliance processes. The neutral governance is specifically designed to make MCP safe for organisations that can't build on proprietary protocols.

For the Claude Desktop App

If you're building a server specifically for Claude Desktop App users (via local stdio connections), the spec version matters less than the SDK version. Claude Desktop App updates its supported spec version with each release. Check Anthropic's release notes to see the current supported version.

For full installation guidance, see our MCP server installation guide.