MCP Elicitations definition
In the Model Context Protocol (MCP), elicitation is a mechanism that lets a server pause partway through a task and request structured input or confirmation from the user through the client, then continue once a response arrives. It is how a server asks for a missing parameter, an approval, or a choice without abandoning the work in progress.
Elicitation in the Model Context Protocol is the server's ability to stop mid-task, ask the person a structured question, and resume with their answer. It turns a one-shot tool call into a conversation with a checkpoint in it. For agents that write to structured content, that checkpoint is where a human decides: in Sanity, an agent can draft a document and then elicit approval before it publishes, so the edit reaches the Content Lake only with a person's consent.
Elicitation in the Model Context Protocol is a request that travels backward, from the server to the user, in the middle of a task. Normally an MCP server receives a tool call from a client, does the work, and returns a result. Elicitation interrupts that one-way flow: the server sends a structured request describing what it needs, the client presents it to the person, and the person's answer comes back so the server can finish.
The important word is structured. An elicitation is not free-text chat. The server describes the shape of the answer it expects, such as a boolean confirmation, a choice from a fixed set, or a small set of named fields, which means the client can render a real interface (a checkbox, a dropdown, a form) rather than hoping the user types something parseable. The server gets back data it can act on directly instead of prose it has to interpret.
The user, not the model, is the one answering. Elicitation exists so a human can be inserted into an otherwise automated sequence at the exact moment their judgment is needed, which is a different thing from the model asking itself a question or guessing a sensible default.
Elicitation pairs with MCP Tasks because a task can run long enough that stopping to ask a person is practical. A task in the Model Context Protocol is a long-running unit of work that the server tracks in the background rather than completing inside a single request and response. Short calls return in milliseconds and there is nowhere sensible to put a question. A task that runs for minutes has room for one.
Put together, the pattern looks like this. The client starts a task. The server works until it hits something it cannot decide alone. The server raises an elicitation and the task moves into a waiting state. The client surfaces the question to the user, who answers (or declines, or cancels). The server receives the response and the task resumes from where it paused, finishing with the user's input folded in.
The waiting state is what makes elicitation workable rather than disruptive. Without tasks, a server that needs human input has to either block a request open or fail and ask the client to start over with more arguments. With tasks, the job keeps its place in line while a person answers, which matters most when the earlier steps were expensive to compute.
Elicitation is used for three recurring situations, all of which share the same shape: the server has enough information to start but not enough to finish correctly.
The first is a missing parameter. A user asks for something underspecified, such as scheduling a post without saying when, and rather than inventing a time the server elicits the one value it lacks. This is more precise than rejecting the call, because the server asks for exactly the field it needs instead of making the model reconstruct the whole request.
The second is confirmation before a destructive or irreversible action. Deleting records, sending an email to a list, pushing a change to production, or publishing something public are all actions where an agent being ninety percent sure is not good enough. Elicitation puts an explicit yes or no in front of the step, and a decline is a legitimate answer that the server must handle rather than route around.
The third is choosing between options. When the server finds several valid matches, such as three customer records with the same name or two possible target environments, it can elicit a selection instead of picking one and hoping. The user sees the candidates and chooses, and the ambiguity is resolved by the person who actually knows the answer.
Elicitation matters for content agents because writing to a content repository is the step that becomes visible to other people, and visibility is hard to take back. An agent that reads content can be wrong quietly. An agent that publishes a product page, changes a price, or pushes a localized string to a live site is wrong in public, which is why the write path is the natural place to require a human answer.
Sanity is the AI Content Operating System, the intelligent back end for companies building AI content operations at scale, and the primitives that make elicitation useful sit in that back end rather than in the agent. Content is stored as structured documents in the Content Lake, so an agent's proposed change can be expressed as a specific patch to specific fields rather than an opaque blob of text. That specificity is what makes an elicited approval meaningful: the question put to the person can name what is about to change and where, and Roles & Permissions still govern what the operation is allowed to do even after the person says yes.
The practical pattern is an agent that drafts freely and elicits sparingly. Let it create and revise drafts without interruption, because drafts are cheap to discard, then raise an elicitation at publish, at bulk operations, and at anything that touches a production release. Governance improves because the interruption lands where the consequence is, not on every call.
Elicitation is different from a question-asking tool because the request originates with the server during execution, while a tool call originates with the model before execution. A server can expose an "ask_user" tool, and the model may or may not choose to call it. With elicitation, the server decides that input is required and the work does not proceed until the client returns an answer.
That difference matters for anything you need to be reliable. A guardrail that depends on the model remembering to invoke it is a suggestion. A guardrail the server raises itself, as a condition of completing the task, is closer to a control. If a publish step must have human approval, the approval request belongs on the server side of the boundary where it cannot be skipped by a model that decided it was confident.
The second difference is in the response. Elicitation defines the schema of the answer, so what comes back is typed data the server can validate, and the client can decline or cancel as a distinct outcome from answering. A free-text reply to a tool call is a string somebody still has to parse, and "no" expressed in prose is easier to misread than a boolean set to false.
Discover More with Sanity
Now that you've learned about MCP Elicitations, why not start exploring what Sanity has to offer? Dive into our platform and see how it can support your content needs.
Last updated: