Local (stdio) MCP server that gives your prompts and Agent Skills MCP elicitation — human-in-the-loop dialogs (elicit_confirm, elicit_form) and the elicit_doctor capability report, with no server of your own.
Elicitly provides three well-intentioned tools for human-in-the-loop interaction with clear names and reasonable descriptions. However, schema documentation is incomplete, parameter descriptions lack depth, and output schemas are not documented. The tools follow a verb-noun naming pattern (elicit_*) that clearly signals action, and descriptions explain the purpose adequately. Input parameters are present and typed via TypeScript/Zod, but the JSON Schema representation visible in the code lacks sufficient detail for LLM reasoning about field mappings and constraints. Error handling is generic. The prompts feature is implemented but ancillary to the core tool functionality.
Ask the user an OK/Cancel confirmation (modeled on JavaScript's confirm()).
Report the host's support for elicitation (form/url mode), sampling, and roots; optionally run one live elicitation probe.
Ask the user to fill a form defined by your own JSON schema; returns the raw {action, content}.
Output schemas not documented. Tool descriptions do not specify what fields are returned or their types. LLMs cannot plan downstream operations or extract relevant data.
Parameter descriptions are minimal and lack actionable guidance. The 'labels' parameter in elicit_confirm lacks detail on when to use it or what happens if omitted. 'requestedSchema' description does not explain the ElicitSchema structure or how fields map to form rendering.
elicit_form returns raw {action, content} but does not document the structure of 'content' or valid values for 'action'. LLMs must guess at the response format, risking misinterpretation.
elicit_doctor's 'probeElicitation' parameter is the only required input, but its description lacks guidance on when to set it true vs false or what happens in each case. No mention of side effects or impact on subsequent tool behavior.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2025-06-18+ | v2 |
Error handling is not visible in the tool definitions. No indication of retryable vs fatal errors, no recovery guidance, no actionable error messages. If a form submission times out or is cancelled, the LLM has no direction on what to do next.
Timeout parameters (timeoutSeconds) exist but lack guidance on defaults, bounds, or what happens on timeout. Are timeouts retryable? Does the user see an error or does the dialog quietly disappear?