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.)
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 | Captured |
|---|---|---|---|---|---|---|
| 26.901.51231 | — | 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. Verbatim fingerprint: Superseded evidence (earlier versions of this host): | ||||||
| 26.901.51231 | 2025-06-18 | yes | 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 | 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. Verbatim fingerprint: Superseded evidence (earlier versions of this host): | ||||||
| 1.46388.4 | 2025-11-25 | no | no | 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. Verbatim fingerprint: | ||||||
| 2.1.231 | 2025-11-25 | yes | 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): | ||||||
| unknown | — | broken | no | 2026-08-23 | ||
Notes & evidenceAdvertised ≠ working, same shape as the Claude Desktop row: Cowork advertises elicitation.form but the probe timed out at the doctor's 40s bound with no dialog (verdict advertised_but_unanswered). The embedded MCP client identifies as claude-code 2.1.241 — the same client library as Claude Code (where remote-HTTP forms work) and Claude Desktop, so the gap is the web Cowork UI layer, not the client. Tracked upstream as anthropics/claude-code#88901, which explicitly covers Cowork. hostVersion is unknown — the web app carries no user-facing version; the contributor left it null. Captured 2026-08-23 via the contribute-fingerprint prompt against staging (server 44ace47, identical code to production). This also corrects the premise of anthropics/claude-ai-mcp#153: claude.ai does advertise elicitation via embedded claude-code — it just doesn't render it. Verbatim fingerprint: | ||||||
| 2.1.228 | — | yes | 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 elicitation gaps — whether a bug in an advertised capability or a mode not yet built — close fastest upstream. If you want MCP elicitation 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. Our own fingerprint shows Cowork already advertises elicitation.form (via embedded claude-code) but never renders it — the #88901 hang, see the Claude.ai matrix row — so this is really “make the advertised capability function.” Until it does, claude.ai connectors have no native-dialog path, which is where Pro’s hosted review page fills in |
| 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.