A test fixture for MCP elicitation. It asks for input it does not want and never keeps a value, only its length and digest. Exposes a catalogue of MCP elicitation shapes as tools so an MCP client can be driven through every one of them on demand.
Strong foundation with clear naming, comprehensive descriptions, and proper tool annotations. All 7 tools have verb-based names (list_, run_, custom_, session_, exchange_, reset_) and detailed descriptions (100-250 chars). Input schemas are present for most tools with typed parameters. Tool annotations correctly applied (ReadOnlyHint, IdempotentHint). Key gaps: output schemas not documented in source; some parameter descriptions could be more prescriptive about constraints and error recovery; no explicit error handling guidance in descriptions.
Send a form elicitation carrying a schema supplied verbatim, for probing a shape the catalogue does not cover. The schema is passed through byte for byte, including one that is not valid JSON Schema.
Send a URL elicitation, or a -32042 URL-elicitation-required error, for an arbitrary URL.
Report what the server sent and what came back, newest first. This is the read-back when the client redacts submitted values from its own transcript.
List the elicitation scenarios this server can run, with what each one emits and what a conforming client should do about it.
Discard the exchange log.
Run one scenario from list_scenarios. Most scenarios ask for input; answering resumes the call, and the result reports the action and a fingerprint of each value rather than the value itself.
Output schemas not documented. Tool descriptions explain what tools do but not what they return. LLMs cannot plan downstream calls or extract fields without knowing response structure.
Parameter constraints not fully specified. 'scenario' param in run_scenario lacks format guidance; 'delivery' enum values (auto, deferred, direct) are mentioned but not formally constrained; 'limit' in exchange_log has no min/max bounds.
Error handling guidance missing. Descriptions do not explain what errors are possible, when to retry, or what the LLM should do if a scenario fails. E.g., run_scenario could fail if scenario ID is invalid or delivery mode is unsupported.
Inferred effective spec: 2026-07-28+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Report what this client negotiated: protocol version, elicitation capabilities, and which delivery mode the server will therefore use. Start here when a scenario behaves unexpectedly.
reset_log has no input schema visible in source. Tool is registered but schema definition not shown, making it impossible to verify parameter types and descriptions.
Destructive operations lack confirmation pattern. reset_log and run_scenario (with side effects) should support a dry-run or confirmation step to prevent accidental data loss.