Skip to main content
Glama
Sign In

Elicitly Pro

by ai.elicitly
OverviewDiscussionsAdmin

Diagnose the host's elicitation support

elicit_doctor

Check whether the connected MCP host actually supports elicitation (and sampling/roots) before relying on it — advertising a capability is not the same as it working. Use it to decide whether to call elicit_form/elicit_confirm, to explain why a prompt did or didn't appear, or to contribute a host capability fingerprint. Returns a passive report derived from the initialize handshake; set probeElicitation: true to also run one live form round-trip (the user may see a dialog) and classify what really happened. Read-only. Pass share: true to contribute the report to Elicitly's public Support Matrix evidence queue — stored: this report plus the optional productName / productVersion / notes (the host product's name and version, which the report cannot see from inside, and any unusual setup); the report itself contains no elicitation payloads or conversation content. The result then carries shared: true|false.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "elicit_doctor"
  }
}

Input Schema

NameRequiredDescriptionDefault
notesNoWith share: anything unusual about the setup worth recording with the evidence.
shareNoContribute this report to Elicitly's public Support Matrix evidence queue. Stored: the report plus productName / productVersion / notes; no elicitation payloads or conversation content.
productNameNoWith share: the host product's name as the user sees it (e.g. "Claude Desktop") — the report cannot detect this from inside.
productVersionNoWith share: the host product's version, if known.
probeElicitationNoAlso fire one live form-elicitation round-trip (the user may see a dialog) and report the outcome under probes.elicitationForm. Default false: passive capability report only, no prompt.

Output Schema

NameRequiredDescriptionDefault
probesNoPresent only when probeElicitation was true: the live round-trip's attempted/action/latencyMs/verdict.
sharedNoPresent when share: true was passed — whether the report landed in the evidence queue.
supportYesElicitly's derived support booleans, inferred from the advertised capabilities.
initializeYesThe MCP initialize handshake echoed verbatim: { request: { clientInfo, capabilities }, response: { protocolVersion, capabilities, serverInfo } }.
shareErrorNoPresent when sharing was requested but failed: a one-line error summary.
deprecationsYesSpec-level deprecation advisories (MCP 2026-07-28, SEP-2577) for the client features the report surfaces.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedOutput schema / additionalProperties
      Previous value: -falseNew value: +{}
    • changedOutput schema / properties / probes / additionalProperties
      Previous value: -falseNew value: +{}
    • changedOutput schema / properties / support / additionalProperties
      Previous value: -falseNew value: +{}
  2. Changed6 schema fields changed
    • addedInput schema / properties / notes / description
      Added value: +"With share: anything unusual about the setup worth recording with the evidence."
    • addedInput schema / properties / probeElicitation / description
      Added value: +"Also fire one live form-elicitation round-trip (the user may see a dialog) and report the outcome under probes.elicitationForm. Default false: passive capability report only, no prompt."
    • addedInput schema / properties / productName / description
      Added value: +"With share: the host product's name as the user sees it (e.g. \"Claude Desktop\") — the report cannot detect this from inside."
    • addedInput schema / properties / productVersion / description
      Added value: +"With share: the host product's version, if known."
    • addedInput schema / properties / share / description
      Added value: +"Contribute this report to Elicitly's public Support Matrix evidence queue. Stored: the report plus productName / productVersion / notes; no elicitation payloads or conversation content."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "deprecations": {
+      "description": "Spec-level deprecation advisories (MCP 2026-07-28, SEP-2577) for the client features the report surfaces.",
+      "items": {
+        "additionalProperties": {},
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "initialize": {
+      "additionalProperties": {},
+      "description": "The MCP initialize handshake echoed verbatim: { request: { clientInfo, capabilities }, response: { protocolVersion, capabilities, serverInfo } }.",
+      "propertyNames": {
+        "type": "string"
+      },
+      "type": "object"
+    },
+    "probes": {
+      "additionalProperties": false,
+      "description": "Present only when probeElicitation was true: the live round-trip's attempted/action/latencyMs/verdict.",
+      "properties": {
+        "elicitationForm": {
+          "additionalProperties": {},
+          "propertyNames": {
+            "type": "string"
+          },
+          "type": "object"
+        }
+      },
+      "required": [
+        "elicitationForm"
+      ],
+      "type": "object"
+    },
+    "shareError": {
+      "description": "Present when sharing was requested but failed: a one-line error summary.",
+      "type": "string"
+    },
+    "shared": {
+      "description": "Present when share: true was passed — whether the report landed in the evidence queue.",
+      "type": "boolean"
+    },
+    "support": {
+      "additionalProperties": false,
+      "description": "Elicitly's derived support booleans, inferred from the advertised capabilities.",
+      "properties": {
+        "elicitation": {
+          "type": "boolean"
+        },
+        "elicitationForm": {
+          "type": "boolean"
+        },
+        "elicitationUrl": {
+          "type": "boolean"
+        },
+        "roots": {
+          "type": "boolean"
+        },
+        "sampling": {
+          "type": "boolean"
+        }
+      },
+      "required": [
+        "elicitation",
+        "elicitationForm",
+        "elicitationUrl",
+        "sampling",
+        "roots"
+      ],
+      "type": "object"
+    }
+  },
+  "required": [
+    "initialize",
+    "support",
+    "deprecations"
+  ],
+  "type": "object"
+}
  3. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only say openWorldHint=false and destructiveHint=false; the description adds the material behavioral facts beyond them — that probeElicitation fires a live round-trip with a possible user dialog, that share: true enqueues the report to a public evidence queue, exactly what is stored, and that no elicitation payloads or conversation content leave. This is exactly the extra context annotations cannot carry.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and the safety/privacy caveats are front-loaded, and each sentence carries distinct information. It is dense and the longer sentences (share clause) could be split, but nothing is redundant padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return structure needn't be documented, and the description still explains the passive-vs-probe modes, the sharing side effect, and data handling. An agent has everything needed to decide whether and how to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description adds the interaction between parameters: probeElicitation's default-false passive behavior, and the pairing of share: true with productName/productVersion/notes that the report cannot self-detect. It slightly exceeds the schema's per-field text by explaining why those fields exist and what the result carries (shared: true|false).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource — diagnosing whether the connected host actually supports elicitation — and explicitly frames it against the sibling call targets (elicit_form/elicit_confirm). An agent can distinguish this diagnostic tool from the other elicit_* siblings without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit when-to-use triggers: deciding whether to call elicit_form/elicit_confirm, explaining why a prompt did or didn't appear, or contributing a capability fingerprint. The alternative path (turn on probeElicitation vs the default passive report) is spelled out with the trade-off.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Elicitly Pro toolsInspect
Try in Browser
Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources