The mechanism
The modern protocol requests additional client input through multi round-trip requests, abbreviated MRTR. The server returns an interim input_required result containing input requests and opaque request state. The client gathers the requested input and retries the original operation with a new JSON-RPC ID and corresponding responses.
Opaque state is not permission. A server should integrity-protect it and bind it to the principal, operation and lifetime. A client echoes it without interpreting or editing it. Replaying a state handle from another user must not resume that user’s operation.
Elicitation can collect user input when the client advertises support. Form-mode elicitation must not ask for passwords, API keys or payment details. Sensitive authorization flows use appropriate external URL-based mechanisms with explicit user review and identity checks.
Worked example
This is a conceptual continuation record, not a complete MRTR wire example. It isolates the state-binding checks you should implement around an SDK. “Accept” means the user supplied requested form input; it does not automatically authorize unrelated writes.
Original intent: summarize INC-104 in a chosen language
Server asks: preferred_language (non-sensitive enum)
State binds: principal + incident + operation + expiry
Client response: preferred_language = English
Retry: same original operation, new JSON-RPC ID, opaque state unchanged
Executor: validate state and current authorization before continuingPractice: predict, inspect, explain
Offline exercise. Change the principal, operation or expiry while reusing the state handle. Predict rejection for each case. Then let the user decline the form and specify a graceful outcome. Finally consider a client that never declared elicitation support.
Expected observation: the server must not request unsupported client behavior. Decline and cancellation are normal paths, not reasons to invent a user response. Cache neither interim results nor continuations that depend on request state and input responses. Preserve a bounded deadline across rounds.
Troubleshooting and trade-offs
Repeated input requests can become an accidental infinite workflow. Limit rounds, input size and total time. If state is stored client-side, protect its integrity and avoid embedding secrets. If state is stored server-side, enforce ownership and expiry on lookup. Do not expose an approval flag as an ordinary untrusted form field and then treat it as authenticated review.
Interview practice
Why use a new JSON-RPC ID on retry?
The continuation is a new protocol attempt, even though it resumes the same business intent. The opaque state and input mapping connect the rounds.
What must requestState be bound to?
At minimum the intended operation, principal and lifetime, with integrity protection. Additional target revision and single-use rules may be needed for consequential actions.
Completion check
Draw accept, decline, unsupported-client and expired-state paths without granting authority through form data.
Sources and version notes
This edition targets MCP 2026-07-28, checked 6 October 2026. SDK examples are version-sensitive and labelled when not executed. Synthetic fixtures are learning material, not protocol conformance evidence.
Make the understanding yours.
Use the completion check above. Mark this chapter when you can explain the mechanism and its limits.
Self-assessed reading progress. This does not certify that a lab ran or a system is secure.