elicit_doctor

Reports the connected host’s support for the client features — Elicitation, Roots, and Sampling — and, with probeElicitation: true, runs one live elicitation round-trip and classifies the result.

When to use

Before relying on elicit_confirm or elicit_form in an unfamiliar host — advertising a capability is not the same as implementing it, and the probe catches the difference. Also the tool behind every Support Matrix entry.

Input

Parameter	Type	Required	Description
`probeElicitation`	boolean	no	Default `false`. When `true`, fire one real form-mode elicitation and record what happened — this prompts the user.
`share`	boolean	no	Pro Edition only. Default `false`. When `true`, contribute the finished report to the Support Matrix evidence queue — see below.
`productName`	string	no	Pro, with `share`. The host product’s name (e.g. “Claude Code”) — the report only sees the embedded MCP client, not the product around it.
`productVersion`	string	no	Pro, with `share`. The host product’s version.
`notes`	string	no	Pro, with `share`. Anything unusual about the setup (OS, flags, enterprise policy).

{ "probeElicitation": false }

On the hosted server, share: true stores the report — plus whatever productName / productVersion / notes you volunteered — in the Support Matrix’s evidence queue, tied to your authenticated account. The report contains the handshake echo, capability booleans, and probe verdicts — no elicitation payloads and no conversation content. The result then carries shared: true (or shared: false with a shareError if storage failed; you still get your report). Sharing never happens unless you pass share: true. The easiest way to contribute is the server’s contribute-fingerprint prompt (shown by hosts that support MCP prompts — in Claude Code it appears as a slash command), which collects the metadata and consent, then makes this call for you. The matrix itself stays curated: contributions are evidence for review, and no matrix cell changes automatically.

The report’s three layers

initialize — the initialize handshake, echoed verbatim: request is what the client sent (as the SDK retained it), response is what the server replied.
support — Elicitly’s interpretation: derived booleans applying the spec’s rules.
probes — Elicitly’s active experiments (opt-in): what actually happened when the feature was exercised, which can disagree with what was advertised.

Output

The passive report (no probe):

{
  "initialize": {
    "request": {
      "clientInfo": { "name": "claude-code", "version": "2.1.76" },
      "capabilities": {
        "elicitation": { "form": {} },
        "sampling": {},
        "roots": { "listChanged": true }
      }
    },
    "response": {
      "protocolVersion": "2025-11-25",
      "capabilities": { "tools": { "listChanged": true } },
      "serverInfo": { "name": "elicitly", "version": "0.1.0" }
    }
  },
  "support": {
    "elicitation": true,
    "elicitationForm": true,
    "elicitationUrl": false,
    "sampling": true,
    "roots": true
  }
}

initialize.request has no protocolVersion because the SDK does not retain the client’s requested version; the negotiated version is what matters and appears in initialize.response. (The SDK also normalizes the empty-object shorthand: a client that sent elicitation: {} is retained as elicitation: { "form": {} }.)
support.elicitationForm — the host advertises form-mode elicitation (an empty elicitation: {} counts, per spec).
support.elicitationUrl — the host advertises url-mode elicitation.

With probeElicitation: true, the report adds probes.elicitationForm:

{
  "probes": {
    "elicitationForm": {
      "attempted": true,
      "action": "accept",
      "latencyMs": 1840,
      "data": "ok",
      "verdict": "working"
    }
  }
}

verdict is one of:

verdict	meaning
`working`	the user accepted; elicitation round-trips correctly
`user_declined`	the user declined/cancelled after a real prompt
`advertised_but_autocanceled`	advertised, but the “no” came back faster than a human plausibly could (`< 2000 ms`) — the host auto-answered without ever asking anyone
`advertised_but_unanswered`	advertised, but no answer arrived before the request timeout — a human may have left the dialog open, or the host silently dropped it
`unsupported`	the call threw / errored

How long the probe waits: on the hosted Pro server the probe gives up after 40 seconds — deliberately below the ~60-second tool-call limit common to MCP hosts (Claude Desktop among them) — so a host that never delivers the dialog still returns the finished report in-band, with advertised_but_unanswered as the verdict, instead of the host killing the call first. The Free (stdio) edition currently waits the MCP SDK’s default 60 seconds.

If the host never advertised elicitation, the probe is skipped:

{ "probes": { "elicitationForm": { "attempted": false, "reason": "client did not advertise elicitation" } } }

Examples

A quiet checkup

No arguments needed — the passive report never prompts the user:

{}

Read support for the verdict at a glance: if elicitationForm is false, elicit_confirm and elicit_form cannot raise a dialog in this host.

Catching a broken host in the act

The probe is where elicit_doctor earns its name — advertising a capability is not the same as implementing it:

{ "probeElicitation": true }

On a host that advertises elicitation but auto-cancels it, the report shows the contradiction directly — support says yes, the probe says no:

{
  "support": { "elicitation": true, "elicitationForm": true },
  "probes": {
    "elicitationForm": {
      "attempted": true,
      "action": "cancel",
      "latencyMs": 8,
      "data": null,
      "verdict": "advertised_but_autocanceled"
    }
  }
}

No human can decline a dialog in 8 milliseconds — the host cancelled it before anyone saw it. That fingerprint is exactly what the Support Matrix records; contribute your host’s report there.

elicit_confirm / elicit_form — the tools whose viability the report answers
Support Matrix — reports from known hosts