A release tool on an MCP server must pause mid-operation until the user explicitly approves or rejects the deployment, then continue with that decision. Which mechanism fits under revision 2026-07-28?
Select an answer to reveal the explanation.
Short Explanation
Think of a bank teller who slides a form back across the counter: you sign it and hand the whole request back. That's multi round-trip in a nutshell, and the trap is the old style where the server rings you with its own request.
Full Explanation
Revision 2026-07-28 removes server-initiated JSON-RPC requests. When a server needs input mid-operation, it returns a result with resultType input_required, an InputRequiredResult whose inputRequests contain an elicitation/create request, here a form asking the user to approve or reject the release. The client presents it to the user, then retries the original tools/call with a new JSON-RPC id, the same parameters, and the user's answer in inputResponses, plus any requestState the server supplied. The server reads the decision and completes or aborts. Sending elicitation/create as a server request on the stream is the legacy pattern and is no longer allowed. Tool annotations are hints to the host about behaviour; they do not make a server block, and a destructive hint never records an approval. Sampling asks the client's model for a completion, so a model's reply is not a human approval, and sampling is deprecated in this revision. Exam caveat: for operations that run long while waiting, the Tasks extension offers the same pattern through the input_required status and tasks/update. Operational check: trace one release and confirm the first response carries resultType input_required, the retry uses a new id with inputResponses, and a declined action stops the deployment.