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. (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.)
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 |
|---|---|---|---|---|---|---|
| 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: | ||||||
| 1.34493.1 | — | broken | no | 2026-08-22 | ||
Notes & evidenceAdvertised ≠ working, live: the connector advertises elicitation.form, but the probe timed out at the doctor's 40s bound with no dialog ever rendered (verdict advertised_but_unanswered; the owner confirmed nothing appeared). Captured on Claude for Mac 1.34493.1 (255293) via the contribute-fingerprint prompt from the + menu — in Cowork mode; Chat mode's tool calls errored before the probe could run. The embedded MCP client identifies as claude-code 2.1.241 — the same client library as Claude Code, where remote-HTTP forms DO work — so the gap is Desktop's connector UI layer, not the client. Tracked upstream as anthropics/claude-code#88901. Connector traffic is proxied through Anthropic's cloud (user-agent Claude-User), and protocol shows — for the usual legacy-lane echo reason. Two earlier same-evening attempts at the SDK's default 60s probe window died at the host's own ~60s tool-call limit with no in-band report — the probe's 40s bound (elicitly-pro#60) is what made this capture returnable. 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): | ||||||
| 26.810.52044 | — | yes | yes | 2026-08-15 | ||
Notes & evidenceFull remote support, both modes. Form: verified working against the hosted Elicitly Pro server (probe accept in 4.4s). URL: verified 2026-08-14 via elicit_approval's native URL-mode push — the first URL-mode-verified host. Correction history, preserved on purpose: the two earlier fingerprints show every content-bearing form accept erroring, which was Elicitly's own bug, not the host's — the v1 MCP SDK validates accept content with Ajv by default, and Ajv's runtime code generation is forbidden in Cloudflare workerd (server fix 79bde01 pins the SDK's codegen-free CfWorker validator). The -server-bug fingerprint's reason field is what cracked the diagnosis; openai/codex#38707 was filed against the host on the earlier evidence and has been corrected. Verbatim fingerprint: | ||||||
| 26.810.41047 | 2025-06-18 | yes | advertised | 2026-08-14 | ||
Notes & evidenceApp released 2026-08-13; the embedded MCP client identifies as codex-mcp-client 0.148.0-alpha.9. Probe: accept in 10.4s, verdict working. First host observed advertising URL-mode elicitation (url: {}) — verified working over remote HTTP (see that row); the Free stdio server never pushes URL mode, so this cell stays advertised. Also advertises the MCP Apps UI extension (io.modelcontextprotocol/ui: mcp-app + skybridge HTML). Sampling and roots not advertised. Verbatim fingerprint: | ||||||
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. The exact behavior behind our Claude Desktop matrix row |
| 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), and whether this MCP server is connected over stdio or remote HTTP.
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.
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.