Choose a protocol era before copying code

The mechanism

A protocol version is a contract, not a package version. This edition targets 2026-07-28, checked on 6 October 2026. The current specification uses self-contained requests and per-request capabilities. Older examples use an initialization exchange and negotiated session state. Combining fragments from those eras produces a client that looks plausible but speaks neither correctly.

Keep three values in your compatibility record: protocol date, SDK package version and transport implementation. A release number alone does not prove support for a protocol feature. Likewise, a host that supports tools may not support elicitation or an optional extension.

The current protocol removes the core initialize exchange and protocol session identifiers. This does not forbid an application from keeping durable jobs, user sessions or caches. It means those application mechanisms must not be confused with a removed protocol session.

Worked example

Use a compatibility worksheet before installing or connecting anything. The following is a planning record: null means unverified. Preserve that distinction when a tutorial runs against a newer library. Record an actual version only after checking the installed package and the server’s supported protocol list.

{"protocol_target":"2026-07-28","transport":"stdio",
 "python_sdk_version":null,"host_version":null,
 "supports_discover":null,"supports_elicitation":null,
 "tested_at":null,"status":"not_run"}

Practice: predict, inspect, explain

Offline exercise. Compare a legacy transcript containing initialize and notifications/initialized with chapter 3’s request metadata. Highlight which messages belong to each era. Add a deliberately mismatched version to your worksheet and describe the expected negotiation failure.

Expected observation: compatibility is a matrix, not a single yes/no SDK badge. The modern client should use a mutually supported version or fail clearly. It should not strip required metadata until a server happens to accept the request. Keep legacy fallback explicit and test it separately from modern operation.

Troubleshooting and trade-offs

For a failure during connection, capture the method name, protocol date and transport without recording tokens. Check the server’s documentation before editing payloads. A method-not-found response may mean a legacy peer, an unsupported capability or the wrong endpoint. On stdio, follow the documented discovery probe and fallback rules; do not infer that every error authorizes an initialize retry.

Interview practice

Completion check

Label a transcript’s era from its structure and write a compatibility record that separates verified values from unknowns.

Sources and version notes

This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.

• Official documentation: Versioning
• Official documentation: Changelog
• Official documentation: Versioning
• Official documentation: Protocol eras