Which MCP methods can return input_required, and what may they ask for?

## The closed set of methods MCP 2026-07-28 does not let any call pause for input. Exactly three may return a result whose `resultType` is `"input_required"`: - `tools/call` - `prompts/get` - `resources/read` Everything else — `tools/list`, `prompts/list`, `resources/list`, `resources/templates/list`, `server/discover`, `completion/complete` — must answer with a complete result. The line is drawn along a sensible axis: discovery and enumeration are cheap, cacheable, and describe what the server offers regardless of the caller, so they can never depend on client-side input. The three that can pause are the ones that *execute* something. A practical consequence for client implementers: the MRTR loop only needs to exist in the code paths for those three methods. A client's list-fetching code can assume a single round trip. ## The closed set of things that can be asked Each value in the `inputRequests` map is one member of the union: ``` InputRequest = CreateMessageRequest | ListRootsRequest | ElicitRequest ``` - **`sampling/createMessage`** — the server asks the client's LLM to produce a completion. Sampling was **deprecated** in 2026-07-28 (SEP-2577); the stated migration is for servers to integrate directly with an LLM provider API instead. - **`roots/list`** — the server asks which directories or files the client considers in scope. Roots was **deprecated** in the same revision; the migration is to pass paths as tool parameters, resource URIs, or server configuration. - **`elicitation/create`** — the server asks the *user*, through the client's UI, for a value. Elicitation is **not** deprecated and is the one member of the union expected to grow in use. The symmetric union on the way back is `InputResponse = CreateMessageResult | ListRootsResult | ElicitResult`. There is no fourth kind, and a server cannot invent one: an extension that needs a different interaction defines its own mechanism rather than widening this union. ## Why the union is closed A client must be able to enumerate, at build time, every kind of thing a server can demand of it — that is what makes the capability model meaningful. `ClientCapabilities` advertises `elicitation`, `roots` and `sampling`, and a server that asks for something the client never declared should expect failure rather than cooperation. A closed union also keeps the security story tractable: the host knows the complete list of ways a server can reach back toward the user or the model, and can put consent in front of each one. ## Reading the deprecations correctly Two of the three members being deprecated in the same revision that made MRTR the only path can look contradictory. It is not: MRTR is the *transport* of these interactions, and it will outlive the two deprecated payload types. Deprecated features remain in the spec for at least twelve months, with the earliest removal in the first revision released on or after **2027-07-28**, and new implementations SHOULD NOT adopt them. So in 2026 you must still be able to *receive* a `roots/list` or `sampling/createMessage` request from an older server, while designing anything new around elicitation or plain tool parameters. ## Multiple asks in one round Because `inputRequests` is a map rather than a single field, one interim result can carry several entries of different kinds — say an elicitation and a roots request under two different server-assigned keys. The client fulfils each, fills the corresponding key in `inputResponses`, and retries once with all the answers, rather than making a round trip per item. ## Interview framing The strongest answer names the three methods, names the three request types, and flags which are deprecated and which is not. A candidate who says "any request can return input_required" or who describes the server calling the client directly is answering from the pre-2026-07-28 era.