Progress, subscriptions and multi-round-trip requests

Asking the user mid-call: multi-round-trip requests

A refund tool shouldn't move money until the user confirms. In legacy MCP, the server would send its own request to the client in the middle of a call and wait. That needed the server to hold the call open and remember where it was: state again.

Think of a bank clerk who needs your signature. Instead of holding your place, they hand you a form and a stamped slip, and serve the next person. When you come back with both, any clerk can finish the job. The 2026-07-28 revision works that way, with multi-round-trip requests (MRTR):

1. The client calls tools/call as usual.
2. The server sees it needs input. Instead of a normal result, it returns an InputRequiredResult and ends the request:

{"resultType": "input_required",
 "inputRequests": {"confirm": {"method": "elicitation/create", "params": {
     "mode": "form", "message": "Refund $49.00 for order ord_51?",
     "requestedSchema": {"type": "object", "properties": {"confirm": {"type": "boolean"}}, "required": ["confirm"]}}}},
 "requestState": "eyJvcmRlci...Q.9c1f..."}

1. The client shows the question (here, an elicitation form) and collects the answer.
2. The client retries the original request with a new id, adding inputResponses (answers keyed like inputRequests) and echoing requestState:

{"name": "refund_order", "arguments": {"order_id": "ord_51"},
 "inputResponses": {"confirm": {"action": "accept", "content": {"confirm": true}}},
 "requestState": "eyJvcmRlci...Q.9c1f..."}

1. The server has everything it needs in this one request, so it finishes.

An elicitation answer has an action: "accept" (with content matching the schema), "decline" or "cancel". The server needs no memory between the two requests. Anything it wants to carry over goes in requestState, an opaque string the client must echo back untouched.

MRTR works for tools/call, prompts/get and resources/read, and the client must have declared the matching capability, such as elicitation.

requestState is attacker-controlled

That stamped slip passes through the customer's hands, so the bank must be able to tell if someone altered it. requestState passes through the client in the same way, so the spec says servers must treat it as attacker-controlled input. If it influences money, access or data, it must be integrity protected: signed (or encrypted) so changes are detected. It should also be checked against replay, someone reusing an old copy, by including:

• who it was issued to (reject it from anyone else);
• a short expiry;
• what request it belongs to, such as the tool name and order id (reject it on any other call).

That's exactly the signed-token pattern from Phase 8: a JSON payload, base64url-encoded, plus an HMAC signature. Signing stops edits and expiry limits replay, but it doesn't make a state single-use. If something must happen at most once, like a refund, the server still checks its own records (the order shouldn't already be refunded).

In plain words: anything you hand to a client and get back could have been changed. Sign it, and check the signature when it returns.

import base64, hashlib, hmac, json

SECRET = b"server-only-secret"

def sign_state(payload):
    body = base64.urlsafe_b64encode(json.dumps(payload, sort_keys=True).encode()).decode().rstrip("=")
    return body + "." + hmac.new(SECRET, body.encode(), hashlib.sha256).hexdigest()

def read_state(state):
    body, _, sig = state.partition(".")
    if not hmac.compare_digest(sig, hmac.new(SECRET, body.encode(), hashlib.sha256).hexdigest()):
        return None
    return json.loads(base64.urlsafe_b64decode(body + "=" * (-len(body) % 4)))

s = sign_state({"tool": "refund_order", "order_id": "ord_51", "amount": 49.0, "user": "ada", "exp": 1700000300})
print(s[:40] + "...")
print(read_state(s))
tampered = sign_state({"tool": "refund_order", "order_id": "ord_51", "amount": 4900.0, "user": "ada", "exp": 1700000300})
print(read_state(tampered.split(".")[0] + "." + s.split(".")[1]))

Mistakes with long-running work

The server doesn't wait for the user. With multi-round-trip requests, the request ends when input is needed. Code that tries to hold it open, and pause for the answer, brings back the very state the 2026 revision removed. Finish the request, and pick up from the state when the next one arrives.

requestState comes back from the client, so it isn't trustworthy. It looks like your own data, since you created it. But it has been through the client's hands, and it could have been changed. Sign it and check the signature, as in this lesson's example. Keep the amount and the user out of it unless they're signed too.

Send only what was asked for. A client subscribes to specific kinds of change. Sending others wastes its attention and may break it.

Old features linger. Sampling and roots are deprecated. You'll still see them in older servers, but don't build new ones on them.