[okwalerie]

Clients using MCP 2026-07-28 need per-request metadata and discovery instead of an initialize/session handshake. This adds that path alongside the existing 2025-06-18, 2025-03-26 and 2024-11-05 behavior, based on client-support (PR #5).

The change adds stdio/HTTP server dispatch, modern client discovery and request metadata, explicit multi-round results, request-scoped subscriptions, mirrored HTTP headers, tool input-schema validation and bounded stdio frames. It also preserves application JSON key spelling and maps external integer request IDs around jsonrpc4clj's narrower ID constraint.

Validation:

• make format, make check: pass.
• make test: 63 tests, 292 assertions, zero failures/errors; includes real HTTP client/server multi-round calls and legacy regressions.
• Official conformance 0.2.0-alpha.12: 28 stateless checks pass (two dynamic list-mutation checks skipped), 8 caching checks pass, 2 DNS-rebinding checks pass, 4 resource-not-found checks pass.
• Official Python SDK 2.3.0: six application tools exercised against a real Rama IPC fixture over both legacy and modern stdio.

This is initial modern protocol support, not a full conformance/tier claim. OAuth, Tasks, progress/log streaming and the complete content/client/multi-round conformance suites are not validated. Applications remain responsible for authenticating opaque request state, validating returned inputs, and bounding backend execution. The intervening 2025-11-25 revision is not added. docs/mcp-2026-07-28.md documents the APIs and these limits.

The PR targets client-support to keep it separate from the existing PR #5 changes.

[okwalerie]

Oof - apologies for the slop PR. I gave no human review into this whatsoever.

Right now I'm working on a project and wanted to reuse this sdk, but updated to the new stateless MCP specifications. My intent was to submit a PR only after giving it a run, some reviews, and sitting on it for a bit.