MCP Elicitation: When a Server Asks the User

Status in the 2026-07-28 spec: core (optional client feature)

Elicitation is the part of the Model Context Protocol (MCP) that lets a server ask the user for more information mid-request. The server explains what it needs. The AI app (the client) shows the user a form or a link, and the answer goes back to the server.

As of October 2026, elicitation is the only client feature in the 2026-07-28 specification that is not deprecated. Roots and Sampling, the other two, are on their way out. This page explains how elicitation works now, what changed, and where teams go wrong.

Why elicitation exists

Many real tasks need a human decision in the middle. A booking tool may need a date. A deployment tool may need a "yes, go ahead". A server that connects to a third-party service may need the user to sign in to that service.

Without elicitation, the server has two bad options. It can fail and make the AI guess, or it can ask the model to relay the question in chat. Elicitation gives the server a structured, visible way to ask the user directly, while the client stays in control of what is shown. The elicitation page of the spec says this lets "clients maintain control over user interactions and data sharing."

How elicitation works in 2026-07-28

The 2026-07-28 spec made MCP stateless. Servers can no longer send their own requests to the client mid-call. The patterns overview says plainly that "Servers MUST NOT initiate JSON-RPC requests."

Elicitation now rides on Multi Round-Trip Requests (MRTR):

1. The client sends a request, such as tools/call.
2. The server replies with a result whose resultType is input_required. Inside, an inputRequests map holds one or more elicitation/create requests.
3. The client shows the question to the user and collects the answer.
4. The client retries the original request with a new ID, adding the answers in inputResponses and echoing any requestState the server sent.
5. The server finishes the work and returns a normal result.

According to the MRTR page, only tools/call, prompts/get and resources/read may return an input-required result.

Declaring the capability

A client that supports elicitation declares it on every request, inside _meta. It lists the modes it handles, form, url or both. An empty elicitation object means form mode only. Servers must not send a mode the client did not declare.

Example: a form-mode request

This is the form-mode example from the spec. The server places it inside inputRequests:

{
  "method": "elicitation/create",
  "params": {
    "mode": "form",
    "message": "Please provide your GitHub username",
    "requestedSchema": {
      "type": "object",
      "properties": {
        "name": { "type": "string" }
      },
      "required": ["name"]
    }
  }
}

The client returns the user's answer inside inputResponses on the retry:

{
  "action": "accept",
  "content": { "name": "octocat" }
}

Form mode vs URL mode

Form schemas are kept simple on purpose. The spec says nested objects and other advanced JSON Schema features "are intentionally not supported to simplify client user experience."

URL mode sends the user to a page the server controls. When the user agrees, the client replies accept. That only means the user consented, not that the task is done. The server checks on the retry whether the out-of-band step finished.

Three possible answers

Every response carries an action:

• accept: the user submitted (form mode includes content).
• decline: the user said no.
• cancel: the user closed the dialog without choosing.

The spec says servers "MUST handle cases where the user declines or cancels."

What changed across spec versions

In 2025-11-25, the server sent elicitation/create as its own JSON-RPC request. Under 2026-07-28 that is gone. The changelog explains that servers which need to track an elicitation across retries now "encode their own identifier in requestState." The wider shift is covered in why MCP became stateless.

Common mistakes

• Asking for secrets in a form. The spec says servers "MUST NOT use form mode elicitation to request sensitive information such as passwords, API keys, access tokens, or payment credentials." Use URL mode.
• Using URL mode to sign users in to your own server. URL mode is for third-party access. Sign-in to the MCP server itself belongs to MCP authorization.
• Trusting requestState blindly. It passes through the client. The MRTR page says servers must treat it as attacker-controlled and protect it (for example with HMAC) if it affects access or business logic.
• Putting personal data in the URL. Servers must not include credentials or personal information in a URL-mode link, or send a pre-authenticated URL.
• Skipping the identity check. The spec describes a phishing attack where one user tricks another into finishing a sign-in. The server must confirm that the person who opens the URL is the person who started the request.
• Treating "accept" in URL mode as "done". It only means the user agreed to open the link.

Who needs to care

If you run an AI app, elicitation is how third-party servers will ask your users things. Check that your client shows which server is asking, as the spec requires. If you build servers, elicitation replaces ad-hoc "please tell the assistant" text with a clean, auditable step. The MCP security checklist covers the related approval controls.

Next step

Elicitation sits on top of the multi-round-trip pattern, so read MCP multi-round-trip requests explained next. To build it hands-on, try Lesson 18 of Learn MCP, or browse the rest of the MCP specification reference.

Frequently asked questions