A client sends a request declaring a protocol version the server does not support. The server answers with error -32022 whose data lists the versions it does support, and one of them is a version the client also implements. What should the client do next?
Select an answer to reveal the explanation.
Short Explanation
It's like a shop saying "we take euros or pounds, not dollars." You pay in a currency you both have and try again. The trap is assuming a version error means the shop is from a bygone era — a recognized -32022 actually proves it's modern.
Full Explanation
Version negotiation in 2026-07-28 happens per request. Every request names its version in io.modelcontextprotocol/protocolVersion, and a server that does not implement that version responds with UnsupportedProtocolVersionError, code -32022, whose data carries a supported array and the requested value. The client should select a mutually supported version from that list and retry the request, or surface an error to the user when no compatible version exists. Falling back to initialize is the wrong conclusion: the versioning rules say a recognized modern JSON-RPC error, such as this one, identifies a modern server, and the client should retry with a supported version rather than fall back to the legacy handshake. Resending the same request unchanged will simply fail again, because nothing about the version mismatch is transient. server/discover is a request the client may send to learn supported versions up front, but servers never push a version notification, and the error already supplied the list. Exam caveat: on HTTP the same error arrives with status 400, so clients must read the body before deciding a server is legacy. Operational check: force an unsupported version in a test request and confirm the client retries once with a version from data.supported.