Module input_required 

SEP-2322 multi round-trip requests, introduced at 2026-07-28.

What replaced server-initiated requests

Through 2025-11-25 a tool that needed the user asked the client directly: it sent elicitation/create down the response stream and waited for the answer to come back on a separate request. 2026-07-28 has no server-to-client requests at all — the schema’s ServerRequest union is gone — because a stateless server has nowhere to wait. Instead the tool answers with an InputRequiredResult naming what it needs, and the client retries the original request carrying inputResponses (and the server’s requestState, if it sent one).

So the shape a handler writes is a result, not a call:

• round one returns InputRequired, built here;
• round two reads the answers off its RequestContext.

Why requestState is sealed by the library

requestState is the server’s own memory, held by the client between rounds. A client that edits it can make a server believe it already asked a question, or already got an answer, it never did. The SEP’s scenario for this is explicit: a tampered state is rejected. Sealing it here, under a key the client never sees, means every handler gets that rejection without writing it — the dispatcher refuses a state that does not open before the handler runs.

Sealed, not encrypted: the state is integrity-protected, and its content is visible to the client. A handler that needs a secret in it must not put one there; this is the same contract the SEP gives requestState itself.

Structs

InputRequired

An interim result: what the server needs before it can finish.

InputRound

What a retry carried back: the client’s answers and the server’s state.

StateKey

The key a server seals requestState under.

Constants

INPUT_REQUIRED

The value resultType carries on an interim result.

Functions

capability_for

The client capability each input request needs, by method.

is_input_required

Whether a result is an interim one.