ruby-sdk

Motivation and Context The Deprecated Features paragraph still described the pre-#516 design, claiming the SDK "emits deprecation warnings when they are used with protocol version 2026-07-28 or newer". Since #516 the only deprecation warning is the client-side one, emitted on a modern connect that declares the Roots or Sampling capabilities, exactly as the 1.2.0 CHANGELOG entry states. Logging never warns ( is the sanctioned SEP-2575 delivery path on that wire), and the server never warns either: counter-offers a legacy version, a modern pin is rejected at construction, and the modern lifecycle refuses the deprecated server-to-client request APIs outright rather than serving them with a warning. The paragraph now describes the shipped behavior and says where each feature lives per lifecycle: unchanged on legacy, carried on 2026-07-28 by input requests embedded in responses (the SEP-2322 multi round-trip requests pattern) and the envelope's . Those carriers are not the SEP-2577 replacements: the spec's deprecated-features registry points migrating implementations outside the protocol (tool parameters or configuration, direct LLM provider APIs, stderr or OpenTelemetry), and the paragraph now says so instead of presenting the modern delivery forms as the replacements. How Has This Been Tested? Documentation-only change; proofread against the module header and the CHANGELOG entry that shipped this behavior in 1.2.0, which the 1.3.0 release leaves unchanged. Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [x] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed

Three pages carried names the 2026-07-28 specification does not use: "Multi-Round-Trip Results" for the pattern the specification titles Multi Round-Trip Requests (MRTR) and serves at basic/patterns/mrtr - the results are the wire type, not the feature - plus "Completions" for the utility the specification titles Completion, and "Notification Subscriptions" for the pattern it titles Subscriptions. Retitle the three pages to the specification's names, move them to /server/mrtr/ and /client/mrtr/, /server/completion/, and /server/subscriptions/ following the specification's slugs, update every internal reference, and keep the URLs published with v1.3.0 working via jekyll-redirect-from. The Discovery page keeps its title but moves from /server/discovery/ to /server/discover/, matching the specification's slug and the RPC, with its published URL redirected the same way. Types of changes [ ] Bug fix (non-breaking change which fixes an issue) [ ] New feature (non-breaking change which adds functionality) [ ] Breaking change (fix or feature that would cause existing functionality to change) [x] Documentation update Checklist [x] I have read the MCP Documentation [x] My code follows the repository's style guidelines [x] New and existing tests pass locally [x] I have added appropriate error handling [x] I have added or updated documentation as needed

Opening this as the public record for the defect fixed in #521, as @koic suggested. A request id is the only key that routes request-scoped messages back to the request that caused them, and nothing checked whether the id was already taken. A second request arriving under an id still in flight took the routing entry over, and from that point: progress and log notifications for the first request were written to the second request's SSE stream, through in the Streamable HTTP transport; server-to-client requests, so sampling and elicitation prompts, resolved through the same map and were misdirected the same way; removed whichever stream held the id rather than the one that had actually failed, so a collision closed one stream and unregistered the other; was keyed the same way outside the transport, so routing broke on every transport, stdio included. The spec places the uniqueness obligation on the sender, and the 2026-07-28 revision draws it at exactly this window: "The request ID MUST NOT match the ID of any other request the sender has issued and not yet received a response for". The defect was that the server neither enforced the rule nor refused the violation, and misrouted silently instead. #521 refuses a request whose id is already in flight, as Invalid Request from the server core and 409 from the Streamable HTTP transport before any stream is registered, and identity-guards every removal keyed by request id. Only the in-flight window is enforced, so sequential reuse of an id still works. I reported this privately first. It was handled as a public fix rather than an advisory because reaching it needs the victim's , which already permits tool execution in that session, so nothing new is gained by the misrouting.