During a code review, a developer sees that their server answers some tools/list requests with an InputRequiredResult asking the user, through elicitation, which team's tools to show. The client did declare the elicitation capability. How should the reviewer assess this design?
Select an answer to reveal the explanation.
Short Explanation
Only three doors in the building have an intercom: tools/call, resources/read and prompts/get. Knock on any other door, like tools/list, and nobody is allowed to ask you questions back. The trap is thinking a declared elicitation capability unlocks every request.
Full Explanation
The multi round-trip requests pattern lists exactly which client requests may receive an InputRequiredResult: prompts/get, resources/read and tools/call. Servers must not send InputRequiredResult responses on any other client request, so a tools/list that answers with an elicitation is non-compliant no matter how the rest of the exchange is built. List results are also designed to be cacheable and deterministic, and interim input_required results carry no caching hints, which is another reason the list operations stay out of MRTR. Adding requestState does not change the rule; it only governs how a permitted retry reconstructs state. The client's declared elicitation capability is a necessary condition for including an elicitation request at all, not a license to use MRTR on unsupported methods. Restricting the pattern to resources/read alone is too narrow, because tools/call and prompts/get are equally eligible. Exam caveat: lists may legitimately differ by the authorization presented on the request, which is the correct way to show a team its own tools. Operational check: search the server for every code path that emits resultType "input_required" and confirm each belongs to one of the three permitted methods.