Skip to content
Elicitly

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

Section titled “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

Section titled “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. 
{ "probeElicitation": false }

The report’s three layers

Section titled “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

Section titled “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_broken advertised, but cancelled faster than a human could (< 250 ms) — the host auto-cancelled
unsupported the call threw / errored

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

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

Examples

Section titled “Examples”

A quiet checkup

Section titled “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

Section titled “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_broken"
    }
  }
}

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.

Section titled “Related”