Loading ToolBench
An MCP server implementation providing tools for taxi call center operations, including address verification, taxi availability checking, and taxi ordering capabilities.
Three tools defined with reasonable naming and verb-first conventions (verify_address, check_availability, order_taxi). All tools have descriptions (10-70 chars), but descriptions are minimal and lack actionable context for LLM selection. Input schemas are present with typed parameters and descriptions for most parameters. Output schemas are not documented, tool_result.go shows responses are JSON-marshaled but no structured output schema is declared. Error handling is minimal; tool implementations not fully visible. Risk annotations (READ_ONLY, WRITE) are present and helpful. Overall, this is a baseline functional MCP server with room for improvement in description depth, output documentation, and error guidance.
Check if a taxi is available at a given address.
Order a taxi for given passenger details and pickup location (street, city).
Verify that a given address consisting of street and city actually exists.
Tool descriptions are too brief and lack actionable context. 'Verify that a given address consisting of street and city actually exists' (62 chars) does not explain WHEN to call this tool, what validation it performs, or how it relates to other tools. LLMs need 50-200 char descriptions that answer: What does it do? When should I use it instead of similar tools? What does it return?
Output schemas are not documented. tool_result.go shows responses are JSON-marshaled strings, but no structured output schema is declared for any tool. LLMs cannot plan downstream calls or extract required fields without knowing what fields are returned. This forces agents to guess or issue extra discovery calls.
Error handling is absent or minimal. Tool implementations (verify.go, availability.go, order.go) are not shown in source; cannot confirm whether errors return actionable guidance. Per pattern:recovery-guide, errors must tell the LLM what to do next: 'Address not found. Try a different street name.' Raw error codes or empty responses leave agents stuck.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 54 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 11 | - | v1 |
Parameter descriptions are generic. E.g., 'The name and house number of the street to lookup and verify' for 'street' parameter does not specify format (e.g., '123 Main St'), length limits, or validation rules. LLMs may pass invalid formats without constraint guidance.
No confirmation or dry-run pattern for destructive operations. order_taxi modifies state (creates a taxi order) but has no confirm_before_execute or dry_run parameter. Agents may accidentally book multiple taxis if they retry on ambiguous failures, leading to duplicate charges.
Taxi availability state is not documented. check_availability returns a boolean or enum, but the response schema is unknown. Does it return 'available' | 'unavailable' | 'limited'? How should the agent interpret 'limited'? Without documented output, agents cannot reason about next steps.