A tool call usually runs in one shot: the model calls a tool, the server does the work, a result comes back. Elicitation is the exception — a way for a server to pause in the middle of that work and ask a person a direct question, through a simple form, before it continues. It’s one of the newer primitives in the MCP spec, and the one most directly aimed at “the server needs one more piece of information it has no business guessing.”
What elicitation actually is
When a server needs input mid-task, it sends an elicitation/create request back through the client: a short message explaining what it needs, plus a requestedSchema describing the shape of the answer. That schema is deliberately narrow — a flat object of primitive fields (strings, numbers, booleans, enums), not arbitrary nested JSON — specifically so a client can render it as a plain form instead of having to interpret an open-ended structure. Think a confirmation checkbox, a short text field, a dropdown of choices — not a whole document.
The response back to the server carries an action field with one of three values: accept (the person filled in the form and submitted it), decline (they saw the request and said no), or cancel (they backed out of the interaction entirely). Only accept comes with the actual content. That three-way split matters: a server that only checks for a truthy response and treats decline the same as cancel is already handling the primitive wrong.
How it’s different from sampling
MCP has two primitives that let a server reach back through the client mid-task, and it’s easy to conflate them. Sampling asks the client’s model for a completion — a summary, a draft, a classification. Elicitation asks the person for structured input — a confirmation, a missing parameter, a choice between options. Sampling exists so a server can borrow a model call without running its own inference. Elicitation exists so a server can ask for something only a human actually knows or should decide, like which of three matching accounts to act on, or whether to proceed with a change at all.
Both share a design principle worth naming: the request originates from the server, but the client is the one deciding whether it ever reaches the person, and in what form. Neither primitive lets a server put text directly in front of a user unmediated.
What a request can’t ask for
The spec is explicit that servers must not use elicitation to request sensitive information — passwords, API keys, full payment card numbers, anything of that shape. That’s a rule aimed at the interaction pattern, not a technical restriction the schema itself enforces, so it depends on servers actually following it and clients being willing to push back when a form asks for something it shouldn’t. If you’ve read our piece on tool annotations, this will sound familiar: another spec-level rule that describes intended behavior without a runtime mechanism forcing compliance.
In practice, that means a well-behaved elicitation form looks like “which of these two calendar events did you mean?” or “confirm: cancel this subscription?” — not “enter your current password to continue.” If you ever see the latter from an MCP server, that’s a server ignoring its own spec, not a normal use of the primitive.
Why this is the human-in-the-loop primitive
Elicitation is the protocol-level mechanism behind a pattern we covered more broadly in human-in-the-loop approvals for AI tool calls: an agent that can propose an action but has to pause and get a real answer before finishing it. Before elicitation, that pause-and-resume behavior was something each server had to invent for itself — some private out-of-band prompt, or just asking the model to relay a question in plain text and hoping the user’s reply gets parsed correctly. Elicitation makes it a first-class request with a defined schema and three unambiguous outcomes, so the pause is a protocol event a client can render consistently rather than text the model has to interpret.
It also means the pause happens at the right layer. The model doesn’t see the elicitation exchange as conversation it has to relay — the client handles rendering the form and returning the structured answer directly to the server. That keeps a confirmation step from becoming just another piece of text the model could misread, paraphrase, or skip.
What this means if you’re building a server
Reach for elicitation when a tool genuinely can’t proceed correctly without input only the user has — disambiguating between similar records, confirming a destructive action, or picking one option among several the tool discovered mid-call. Don’t reach for it as a substitute for good tool design: if you find yourself eliciting basic parameters a well-written tool schema should have collected upfront, that’s a sign the tool itself needs better inputs, not that every gap belongs behind a mid-call prompt. And never design a form that asks for a credential — if your server needs a secret, that belongs in server configuration or OAuth, not a runtime elicitation exchange. If you’re generating a server from an existing API with gate’s MCP server builder, elicitation isn’t something a generator adds for you — it’s a deliberate addition for a tool that genuinely needs a mid-call decision from a person, the same way sampling is a deliberate addition rather than a default.
Client support is still uneven, the same story as sampling: implementing elicitation well means a client has to render an actual form UI and decide what to do if a server sends a malformed or overly broad schema. Check what the client you’re building against actually supports before designing a tool flow around it.
The bottom line
Elicitation gives a server a structured way to pause and ask a person something specific — a confirmation, a disambiguation, a small missing fact — without routing the question through the model as free text. It’s deliberately narrow: flat forms only, no sensitive fields, and the client stays in charge of whether the prompt ever reaches the user. That makes it a good fit for the handful of moments a tool call genuinely needs a human answer, and a poor fit for anything else. See our guide to MCP’s primitives for where it sits alongside tools, resources, and prompts.