MCP prescribes a standard way for AI applications to connect with external tools, but ordinary tool calls rest on a hidden assumption: by the time the client issues a request, the server already has every parameter needed to complete the task. Real-world business is rarely that tidy. Only after a tool has queried data might it discover that the user needs to choose a connecting flight, fill in missing business details, or authorize access at a third-party system.
The trouble is that the gap is detected by the remote server, while the interface lives in the user-facing host. The server cannot pop up its own window, nor can it assume the model will reliably reconstruct the right question from an error message. MCP therefore needs a reverse channel: the server pauses the current task and delivers a structured question to the user through the client; once the user responds, the result travels back to the originating server, and the task resumes with its existing state intact. This design is elicitation.
What needs solving here is more involved than just showing an extra
dialog. After the server issues a request, the current task must stay
paused where it is. The user may supply information, decline, or cancel;
the client delivers the result back, and the server picks up from where
it left off. MCP must define uniform message formats and return paths
for all these actions. MCP added the precursor to the form mode in the
2025-06-18
spec, then introduced the URL mode in the 2025-11-25
version. The two modes are separate because ordinary preferences,
account authorization, and payment credentials cannot travel along the
same data path.
This also determines the central concerns for understanding elicitation: why the server cannot just ask the model to casually follow up with another question, why form and URL must stay separate, why the server’s business confirmation cannot substitute for host-level permission, and how the client picks up a paused task. Cloudflare’s addition of client-side handling in 2026 is merely a new milestone where this protocol design meets real products.
Suppose the user asks an agent to book a flight to Tokyo for next week. The travel server responsible for searching flights first finds available options, only then discovers it needs the user to choose a connecting flight; further into processing discounts, it needs the user to authorize a frequent-flyer account at a third-party system; at the payment stage, it must enter an independent payment flow. A connection preference, an account authorization, and payment information cannot all be packed into the initial tool call.
The server here is an external tool within a Model Context Protocol (MCP) connection. The AI application the user actually operates is the host; the client inside the host maintains the connection to this server. The server can query flights and calculate prices, but it has no access to the host’s interface and cannot decide the host’s global permissions on its own. Once it detects a gap, it needs a standard way to hand the question back to the client.
Without elicitation, the server can usually only return an error and let the model guess the question behind it before re-asking the user; or return a link with no clear purpose; or, worse, have every server build its own callback for every different client. The first two approaches risk breaking the task — the model may need to re-plan or even lose the state it already fetched. The third forces each product pair to maintain a private interface.
Elicitation lets the server issue a structured request and wait in place. Once the user answers, the client sends the result back to the originating server, which continues processing with its existing state. The protocol thus defines the full round-trip from pause to resume, no longer just the initial tool call.
MCP arranges two data paths for these requests. Which one to use depends first on what kind of information the user is giving up, and whether that information may travel through the MCP client.
form collects non-sensitive structured input. The server can ask the client to present an input field, a set of options, or a confirmation button; after the user fills it in, the data returns to the server through the MCP client. Cloudflare began supporting server-initiated form requests as early as August 5, 2025. The protocol also draws a clear boundary: passwords, API keys, access tokens, and payment credentials must never be solicited through form.
For sensitive flows such as OAuth or payment, the server uses URL. The client first presents an external link to the user; once the user agrees, the browser or another external environment opens a secure page. Confidential information stays within the third-party flow and never enters the MCP client or the model’s context. An accept here only means the user is willing to open the link — it does not mean OAuth has been granted, an account has been linked, or a payment has been made. MCP client-to-server authentication and third-party OAuth are also two independent processes.
The three pauses in the diagram may look identical, but the data flows to different destinations. The connection preference returns to the travel server via form; the frequent-flyer account completes OAuth on an external page; the payment system still guards payment itself. A client that merely “shows a dialog” without explaining the source and the data destination has not fully implemented this protocol capability.
The same confirmation button carries different authority at different layers. The allow/ask/deny rules the host sets for tool calls are an enforcement checkpoint protecting the local environment. OpenCode’s permission mechanism and Claude Code’s hooks both place these checks on the host side. Third-party OAuth and payment are executed by external business systems. The form or URL request the server itself issues can only handle its own business process.
| Mechanism | Initiated by | What the user decides | Where the response goes | Enforced by |
|---|---|---|---|---|
| Local question | Model or local environment | Requirement, preference, or ambiguity | Local environment | Not an enforcement checkpoint |
| MCP form / URL elicitation | External MCP server | Missing input or consent to redirect | The MCP server that issued the request | Server business logic |
| Host tool permission | Host policy | Whether a given tool call may execute | Local permission engine | Host environment |
| Third-party OAuth / payment | External business system | Identity authorization or payment confirmation | Independent security service | Third-party system |
Suppose a server uses form to ask whether the user confirms file deletion. The user clicking “approve” only satisfies the server’s business confirmation. Before actually executing the deletion, the host can still block the tool under its own permission rules. Conversely, the user accepting an OAuth URL only agrees to leave the current interface to authorize an identity — it does not grant the local tool new execution rights.
Looking only at dialog appearance, it is easy to mistake “I’m willing to continue this business process” for “I authorize the system to perform any action.” The client must make clear who is making the request and what its scope is; it cannot erase these distinctions with a generic “Allow” button.
MCP has already defined the reverse request, but the protocol’s existence does not mean users can actually complete that interaction. On July 13, 2026, Cloudflare updated its Agent SDK, enabling Cloudflare Agents to act as MCP clients that handle form and URL requests. This update does not change elicitation’s design; it only shows that the implementation gap has shifted from “can the server ask” to “can the client correctly handle the request and resume the task.”
When client and server establish a connection, they declare which optional capabilities each supports. If the client has not declared elicitation, the server should not send it such requests. Therefore, being able to call MCP tools is not the same as being able to handle a question that arrives mid-execution from the tool.
As of mid-2026, there is direct evidence of form and URL support in VS Code’s URL support and form UI update, GitHub Copilot Chat, Kiro handling both modes, Claude Code CLI, and Codex. Cursor explicitly supports form, though public material is not yet sufficient to confirm URL support. OpenCode’s implementation at the time also did not declare elicitation. Claude Code CLI supporting it does not mean Claude Desktop or Cowork has the same capability.
Cloudflare’s update also clarifies another common point of confusion.
The server-side SDK provides elicitInput() for developers
to conveniently issue requests; after configuring
configureElicitationHandlers({form,url}) on the client
side, what the client receives is still a standard MCP
elicitation/create request, not a Cloudflare-proprietary
protocol.
The handler also does not automatically become a complete user interface. The host still needs to tell the user which server is asking, display URLs safely, distinguish accept, decline, and cancel, route the result back to the correct request, and resume the original task after the operation finishes. MCP defines what data travels over the wire; it does not define where buttons go or what the prompt text says. The gap in client experience lives in the distance between protocol messages and actual interaction.
Other agent protocols also have “stop and wait for a person” designs, but each pauses a different object. AG-UI connects an agent backend to a user frontend; its interrupt/resume is closest to MCP elicitation, but it covers interactions between the agent and the frontend. ACP connects a coding agent to an editor and concerns whether local tools may execute. A2A coordinates remote agent tasks and defines states like input-required and auth-required, but provides no general elicitation form or result format.
Microsoft’s human-in-the-loop and OpenAI’s MCP approval primarily intercept tool execution in the host or runtime. UCP and AP2 handle commercial and payment authorization. All of these mechanisms wait for the user, but a similar appearance does not make them interchangeable.
When a server can proactively reach out to a person, new misuse emerges: developers may turn every uncertain item into a dialog, reducing the agent to a confirmation machine. elicitation should be reserved for information gaps that appear only after the tool has started, security flows that must be completed externally, and choices that significantly alter the business outcome. Items for which a safe default can be inferred, low-risk reads, and reversible operations should still be handled by the agent itself.
The transport details of the 2026 candidate specification may still change, but the need for a server to request input mid-execution will not disappear. To judge whether a client genuinely supports elicitation, look at four things: can the user see which server is asking; does the data travel the appropriate form or URL path; does the interface accurately express accept, decline, and cancel; once handled, can the original task resume with the correct state. Calling a human back is not hard. The hard part is putting them in the right place to make a decision within the right scope, and then letting the task carry on.