Telling a Modern MCP Server From a Legacy One
Modern MCP has no opening handshake, so a client that must work with both current and older servers has to work out which kind it is talking to from how the very first exchange behaves, not from anything either side announces up front. Name the revision timeline from 2024-11-05 through 2026-07-28 and the headline change each revision made. Define modern, legacy, and dual-era, and read the compatibility matrix for every combination of client era and server era. Probe a server on stdio with server/discover and classify its response as modern, modern with a different version, or legacy, without keying the decision to one specific error code. Explain how a client negotiates a version after an UnsupportedProtocolVersionError (code -32022) without performing a handshake. State what 2026-07-28 removed outright, and why a server that only speaks modern versions still names its supported versions when it rejects an old connection attempt. Real deployments do not upgrade all at once. A client library gets built today and still has to talk to servers written months or years apart, some updated the day a new revision shipped and some left exactly as they were installed. The 2026-07-28 revision removed the one thing earlier revisions used to sort that out: an opening exchange that named a version before any real work began. Every modern request is…
Telling a Modern MCP Server From a Legacy One: Modern MCP has no opening handshake, so a client that must work with both current and older servers has to work…
This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.
Browse the complete course catalog or open this lesson on GitHub.