Topic 4: User interaction

Why a server needs to ask, and how it asks now

Some tools cannot finish with only the model's arguments. create_note should check with Nare before saving a note that looks like a duplicate. An import from Zotero needs Nare's Zotero API key, which the model must never see. Both need a person, in the middle of a call.

Elicitation is MCP's way for a server to ask the user something during a request. It has two modes:

• Form mode: the server sends a message and a small flat JSON Schema; the client renders a form; the answer comes back as data.
• URL mode (added in 2025-11-25): the server sends a message and a URL; the client asks the user for consent and opens the URL in a browser; what the user does there never passes through the client.

How the question travels changed in 2026-07-28. Before, the server opened its own request back to the client (elicitation/create) while the original tools/call was still pending: a server-initiated request over a back-channel. The stateless 2026-07-28 revision removed that back-channel. Instead, the server returns an InputRequiredResult (resultType: "input_required") carrying inputRequests (what it needs) and an opaque requestState (where it was). The client gets the answers and retries the same request with inputResponses and the echoed requestState. This pattern is called Multi Round-Trip Requests (MRTR, SEP-2322). Every leg is an ordinary client-to-server request, which is what lets any replica behind a load balancer handle any leg.

The Python SDK hides the difference behind one server API and one client API. On the server, you hang a question on a parameter with a resolver; the SDK picks the transport from the negotiated protocol version. On the client, you register one elicitation_callback; the SDK feeds it from either era and, on 2026-07-28, runs the retry loop for you.