`acceptedContent<T>(responses, key)` is a ~6-line content reader over the SDK-unvalidated `inputResponses` map (it checks `entry.action === 'accept'` and returns `entry.content`) — it does no protocol or validation work the SDK must own, and the bare responses are already surfaced at `ctx.mcpReq.inputResponses`. Per REVIEW.md Guiding Principle #1 ("content helpers belong in userland") and the API-surface checklist ("helpers users can write themselves belong in a cookbook, not the SDK"), consider

When a round's embedded requests are fulfilled concurrently with `Promise.all(entries.map(... dispatchInputRequest ...))` (inputRequiredDriver.ts ~188-198), a fast-failing entry (missing handler, unknown kind, or handler throw) rejects the whole call but never aborts the still-running sibling handlers — e.g. `input_required` with `{ ask: elicitation/create, sample: sampling/createMessage }` and no sampling handler: the `sample` dispatch throws `CapabilityNotSupported` immediately while the elici

The synthesized embedded-handler context in _dispatchInputRequest binds ctx.mcpReq.send/notify to relatedMessagingUnavailable(), which throws synchronously, but BaseContext.mcpReq.send/notify are declared Promise-returning (and the wire-path implementations are async). A handler reused across wire and MRTR dispatch that uses the documented fire-and-forget idiom ctx.mcpReq.notify(n).catch(...) will have the throw escape before .catch can attach on the MRTR path, hard-failing the whole input-requi

decodeResult() in packages/core/src/wire/rev2026-07-28/codec.ts discriminates input_required on the raw resultType alone, with no check on the method, so a 2026 server that answers a NON-MRTR method (e.g. completion/complete, tools/list) with input_required is driven into the auto-fulfilment driver (dispatching the client's elicitation/sampling/roots handlers and retrying the original call) instead of being rejected. This deviates from the SDK's own wire-response contract in schemas.ts, where on