Elicitation Support

[joe-credal]

Problem Statement

With Elicitation now supported in Claude Code, support in Claude.ai as well would help finally make this feature of the spec something MCP server developers could rely on.

Elicitation would enable significantly cleaner and more reliable user experiences for several workflows we're looking to implement - experiences that conversational interaction alone cannot match. Certain user inputs, such as confirming high-risk actions, benefit greatly from the structured, focused prompts that elicitation provides, rather than being included in open-ended dialogue.

Proposed Solution

Add the elicitation functionality of the MCP spec to Claude.ai.

Area

Protocol Support

Priority

High - Major improvement needed

[betsy]

would also love this

[liv-s]

this would be awesome!

[FangedParakeet]

Wow, this would make my day. Pretty please.

[rb0000]

Would be incredible if this existed

[whitford-olmst]

I don't see this as a nice to have as much as absolutely critical. Ambiguity is a huge issue that I frequently run into, and MCP Elicitation is the way to disambiguate. For example:

• "What's the weather in Paris?" --> Did you mean Paris, France | Paris, TX | Paris, ON ?
• "Prep for a Meeting with Guggenheim" --> No problem, but please confirm which Guggenheim you are talking about: Guggenheim Investments, Guggenheim Securities, Guggenheim Partners, The Guggenheim Museum.

Without MCP Elicitation, my options are to guess (which may have terrible repercussions), or just stop (which can feel like failure).

FWIW, I have tried using MCP Apps as an alternative to MCP Elicitation, but that didn't work because there is no mechanism to wait for an MCP App event like choosing an item from a list.

[alex-hodges-relativity]

This feature is a must-have for applications that adhere to strict compliance rules. It provides a very necessary human-in-the-loop mechanism that is essential for validation and auditing purposes.

[WubbbaLubbbaDubDub]

Strongly seconding this — with a request to make the ask url-mode-specific, because the OP's use case ("confirming high-risk actions") is exactly what URL mode, not form mode, is for.

The 2025-11-25 spec splits elicitation into:

• form mode — structured JSON-schema input through the client; explicitly forbidden for secrets, and not a secure out-of-band confirmation.
• url mode — the client opens a server-provided URL out-of-band; combined with URLElicitationRequiredError (-32042), a server can require a human to approve/authorize before a tool call proceeds and resume after. This is the "confirm a high-risk action" / human-in-the-loop primitive (and OAuth/3LO for connectors).

So whatever lands on Claude.ai, please advertise "elicitation": { "form": {}, "url": {} } and implement the url path — not bare "elicitation": {} (which the spec defines as form-only).

Two references:

• VS Code's Copilot MCP client already ships url mode end-to-end (advertises { form, url }, opens the URL via its opener service, handles the -32042 retry) — a working blueprint.
• So Claude.ai doesn't inherit it: Claude Code regressed here — it advertised { form, url } in 2.1.87, then narrowed to {} (~2.1.108), so url-mode now hard-fails with -32602 ([BUG] Claude CLI: URL-mode elicitation/create not supported — server-initiated OAuth flows fails with not supported error claude-code#48164, [BUG] URL-mode elicitation broken: client capability dropped from {form,url} to {} (~2.1.108); server elicitation/create mode:"url" rejected with -32602 claude-code#69555). The likely trigger was older Java-SDK servers crashing on the new capability keys, which was fixed server-side in Java SDK ≥ 0.18.0 — so advertising the full shape is safe.

Why it matters beyond chat: we run an MCP gateway and need url-mode + -32042 to deliver "require confirmation before a sensitive tool runs" as a single blocking, resumable step. Form mode can't carry that securely.

[benbloomorigamirisk]

I need this feature as a way for my MCP server to capture user inputs securely without exposing the data to AI Context.