AI agents often get stuck for a simple reason: the server needs information the agent does not have. A payment tool might need a shipping address. A database tool might need the user to confirm which workspace to query. A deployment tool might need approval before touching production.

MCP elicitation is the protocol feature that lets an MCP server ask for that missing input while a workflow is already running. Instead of failing the tool call or inventing a value, the server can pause, request structured input from the client, and continue once the user responds.

The core idea

Elicitation is human-in-the-loop input for MCP workflows.

In a normal MCP tool call, the client sends arguments to a server and the server returns a result. That works when the agent already has every required field. Elicitation handles the cases where the server discovers a gap only after execution starts.

The important distinction is direction. Tools are client-to-server requests. Elicitation is a server-to-client request that happens inside an active client request. The server is not randomly interrupting the user. It is asking for information tied to something the user or agent already initiated.

That makes elicitation useful for three patterns:

  • Missing fields, such as account IDs, regions, file names, or dates
  • Confirmation gates before risky actions
  • Choice points where the server knows the valid options better than the agent does

If tools are how an agent acts, elicitation is how a server asks, “Before I act, can you clarify this?”

How it works

At a high level, the flow looks like this:

  1. The client calls an MCP server feature, often a tool.
  2. The server starts processing the request.
  3. The server realizes it needs input from the user.
  4. The server sends an elicitation request back through the client.
  5. The client presents that request in its own interface.
  6. The user accepts, rejects, or provides the requested values.
  7. The server resumes or exits based on the response.

The request is structured. A server does not send a vague text prompt and hope the model formats the answer correctly. It describes what it needs, often with a schema for fields like strings, numbers, booleans, or enums. The client can turn that schema into a form, a confirmation dialog, a chat question, or another UI pattern.

For example, a cloud deployment server might receive a request to deploy an app, then ask:

{
  "method": "elicitation/create",
  "params": {
    "message": "Choose the production region for this deployment.",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "region": {
          "type": "string",
          "enum": ["us-east-1", "us-west-2", "eu-west-1"]
        }
      },
      "required": ["region"]
    }
  }
}

The client can render a dropdown instead of leaving the agent to guess. The server gets back a constrained value, not a paragraph.

Why it matters for AI agents

Elicitation makes MCP workflows safer and less brittle.

Without elicitation, developers have three bad options. They can require every parameter up front, which makes tools hard to use. They can fail when anything is missing, which makes agents feel fragile. Or they can let the model infer missing details, which is risky when money, customer data, infrastructure, or production systems are involved.

Elicitation gives the server a better option: ask at the moment the missing information becomes clear.

That matters because MCP servers often sit closest to the real system. The server may know the valid Stripe accounts, the available database schemas, the list of deploy targets, or the exact permissions attached to a user. The agent may only know the user’s intent. Elicitation lets the system with the best context ask the user for a precise decision.

It also creates a cleaner approval boundary. A client can allow low-risk resources to be read automatically, allow simple tools to run without interruption, and require elicitation for sensitive actions. That is a better user experience than approving every call or trusting every call.

Elicitation in practice

Good elicitation design is specific. A server should not ask the user to re-explain the whole task. It should ask for the smallest missing decision.

Weak request:

What should I do next?

Better request:

This action will send 214 emails. Approve sending now?

Better still, with structure:

{
  "approve": true,
  "send_window": "now"
}

For developers building MCP servers, the design rule is simple: use elicitation when the server needs user intent, consent, or a value that should not be guessed.

Do not use it for every optional parameter. Too many prompts turn an agent workflow into a wizard. Default low-risk settings where possible. Ask only when the answer changes safety, cost, correctness, or access.

Elicitation pairs especially well with MCP auth. Auth answers “who is allowed to do this?” Elicitation answers “does this user want to do this specific thing right now?” Production agents need both.

FAQ

Q: Is elicitation the same as asking the model a follow-up question? A: No. A model follow-up is conversational. MCP elicitation is a protocol-level request from the server to the client for structured user input. The client may show it as a chat question, but the server receives a typed response.

Q: Can an MCP server prompt the user whenever it wants? A: No. Elicitation is tied to an active workflow. Current MCP direction keeps server-initiated requests scoped to work the user or agent already started, so users are not interrupted out of nowhere.

Q: When should I add elicitation to an MCP server? A: Add it when the server must ask for consent, resolve ambiguity, choose between valid options, or collect a required value that should not be inferred by the model.

Q: Does every MCP client support elicitation? A: Not necessarily. Elicitation is a capability clients need to expose. If your server depends on it, document the requirement and provide a safe fallback for clients that cannot present user prompts yet.