MCP Elicitation Explained: How Servers Ask Users for Input

AI agents that stop and ask instead of guessing — that's what elicitation makes possible. MCP elicitation is the mechanism that allows an MCP server to pause a running task, surface a targeted question to the user, and wait for an answer before continuing. It sounds simple, but it fundamentally changes how capable and trustworthy AI agents can be.

What Is MCP Elicitation?

Elicitation is a feature in the MCP June 2025 specification that gives servers a standardized way to request additional input from users during a task. Think of it like a confirmation dialog — but one that can be triggered at any point in a workflow, carry a specific schema for the expected response, and integrate cleanly with the host client's UI.

In plain terms: you ask your AI assistant to create a Jira ticket. The assistant invokes the Jira MCP server. Halfway through, the server realizes it doesn't know which project to put the ticket in. Before elicitation, it would either guess, use a default, or throw an error. With elicitation, it sends you a structured question — "Which project key should I use?" — waits for your reply, then completes the task correctly.

That's elicitation. It turns one-shot commands into a genuine conversation between the user and the server — without requiring you to anticipate every detail upfront.

The Problem Elicitation Solves

MCP servers are designed to take action: they call APIs, write files, create records, send messages. But real workflows are messy. Context is missing. Ambiguities pile up. And when a server hits an ambiguity, its options used to be brutally limited.

Before Elicitation

Without elicitation, a server in an unknown state had only a few paths:

• Guess. Use a default value and hope it's right. Often it isn't.
• Fail silently. Return an empty result or a vague error with no useful signal.
• Fail loudly. Throw an exception that breaks the entire task chain.
• Ask the LLM. Let Claude try to infer the answer from conversation history — unreliable at best.

None of these are great. Guessing leads to wrong actions. Silent failures are hard to debug. Loud failures interrupt everything. And asking the LLM to infer missing data is just a slower, more confident form of guessing.

After Elicitation

With elicitation, the server can interrupt its own execution, send a structured question to the client, and receive a validated response before proceeding. The flow looks like this:

1. User initiates a task via Claude
2. Claude calls the MCP server's tool
3. The server detects it needs more information
4. The server sends an elicitation/create request to the client
5. The client displays a UI prompt to the user
6. The user provides the missing data
7. The client returns the response to the server
8. The server continues and completes the task

The user experience is smooth. The agent gets the information it needs. And crucially, nothing proceeds on a guess.

How Elicitation Works Technically

The elicitation mechanism is built on a simple JSON-RPC message — elicitation/create — that a server sends to the client. What makes it powerful is the requestedSchema field: the server specifies exactly what shape of data it needs, and the client can render an appropriate UI form from that schema.

Here's what a real elicitation request looks like:

{
  "method": "elicitation/create",
  "params": {
    "message": "Which Jira project should I create this ticket in?",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "project_key": {
          "type": "string",
          "description": "The Jira project key (e.g. ENG, INFRA)"
        }
      },
      "required": ["project_key"]
    }
  }
}

Breaking it down:

• message — the human-readable question shown to the user
• requestedSchema — a JSON Schema object describing the expected response shape
• required — fields the server needs before it can continue

The client receives this, renders an appropriate input UI (a text field, a dropdown, a toggle — depending on the schema type), and sends the user's response back. The server then validates it against the schema and continues execution.

This schema-driven approach is what separates elicitation from a simple free-text prompt. The server gets structured, validated data — not a freeform string it has to parse.

Real-World Use Cases

Elicitation isn't a niche edge case — it covers a broad range of everyday agent scenarios.

1. Disambiguation

Your calendar server detects two contacts named "Alex Johnson" in your contacts. Instead of picking one at random, it elicits: "Which Alex Johnson do you mean? (alex.j@company.com or alex.johnson@personal.com)". The agent proceeds only after you confirm.

2. Missing Required Parameters

A GitHub MCP server needs to create a pull request but wasn't told the target branch. It elicits a branch name with a dropdown showing your repo's active branches. You select main, and the PR is created correctly.

3. Confirmation Before Destructive Actions

A file management server is about to delete 47 files matching a pattern. Rather than proceeding silently, it elicits confirmation: "I'm about to permanently delete 47 files in /archive/2023/. Confirm?" with a boolean yes/no schema. This is the AI equivalent of "Are you sure?"

4. Permission Escalation

An email server can read your inbox but needs elevated access to send on your behalf. It elicits explicit permission mid-task rather than assuming it has blanket authorization. This creates a natural, user-driven consent layer.

5. Preference Collection

A document generation server is building a report but doesn't know which output format you want. It elicits a choice between PDF, DOCX, and Markdown. Simple, but it prevents the frustrating cycle of "wrong format, do it again."

How Elicitation Differs from MCP Prompts

If you've read about MCP servers before, you know they expose three types of capabilities: tools, resources, and prompts. It's easy to confuse elicitation with prompts — they both involve asking things. But they're fundamentally different.

MCP Prompts are pre-defined templates registered by the server at startup. A user or client browses available prompts, selects one, fills in its parameters, and gets a response. Prompts are static: their structure is fixed before any task begins. They're more like forms you fill out to start a workflow.

Elicitation is dynamic and reactive. It occurs inside an already-running task. The server didn't know it would need this information when the task started — it discovered the need mid-execution. Elicitation is the server saying "I've hit something I can't resolve without you. Help me out." Prompts can't do that.

Another key difference: prompts are user-initiated. Elicitation is server-initiated. That's a meaningful distinction for both UX design and security.

Security Considerations

Elicitation is powerful, but that power cuts both ways. A server that can interrupt any task to ask the user for input is a server that could, in theory, ask for the wrong things.

The Phishing Risk

A malicious MCP server could abuse elicitation to fish for sensitive information. Imagine a compromised server that elicits: "Please enter your API key for verification." Without proper client-side safeguards, a user might comply — they're already mid-task, they're in a trusted-looking UI, and the request looks plausible.

The MCP spec is aware of this. The design puts two key controls in place:

Client-Side Controls

Clients must explicitly opt into allowing elicitation. A server cannot elicit input from a client that hasn't declared support for it. This means:

• Client developers decide whether to implement elicitation UI at all
• Users can be shown which server is making the request — not just "an AI is asking"
• Clients can impose rate limits or require user approval per-server

Schema-Driven Validation

Because elicitation uses JSON Schema to define expected responses, clients can analyze what a server is asking for before displaying the prompt. A client could warn users if a server asks for a field called password or secret. This is a defense layer that plain text prompts can't offer.

The bottom line: elicitation is safe when clients implement it responsibly. As with most MCP security topics, the June 2025 spec sets the rules, but client implementations determine whether those rules are actually enforced.

What This Means for Agent Builders

If you're building MCP servers or integrating MCP into your product, elicitation changes your design options significantly.

Previously, you had to collect all possible inputs upfront — either in the tool's parameter schema or in the initial user prompt. This led to either overly complex tool signatures (every possible optional parameter listed) or fragile agents that broke on edge cases.

With elicitation, you can build servers that start with minimal input and ask for more only when needed. This matches how real workflows actually work: you rarely know everything you need before you start. You discover it along the way.

Concretely, elicitation enables:

• Progressive disclosure — ask only what's needed, when it's needed
• Human-in-the-loop checkpoints — pause before irreversible actions
• Graceful handling of ambiguity — resolve forks in the workflow without failing
• Dynamic consent flows — request permissions at the moment they're required

For a deeper look at how this fits into the broader MCP evolution, see our MCP version history guide and the structured tool outputs explainer — both of which were introduced around the same time and work well alongside elicitation.