Topic 6: How the protocol has evolved

MCP has had five specification revisions in under two years. Each revision is named by the date it was finalised, and that date string is the protocol version that clients and servers exchange (you saw 2026-07-28 in every message in Part D). Many servers in the wild still speak older revisions, so knowing what changed when is practical, not trivia.

E.1 The five revisions

Source: the official changelog pages at modelcontextprotocol.io/specification/<revision>/changelog, one per revision, each listing changes since the previous one.

E.2 The major shifts, and why they happened

Five shifts explain most of the history. Each one solved a problem that real deployments ran into.

1. Transport replacement (2025-03-26). HTTP+SSE needed two endpoints and a long-lived SSE connection per client, which is awkward behind load balancers and serverless platforms. Streamable HTTP uses one endpoint; each POST gets either a plain JSON reply or an SSE stream when the server has more to say. Our curl calls in Part D received plain application/json replies from that single /mcp endpoint. HTTP+SSE is now formally Deprecated (SEP-2596) and should not be used for anything new.

2. The OAuth model (2025-03-26, reshaped 2025-06-18). The first authorization design let an MCP server act as its own authorization server. The 2025-06-18 revision separated the roles: the MCP server is an OAuth resource server that only validates tokens, and a separate authorization server (your identity provider) issues them. Resource indicators bind each token to one server so a malicious server cannot replay it elsewhere. Module 7 builds exactly this.

3. Elicitation (2025-06-18, extended 2025-11-25). Servers sometimes need a missing detail from the human, not the model. Elicitation gave them a structured way to ask, first through forms and later through URLs for sensitive flows such as signing in to a third-party service.

4. Structured output (2025-06-18). Tool results had been text blocks meant for a model. Structured output added a JSON copy that matches a declared output schema, so application code can use results without parsing prose. You saw both halves in the tools/call response.

5. The stateless redesign (2026-07-28). Earlier revisions opened a stateful connection with initialize and, over HTTP, pinned it with a session id. That made horizontal scaling hard: a request had to reach the replica that held its session. In 2026-07-28 every request is self-contained. Discovery became an optional single call, server/discover; server-initiated requests became Multi Round-Trip Requests, where the server returns input_required and the client retries; and state that must survive between calls is carried explicitly as handles in tool arguments. Module 2 and Module 9 build on this.

You can see both eras from one client. The Python SDK's Client defaults to mode="auto": it probes with server/discover and falls back to the initialize handshake if the server is older. mode="legacy" forces the old handshake.

"""Module 1: one server, two protocol eras.

Run:  PYTHONPATH=. python examples/m01_versions.py
"""
import sys

import anyio

from mcp import Client

sys.path.insert(0, "examples")
from m01_first_server import mcp  # noqa: E402


async def main() -> None:
    for mode in ["auto", "legacy"]:
        async with Client(mcp, mode=mode) as client:
            result = await client.call_tool("search_notes", {"query": "caffeine", "limit": 1})
            top = result.structured_content["result"][0]["note_id"]
            print(f"mode={mode:<6} negotiated {client.protocol_version}  top hit {top}")


if __name__ == "__main__":
    anyio.run(main)

Code explained

• In simple words: the same conversation held in two dialects, to show the server understands both.
• What happens: for each mode the client connects in memory to the Part C server, calls search_notes for "caffeine", and prints the negotiated revision. In auto mode the client sends server/discover; in legacy mode it runs initialize, the handshake every pre-2026 client uses.
• Comes out: real output:
  textCopy

  mode=auto   negotiated 2026-07-28  top hit coffee-and-focus
  mode=legacy negotiated 2025-11-25  top hit coffee-and-focus

  Same server, same tool, same answer, two protocol eras. MCPServer speaks both, which is why a server built with SDK v2 works with older hosts that have not moved to 2026-07-28 yet. The legacy mode also matters when you need server-initiated requests on older hosts; Module 2 and Module 4 return to it.

E.3 Following Specification Enhancement Proposals

The protocol changes through Specification Enhancement Proposals (SEPs). A SEP is a design document for a significant change: a new feature, a breaking change, a governance change, or anything controversial. Small fixes and typo corrections are ordinary pull requests instead. The SEP numbers in the revision table above (SEP-2575, SEP-2577, and so on) are how you trace any change back to its design and discussion.

Since the 2026-07-28 revision, the workflow is pull-request based (SEP-1850): an author adds a Markdown file to the seps/ directory of the specification repository (github.com/modelcontextprotocol/modelcontextprotocol), and the SEP takes its number from the pull request. A sponsor (a Core Maintainer or Maintainer) champions the proposal and manages its status. Core Maintainers review SEPs every two weeks. A SEP reaches Final only once a reference implementation exists and, for protocol behaviour you can observe, a conformance test is merged.

There are four SEP types: Standards Track (protocol features), Extensions Track (optional extensions such as tasks), Informational, and Process.

A practical routine for staying current, which takes about fifteen minutes a month:

This course is pinned to mcp==2.2.0 and revision 2026-07-28. When the next revision lands, Modules 2, 4, 5, and 9 are the ones most likely to need a review; the ideas in this module and in Modules 3, 8, and 10 change slowly.