LLM Best Practices

MCP: Elicitation

3 min read

View markdown source

Overview

Elicitation is an MCP capability, added to the spec in 2025, that lets a server ask the user for structured input in the middle of an operation. Instead of failing when a required value is missing, a server sends elicitation/create, the client renders a form from the supplied schema, and the user supplies the value before the tool continues. The capability is negotiated at initialize time. For the framing it rides on, see mcp-protocol; for the trust boundary it crosses, see 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; clients render only primitives

The server sends elicitation/create with a message and a requestedSchema. 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.

{
  "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 elicitation. The spec explicitly discourages eliciting sensitive credentials; route those through the transport’s auth layer instead. See 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 social-engineering surface.

Graph View

Backlinks