Loading ToolBench
MCP elicitation demo - interactive table booking system
The server implements one tool (book_table) with clear intent and basic structure, but has significant gaps in schema documentation, parameter descriptions, and output specification. The tool name follows verb_noun convention and the description is present but generic. Input parameters have types and basic descriptions, but lack constraints, ranges, and validation messaging. Output is free-text strings rather than structured objects. Error handling returns user-facing messages but lacks recovery guidance and error categorization. The implementation shows defensive programming (hasattr checks, type introspection) but exposes those defenses rather than normalizing the response format.
Book a table with intelligent elicitation for missing or invalid data.
Output schema not documented. Tool returns free-text strings instead of structured objects with typed fields. LLMs cannot reliably extract booking confirmation details or parse errors for recovery.
Parameter descriptions lack format constraints and validation rules. 'date' param description omits that invalid/past dates trigger re-elicitation. 'party_size' lacks min/max bounds in the description (code enforces 1-20 but LLM cannot see this).
Tool description is too generic. 'Book a table with intelligent elicitation for missing or invalid data' does not explain WHEN to call this tool, what it requires, or what happens on cancellation/confirmation. Baseline for A+ tools is 50-200 chars of clear context; this is 80 chars of vague intent.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 57 | - | v1 |
Error handling returns unstructured text messages ('Date input cancelled. Booking cancelled.', '❌ Error processing confirmation...') instead of structured error objects. LLMs cannot categorize whether an error is retryable, user-fixable, or fatal.
No confirmation/dry-run pattern before committing the booking. The tool directly commits state after user confirms. If the user changes their mind mid-interaction or the LLM hallucinates confirmation, the booking is placed. Irreversible operations should support a preview or confirmation step.
Elicitation implementation uses union pattern matching (match result:) but does not fully document the elicitation lifecycle in the tool description. LLMs invoking this tool do not understand that elicitation will interrupt their execution for interactive user input.