Elicitation Support Matrix
Advertising a capability is not the same as it working. This matrix records what
real MCP hosts do when exercised with Elicitly’s elicit_doctor tool, whose report
separates the two on purpose: support is what a host advertises (derived
from the initialize handshake), while probes.elicitationForm.verdict is what
actually happened when elicitation was exercised live. A Form cell is
yes when the probe verdict is working, and broken when the host advertised
the capability but the live probe contradicted it — an auto-answered “no”
faster than a human plausibly could (advertised_but_autocanceled) or an
outright error (unsupported). A cell reading advertised means the handshake
claims the capability but it hasn’t been exercised live yet — elicit_doctor
probes form mode only, so URL mode stays advertised until verified against
the Pro server’s native URL push.
The same host can appear in more than one row: support can differ by
transport. Claude Code renders form elicitation from local stdio servers yet
auto-cancels the identical request from a remote (streamable-HTTP) server
before anyone sees a dialog. It can even differ by attachment path within a
transport — Claude Desktop runs a different embedded MCP client for
config-file servers, desktop extensions (MCPB), and remote connectors — so
rows note how the server was attached where the distinction has been measured. (ChatGPT Desktop briefly looked like a second
case — every remote form accept errored — until the probe’s reason field
revealed the failure was Elicitly’s own runtime bug, since fixed; the
corrected row and both generations of evidence are below. The matrix corrects
itself when the evidence does.)
The MCP Apps column covers the
MCP Apps extension
that elicit_display renders through. It is read
straight from each row’s archived handshake (io.modelcontextprotocol/ui under
capabilities.extensions): advertised when the host claims it, upgraded to
yes once an MCP App has been seen rendering there, and no when it isn’t
claimed — or broken when a host advertised it but, exercised, didn’t deliver
what the spec promises the view (Goose Desktop drops the tool result’s _meta;
see its row). Unlike elicitation there is no live probe: these cells come from
exercising elicit_display in each host.
This matrix tracks elicitation capability, not connection reliability — the two can diverge. ChatGPT/Codex leads on elicitation (both modes working) yet its MCP OAuth-refresh recovery is fragile enough to drop a previously-working connection; Claude is the reverse. That axis lives in Troubleshooting, not here.
Two columns exist to keep old claims honest: Protocol is the MCP revision
the handshake negotiated — watch it to see when hosts start speaking
2026-07-28 natively — and Captured is when the fingerprint was taken;
the older a row, the more suspicion it deserves. Each row’s
Notes & evidence disclosure holds the context and links the verbatim
elicit_doctor output it was derived from, archived unedited.
| Host | Version | Transport | Protocol | Form | URL | MCP Apps | Captured |
|---|---|---|---|---|---|---|---|
| unknown | 2026-07-28 | no | no | yes | 2026-10-08 | ||
Notes & evidenceConnectors now run a new embedded client, Anthropic/ClaudeAI 1.0.0 (the same one Claude Desktop's connectors switched to), which negotiates 2026-07-28 and advertises MCP Apps (io.modelcontextprotocol/ui) but no elicitation at all. elicit_display renders inline, following the host theme. The 2026-08-23 row came from the earlier embedded claude-code 2.1.241 client in Cowork, which advertised elicitation.form but never rendered it (advertised_but_unanswered, anthropics/claude-code#88901); that claim is gone now rather than fixed, so Form moves from broken to no. hostVersion is unknown: the web app carries no user-facing version. Captured 2026-10-08 via the contribute-fingerprint prompt against staging (server ce9e689). Verbatim fingerprint: Superseded evidence (earlier versions of this host): | |||||||
| 1.50.0 | 2026-07-28 | yes | no | no | 2026-09-14 | ||
Notes & evidenceForm works over remote HTTP, and fast: probe accepted in 3.3s with a real dialog, against the production hosted server (57527be) over an authenticated streamable-HTTP session (extension configured in ~/.config/goose/config.yaml). The embedded client identifies as goose-cli 1.50.0 — Goose is its own MCP client, no wrapper — and negotiates 2026-07-28 natively, the first CLI row with a non-null Protocol cell. It also still advertises sampling and roots (both deprecated in 2026-07-28), the only host in the matrix advertising sampling. URL mode is not advertised, and the fallback behaves as designed: a live elicit_selection round-trip (selection → hosted review page from the tool result → elicit_await → elicit_result) completed cleanly, with the agent correctly re-polling elicit_await after a pending return. Contributed via elicit_doctor share: true; a second passive share added the product version the first report omitted — the report's clientInfo can't name the product around it, and for Goose client and product happen to coincide. Verbatim fingerprint: | |||||||
| 1.50.0 | 2026-07-28 | yes | no | broken | 2026-09-14 | ||
Notes & evidenceSame verdicts as the CLI row, same build, same day: form probe accepted in 4.0s with a real dialog against the production hosted server (57527be), remote streamable-HTTP with OAuth, protocol 2026-07-28 negotiated natively. The embedded client identifies as goose-app 1.50.0 (the CLI reports goose-cli — same version, distinct client identity per surface). URL mode not advertised; the same elicit_selection review-page round-trip verified the fallback here too. Sampling and roots advertised, as on the CLI. One attachment quirk worth knowing: with the extension enabled: true in ~/.config/goose/config.yaml its tools didn't surface in the tool list until the extension was re-enabled by its exact config key via the extension manager — a load-order nuisance, not an elicitation defect (it did not recur). Contributed via elicit_doctor share: true. MCP Apps: broken. Goose Desktop advertises io.modelcontextprotocol/ui and loads the view (the 2026-10-08 elicit_display test completed the ui/initialize handshake and offered fullscreen), but its ACP chat path rebuilds the tool result before ui/notifications/tool-result and drops the server's CallToolResult._meta, which the MCP Apps spec delivers to the view. elicit_display carries its render there, so the view showed only the text summary. Tracked upstream as aaif-goose/goose#11323 (reproduced by a maintainer; the earlier fix for the legacy desktop path, #7435/#7476, doesn't cover the ACP path). Verbatim fingerprint: | |||||||
| 26.901.51231 | — | yes | yes | yes | 2026-09-06 | ||
Notes & evidenceFull remote support again on the September build: form probe accept in 6.8s against the hosted server (staging 9e42348, identical code to production; was 4.4s on 26.810.52044). Client codex-mcp-client 0.153.4 — out of alpha — now also advertising an openai/form extension; Protocol shows — for the usual legacy-lane echo reason. URL re-verified live on this build (2026-09-06): elicit_selection's URL-mode push rendered ChatGPT's native "Action required" card (message + URL + Open link), the review page round-tripped, and elicit_result retrieved the choice. The loop closed by polling, which is the design's authoritative path — the completion notification is best-effort (url-mode is async; hosts often hold no live stream when the human decides). Observed but unattributed: the host's card stayed "Action required" after the browser submission; whether ChatGPT consumes notifications/elicitation/complete when a stream is live remains unverified, and the agent's passive waiting was prompt-shaped (it was only asked to run the tool), not a host defect. Earlier verification: 2026-08-14 via elicit_approval (26.810.50856, superseded archive). Captured via pasted contribute-fingerprint text — ChatGPT surfaces MCP tools but not prompts (see the stdio row) — with sharing disabled in-session, contributed through the issue flow instead (elicitly/elicitly#37). Correction history, preserved on purpose in the superseded archives: the two 26.810.52044 fingerprints show every content-bearing form accept erroring — Elicitly's own bug, not the host's (the v1 MCP SDK's default Ajv validator does runtime codegen, forbidden in Cloudflare workerd; fix 79bde01 pins the codegen-free CfWorker validator). openai/codex#38707 was filed on that earlier evidence and has been corrected. MCP Apps: elicit_display rendered inline on 2026-10-08 against the hosted server via the standard _meta.ui.resourceUri, following the host theme (including a live light/dark switch), with fullscreen as a side panel and template links opening in the browser. Verbatim fingerprint: Superseded evidence (earlier versions of this host): | |||||||
| 26.901.51231 | 2025-06-18 | yes | advertised | advertised | 2026-09-06 | ||
Notes & evidenceForm still verified working on the September build (released 2026-09-05): probe accept in 8.3s, real dialog answered (was 10.4s on 26.810.41047). The embedded client left alpha — codex-mcp-client 0.153.4, was 0.148.0-alpha.9 — and now advertises an openai/form extension alongside the MCP Apps UI extension (mcp-app + skybridge HTML). URL mode stays advertised here for the usual reason: the Free stdio server never pushes URL mode; the HTTP row carries its live verification. Host observation: ChatGPT Desktop surfaces MCP tools but not prompts, so contribute-fingerprint can't be selected from any menu — this capture followed the prompt's text pasted into the chat, and the copy-paste contribution flow worked as designed (elicitly/elicitly#36). First row captured with the attachment-path field (config-file npx). Sampling and roots not advertised. The same-day contrast with Claude Desktop 1.46388.4 is the matrix's sharpest: same server, same transport, one host renders the dialog in 8.3s, the other doesn't advertise the capability at all. Verbatim fingerprint: Superseded evidence (earlier versions of this host): | |||||||
| 1.46388.4 | 2026-07-28 | no | no | yes | 2026-09-06 | ||
Notes & evidenceThe cell moved broken → no, and the history is the point: 1.34493.1 ADVERTISED elicitation.form but never rendered it — the probe timed out at the doctor's 40s bound with no dialog (advertised_but_unanswered; anthropics/claude-code#88901; the superseded fingerprint). On 1.46388.4 the connector stopped advertising entirely: the client now identifies as Anthropic/ClaudeAI 1.0.0 (replacing embedded claude-code 2.1.241), negotiates 2026-07-28 natively — this matrix's first non-null Protocol cell — and advertises exactly one capability, the MCP Apps UI extension (text/html;profile=mcp-app). Less capability on paper, more honesty in practice: servers can degrade gracefully instead of hanging on a dialog that never comes. Same-day correction, preserved on purpose: the first capture attempt (19:51 UTC) errored twice — Elicitly's own modern-lane doctor bug (the probe fired at a non-advertising client; elicitly-pro#87, fixed within the hour) — and the archived fingerprint is the clean 20:42 UTC capture against the fixed server (5e631bb), probe recorded in-band as attempted: false. MCP Apps: elicit_display rendered inline on 2026-10-08 through the claude.ai connector in the desktop app's Code tab (client Anthropic/ClaudeAI 1.0.0, MCP Apps advertised, no elicitation). Verbatim fingerprint: Superseded evidence (earlier versions of this host): | |||||||
| 1.46388.4 | 2025-11-25 | no | no | yes | 2026-09-06 | ||
Notes & evidenceNot advertised — verified across BOTH local attachment paths on the same build, same chat surface, same day: a config-file server (npx -y elicitly) and the one-click MCPB desktop-extension install fingerprint identically. The embedded client (claude-ai 0.1.0, distinct from the connector path's Anthropic/ClaudeAI) advertises no elicitation, sampling, or roots; its only capability is the MCP Apps UI extension — a hint at where Desktop is steering rich interaction. The probe was therefore not attempted (attempted: false, an honest absence — contrast the HTTP row's advertised-but-broken history). Agent-mode evidence, summarized only (no verbatim archive): the same build's agent-mode surface runs yet another client identity (local-agent-mode-<extension name>) which also advertises no elicitation but does advertise roots (listChanged: true) — one desktop app, three embedded client stacks depending on how and where the server is attached. Both fingerprints captured via the contribute-fingerprint prompt. MCP Apps: elicit_display rendered inline on 2026-10-08 from both the config-file server (local dev build) and the MCPB extension, following the host theme and offering fullscreen. Verbatim fingerprint: | |||||||
| 2.1.231 | 2025-11-25 | yes | no | no | 2026-08-23 | ||
Notes & evidenceProbe accepted in 7.8s on 2.1.231 against the free stdio server (elicitly 0.5.0), contributed via the free edition's contribute-fingerprint prompt (pre-filled GitHub issue flow, elicitly/elicitly#21). Consistent with the prior verbatim archive on 2.1.228 (accept in 6.6s, elicitly/elicitly#13). Earlier evidence, summarized only: probes accepted in 22.5s on 2.1.223 and 13.2s on 2.1.206, plus live elicit_confirm() calls. A probe once read back as "unsupported" when it outlasted the SDK's 60s window with no answer — elicit_doctor now bounds the probe at 40s (@elicitly/tools 0.5.1), so an unanswered probe returns advertised_but_unanswered in-band rather than erroring. Verbatim fingerprint: Superseded evidence (earlier versions of this host): | |||||||
| 2.1.228 | — | yes | no | no | 2026-08-19 | ||
Notes & evidenceForm elicitation over remote HTTP WORKS as of 2.1.228: probe accepted in 8.3s (21.3s in a prior run) with a real dialog — renders as an option choice, then the host's Accept — captured on macOS via the contribute-fingerprint prompt (elicit_doctor share: true). History, preserved: 2.1.223 auto-answered cancel with no dialog (~1.5s server-side; archived fingerprint), and 2.1.226 reportedly dropped the request until the server timed out (anthropics/claude-code#85442 — still open upstream, but fixed in practice by 2.1.228 per this evidence). URL mode remains unadvertised (#48164). Protocol shows — because the legacy lane's handshake echo doesn't yet carry the negotiated revision. Verbatim fingerprint: Superseded evidence (earlier versions of this host): | |||||||
Prefer a spreadsheet? Download the matrix as CSV to sort and filter it however you like.
Upstream issues we’re tracking
Section titled “Upstream issues we’re tracking”Host-side gaps in elicitation and MCP Apps — whether a bug in an advertised capability or a mode not yet built — close fastest upstream. If you want them to work in more places, a 👍 on the issues below tells those teams it matters — every row is open and active (resolved or superseded issues are removed, and their evidence stays in the matrix rows above):
| Issue | Host | What it covers |
|---|---|---|
| anthropics/claude-code#88901 | Claude Desktop | Embedded claude-code (Desktop connectors / Cowork) declares the elicitation capability but never renders elicitation/create — calls hang until the tool timeout. As of Desktop 1.46388.4 the connector runs a new client (Anthropic/ClaudeAI) that no longer advertises elicitation at all — the hang is gone because the claim is gone (see the matrix row’s arc); the issue remains the ask for the capability to exist and work |
| anthropics/claude-code#85442 | Claude Code (CLI) | Remote streamable-HTTP form elicitation silently dropped or auto-canceled — fixed in practice by 2.1.228 per our live probe (see the matrix row); still open upstream |
| anthropics/claude-code#48164 | Claude Code (CLI) | URL-mode elicitation/create not supported — the mode behind server-initiated auth flows and Elicitly Pro’s native URL prompt (absorbed #56243, Claude Cowork’s auto-cancel) |
| anthropics/claude-ai-mcp#153 | Claude.ai (web) | Feature request to make elicitation work in the web client. As of 2026-10-08 claude.ai connectors run Anthropic/ClaudeAI, which advertises MCP Apps but no elicitation at all (the earlier embedded claude-code client in Cowork advertised elicitation.form but never rendered it — the #88901 hang; see the Claude.ai row’s superseded evidence). Until it lands, claude.ai connectors have no native-dialog path, which is where Pro’s hosted review page fills in |
| aaif-goose/goose#11323 | Goose Desktop | MCP Apps: the ACP chat path drops the server’s CallToolResult._meta before ui/notifications/tool-result, so views that carry per-call data there (like elicit_display’s render) get only content and structuredContent |
| openai/codex#13405 | ChatGPT Desktop / Codex | The umbrella elicitation spec-compliance issue for OpenAI’s MCP client |
| openai/codex#23383 | ChatGPT Desktop / Codex | Auto-approve answers elicitation with empty content, violating the requested schema |
Know of an equivalent issue for another host? Include the link when you contribute a fingerprint and we’ll add it here.
Contribute a fingerprint
Section titled “Contribute a fingerprint”Connected to the hosted Pro server? Use the
contribute-fingerprint prompt
(hosts that support MCP prompts list it — in Claude Code it appears as a
slash command). It collects the host details, asks for your consent, and
shares the report directly via elicit_doctor’s share: true — no
copy-paste. Contributions land in a review queue; the matrix stays curated.
Otherwise — or on the free stdio server — run elicit_doctor (with
probeElicitation: true) in your host; asking your agent is usually enough:
Run elicit_doctor with probeElicitation true and show me the raw JSON. Then tell me this app’s product name and version (plus its release date if you know it), whether this MCP server is connected over stdio or remote HTTP, and how it was attached — a config-file command, a desktop extension (MCPB), or a remote connector.
The second sentence collects what the report can’t say about itself: the
doctor sees the embedded MCP client (e.g. codex-mcp-client), not the product
around it (ChatGPT Desktop), and it can’t tell which transport it traveled or
how the host attached it — which matters, since hosts can run different
embedded clients per attachment path.
The report itself carries the rest:
initialize.request.clientInfo— the MCP client’s name and versioninitialize.response.protocolVersion— the negotiated protocol versionsupport.elicitationForm/support.elicitationUrl— what the host advertisesprobes.elicitationForm.verdict— whether form elicitation actually works
Then share it either way:
- Open a fingerprint issue on the public GitHub repo (preferred — the title and body are pre-filled; paste your JSON into the code block), or
- email it to support@elicitly.ai with the host name and version in the subject.
Either route, the report contains no elicitation payloads — it’s the handshake echo, capability booleans, and the probe verdict.