How does the round-trip loop work?
The client calls a tool. If the MCP server is missing something, a user confirmation, a model completion, a choice, it returns a result typed input_required, carrying the input requests and a requestState token. The client gathers the answers, calls the same tool again with them and the untouched token, and the server resumes from where it stopped. Each exchange is a complete, self-contained request, repeated until a normal result arrives; SDKs cap the rounds so a looping server fails loudly instead of forever.
Why did MCP move to this pattern?
Because the old mechanism made servers stateful. A server issuing sampling or elicitation requests mid-call needed the session to stay pinned to the same instance, which breaks behind ordinary load balancers and serverless platforms. With state carried in the token, any instance can pick up the next round. The pattern is what lets an MCP server scale like a normal web service, and it arrived in the 2026-07-28 revision together with the removal of protocol sessions.
What do builders have to handle on the client side?
Three things. Fulfilling each named input, which may mean prompting a user or running a model call; returning the state token byte-for-byte, since it is opaque and often signed; and bounding the loop, both in rounds and in what the user is asked, so a misbehaving server cannot farm approvals. The loop also interacts with tool calling UX: each round can surface as a pause in the run, like an agent session waiting on an approval gate.
When would a server use this instead of just failing?
Whenever the missing piece is legitimately the client’s to provide: a human confirmation before a destructive step, a credential choice, or a completion from the client’s model. Returning input_required is the protocol’s way of saying ask your user, without the server ever holding the conversation open.