---
title: "MCP: Elicitation"
slug: "mcp-elicitation"
category: "ai-agents"
tags: ["mcp", "ai-agents", "elicitation", "protocol", "capabilities", "security"]
status: "stable"
last_updated: 2026-08-14
summary: "MCP elicitation pauses a tool call via a retried multi-round-trip request to collect structured input (form mode) or out-of-band consent (URL mode), with accept/decline/cancel responses and real security implications."
related: ["[[ai-agents/mcp-protocol]]", "[[ai-agents/mcp-tool-design]]", "[[ai-agents/mcp-security]]", "[[ai-agents/mcp-servers]]", "[[ai-agents/prompt-injection-defense]]"]
---

## Overview

Elicitation is an MCP capability, added to the spec in 2025, that lets a server ask the user for structured input mid-operation. Instead of failing when a required value is missing, a server returns an `InputRequiredResult` carrying an `elicitation/create` request; the client renders a form from the supplied schema, and the caller retries the original request with the user's answer attached. This is the Multi Round-Trip Requests (MRTR) pattern introduced alongside the 2026-07-28 spec's stateless core, replacing the earlier mid-call push model. The 2025-11-25 revision added a second mode, URL mode, for sensitive interactions that must never pass through the client (see below). The capability is declared per request in `_meta`. For the framing it rides on, see [[ai-agents/mcp-protocol]]; for the trust boundary it crosses, see [[ai-agents/mcp-security]].

## Use elicitation for missing required input, not for chatty prompts

Elicitation fits the case where a tool cannot proceed without a specific value the server does not have: a target branch name, a confirmation, a choice among discovered options. It is a request-response interruption, not a conversation channel.

- Good: a deploy tool that discovered three eligible environments asks the user to pick one.
- Good: a destructive operation confirms intent before running.
- Bad: a tool that uses elicitation to walk the user through a multi-step wizard. Decompose that into separate tool calls instead.

Keep each elicitation to a single, well-scoped request. The user is interrupted; respect that.

## Send a flat JSON Schema for form mode; use URL mode for sensitive data

Elicitation has two modes. Form mode collects structured data in-band, validated against a `requestedSchema`. URL mode directs the user to an external URL for interactions that must not pass through the MCP client at all, such as OAuth flows or payment forms; the server never sees the data, only the user's consent to navigate.

For form mode, the schema is intentionally limited to a flat object of primitive properties (string, number, boolean, and enums), so any client can render it as a simple form without a full JSON Schema engine.

```json
{
  "method": "elicitation/create",
  "params": {
    "message": "Which environment should I deploy to?",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "environment": { "type": "string", "enum": ["staging", "production"] }
      },
      "required": ["environment"]
    }
  }
}
```

Do not nest objects or arrays. If the input is genuinely structured, collect it across several flat elicitations or move it into the tool's own arguments.

## Handle all three response actions

The client returns one of three actions, and the server must handle each:

- `accept`: the user submitted values; proceed with the returned `content`.
- `decline`: the user explicitly refused; abort the operation and report it cleanly.
- `cancel`: the user dismissed the request without answering; treat as no decision and do not assume a default.

A server that treats `decline` or `cancel` as `accept` with empty values will act on input the user never gave.

## Treat elicited input as untrusted, and never elicit secrets

Elicitation crosses the same trust boundary as any other user input. The values come back through the client, which may be automated or compromised.

- Validate elicited values against the schema again on the server; do not trust the client to enforce it.
- Never request passwords, API keys, or tokens through form mode elicitation; the spec forbids it. Route sensitive credentials through URL mode elicitation to a page the server controls, or through the transport's auth layer. See [[ai-agents/mcp-security]].
- Clients should show which server is asking and give the user a clear decline path, since a malicious server could use elicitation as a [[ai-agents/prompt-injection-defense|social-engineering]] surface.

## Related

- [[ai-agents/mcp-protocol]]
- [[ai-agents/mcp-tool-design]]
- [[ai-agents/mcp-security]]
- [[ai-agents/mcp-servers]]
- [[ai-agents/prompt-injection-defense]]
