How would you design an MCP tool whose call is retried after input_required?

## The shape of the problem In MCP revision 2026-07-28 a server that needs input mid-call returns an `InputRequiredResult` and the client comes back with a **new request**: same method and arguments, plus `inputResponses` and the echoed `requestState`. From the server's point of view a single conceptual operation has become N separate requests, each self-contained, each independently authorized, each possibly landing on a different process. Everything difficult about the pattern follows from that. ## 1. Side-effect placement The first design rule is to decide, per tool, where the point of no return sits. If a tool validates, mutates, *then* asks the user to confirm, the mutation has already happened and the confirmation is theatre — and if the user abandons the flow, you are left with a half-applied change nobody acknowledged. Structure the handler as: gather everything you need (possibly over several rounds) → confirm → commit once, in the final round. Where pre-input work must happen, make it idempotent or reversible: writes keyed by a deterministic identifier, staged into a scratch area, or wrapped so a repeat is a no-op. The same reasoning applies across rounds. Round two must tolerate being executed twice, because a client whose connection broke may re-issue it with the same `requestState`. ## 2. Nothing may be held open Between rounds there is no connection to hold, no session to hang state on, and no notification if the client walks away — declining is expressed as *not retrying*, and it is indistinguishable from a slow user, a crashed client, or a network failure. So: no database transaction, no advisory lock, no reserved seat in a rate-limit bucket, no temporary file that only the retry can clean up. If the flow genuinely needs reserved capacity, reserve it with a TTL and a reaper, not with a held resource. ## 3. Continuation design `requestState` is opaque to the client, which leaves the server a real choice: - **Self-contained blob** — encode the continuation, authenticate it (MAC or encryption), stamp it with an expiry, and keep it small, since it travels on every subsequent round. Any node can resume; nothing shared is required. - **Handle into a store** — put only a key in the blob and keep the state in a shared cache with a TTL. Smaller on the wire, but reintroduces infrastructure that every replica must reach. Either way, validate before trusting: a tampered, expired or unknown value should be rejected with an invalid-params error rather than repaired or treated as a fresh call. And never treat possession of the handle as authentication — 2026-07-28 replaced its session-hijacking guidance with **State Handle Hijacking** for exactly this. Check the retry's own credentials, and check they belong to the principal the continuation was minted for. ## 4. Bound the loop Nothing in the protocol caps the number of rounds. Each one costs a full request, a potential user approval, and, if the round asks for a completion, a model call. A server that ratchets through many rounds is both a poor experience and an amplification vector. Decide a ceiling per tool, ask for everything you can in one map — `inputRequests` holds several entries at once — and fail with a clear error rather than looping indefinitely. ## 5. Authorization can change between rounds Each round carries its own token and its own `_meta`. A token may expire, be downgraded, or belong to a different user if the client is careless. The server must re-check scope on the round that finally commits, not merely on the round that started the flow. Equally, because the tool set MAY vary by the authorization presented, a tool that existed in round one might not be permitted in round three — handle that as a clean failure. ## 6. Observability Since rounds are separate requests, ordinary per-request logs will not show them as one operation. Correlate deliberately — a flow identifier inside the continuation, surfaced in logs, plus W3C Trace Context (`traceparent`, `tracestate`, `baggage` are the reserved `_meta` exceptions) so a trace spans the rounds. Without that, abandoned flows are invisible and you cannot measure how often users decline. ## 7. When not to use it at all If the missing information is something the caller could have supplied up front, put it in the tool's `inputSchema` and let the model fill it: a required argument costs zero extra round trips. Reserve MRTR for input only the user or the client can produce at that moment — a confirmation, a credential the model must not see, a choice among options discovered mid-execution. And if the problem is *duration* rather than *missing input*, the `io.modelcontextprotocol/tasks` extension is the right tool, not a retry loop.