OrientationAll domainsTrack 2 · 1 / 14

From a phone call to letters

Revision 2026-07-28 makes one decision, and almost every other change follows from it: each MCP request now has to stand on its own.

Listen to this lessonAudio overview in Gemini Notebook · about 15–25 min · opens in a new tab

In real life

Black Friday, three pods, one restart

Picture an AI shopping assistant whose MCP server runs on three pods behind a round-robin load balancer. It's 9:02 on Black Friday. Under the legacy protocol, each shopper's session (their negotiated capabilities, their cart, the paused "which size?" question) lives in one pod's memory, so the load balancer has to pin every shopper to their pod.

At 9:04 the busiest pod runs out of memory and restarts. Several thousand shoppers lose their sessions in the middle of checkout.

Under 2026-07-28 the same incident is a non-event. Every request says who's asking and what it supports, carts are handles stored in a shared database, and the "which size?" question travels inside the request. The next request goes to a healthy pod, which answers it without knowing the old one ever existed.

What changed

Before (the "legacy" protocol, 2025-11-25 and earlier), talking to an MCP server was like a phone call. The client dialled, both sides introduced themselves with initialize, and the server remembered who was on the line. In the middle of a call, the server could interrupt and ask the client something.

Now (the "modern" protocol, 2026-07-28), it's like sending letters. Every request carries its own version, capabilities and identity in _meta. The server never sends requests of its own. Anything that must outlive one request is an explicit handle that the client passes back.

The spec has three words for this, and the exam uses them: modern (per-request metadata), legacy (the initialize handshake) and dual-era (an implementation that supports both).

How each page works

What changed, why, the wire diagram, the actual payloads, what it does to your server, how to test it, why it's good news, then a quick check before you move on.

Reading the payloads

− removed in 2026-07-28 + new in 2026-07-28 ● same field, new rule

Current first

Diagrams open on 2026-07-28, and old payloads are folded away under "What it used to look like". Open them only to compare; the exam tests the current rules.

Why it changed

A phone call has to keep reaching the same machine. That means sticky sessions, shared session storage and reconnect logic. A letter can be opened by any machine in the pool. The spec now says it outright: "all the information needed to process a request is contained in the request itself."

On the wire

Same job, two eras

Compare

This is how it works in 2026-07-28. Switch to Legacy only to see what it replaced.

Solid arrows are requests, dashed are responses or notifications. Red ✕ is gone; green is new.

Check yourself

Answer all 2 correctly and this lesson is marked as learned.

Q1Under 2026-07-28, what is an open stdio connection to a server?

Q2Spot the bug: on a stdio connection, a server reads clientCapabilities from the first request and reuses them for every later request on that connection.

Read the spec

Base protocol: Statelessness ↗Versioning and compatibility ↗

Feedback or a correction? Email diego [at] diegozuluaga [dot] dev or open an issue on GitHub.

Content CC BY 4.0 · Code MIT

← Back to Track 1Registry, extensions, A2ANext →The handshake is gone

Tip: ← and → move between lessons. Hover any heading and press # to copy a link to it.