[chemicL]

The latest protocol revision introduced a stateless incarnation of the protocol. It requires no initialization handshake or session management, and it doesn't allow server-to-client requests.

An instance of the modern client is meant to stand for one user. It does no I/O when built and can share its transport with other clients, so an application that handles authorization creates one per user over a single HTTP transport. Identity isn't passed to client methods; the caller's McpTransportContext reaches the transport's request customizer and authorization error handler. The tool catalog is therefore that user's view of the server. The client also uses it for x-mcp-header mirroring.

Clients are built with McpClient.async(transport) or McpClient.sync(transport), and each operation goes through an immutable request spec, e.g. client.tool("create_issue").arguments(args).call(). Timeouts, progress, _meta and elicitation handlers are set on the builder and can be overridden per call on the spec.

The client takes care of what the revision requires:

• the _meta block with version and capabilities on every request
• version renegotiation
• the multi round-trip loop for input_required results (with callOnce() for callers that run it themselves)
• the Mcp-* and Mcp-Param-* headers, with one retry on -32020
• subscriptions/listen streams that report which parts of the filter the server doesn't honour

A round timeout bounds each exchange but not the time a user spends answering; a call timeout is optional.

The sync client runs the loop and its handlers on the caller's thread.

Transports: Streamable HTTP on the JDK HttpClient, and stdio. Sampling, roots, logging and extensions are left out for now.

On the server side, the HTTP and stdio wire constants are shared with the client, input requests are typed by method and mode, and the listen filter is open so features can honour extension fields. InputResponses.get and RequestStateCodec.open return null instead of an empty Optional.

A conformance client in conformance-tests/client-modern passes the non-auth 2026-07-28 client scenarios.

Part of #1011

[HanselIdes]

Thanks for the modern client. We maintain a downstream MCP client connector on top of this SDK and plan to adopt 2026-07-28, so we have two questions about scope and timing.

1. Fallback to the initialize handshake. The compatibility matrix in the spec says a modern-only client fails against a server that still requires initialize. Most deployed servers will stay on the old protocol for a while. In the changed files I found the server/discover cache and the UnsupportedProtocolVersion handling, but no probe or fallback path. Is a dual-era client in scope for this PR, planned as a follow-up, or left to callers to combine from the 2.x client and this one? If it is a follow-up, which issue tracks it? The closest issue I found is #1203, which covers dual-era servers.

2. Release timing. The PR is in milestone 2.2.0-M3. Will the modern client ship in that milestone? Is there an expected date for a non-milestone release that includes it? The roadmap says the SDK implements new revisions within six months of the spec, which is about the end of January 2027. We need to know whether to plan around that date.