The MRTR inputRequests this outcome carries (empty unless needsInput). Read by the dispatch path so it can drop requests whose kind the client never declared.
Whether this outcome asks the client for more input.
The opaque MRTR requestState this outcome carries (empty unless set).
The JSON-RPC result payload (the final result, or an InputRequiredResult).
Return a copy of this input-required outcome with its inputRequests replaced by reqs (preserving requestState). Used by the dispatch path after filtering out unsupported request kinds.
The handler needs input; the client must gather it and resubmit with the matching inputResponses.
As inputRequired, but also attaches an opaque requestState (SEP-2322): a stateless draft server encodes whatever context it needs to resume the call into this blob, which the client echoes verbatim on the retry and the handler reads back via RequestContext.requestState.
The MRTR (input-required) machinery shared by ToolResponse and PromptResponse: the needsInput_/required_ state, the needsInput/inputRequests/requestState accessors, the two non-typed inputRequired factories, and withInputRequests/toJson. Both response types carry an InputRequiredResult required_ plus a result_ final result of their respective type; toJson switches on needsInput_. The mixin keeps these in lockstep so MRTR edits land on both. The genuine divergences — forVersion (throw vs return on a non-MRTR peer) and ToolResponse's typed complete(T)/inputRequired(T) helpers — stay per-struct.