Loading ToolBench
A Flutter/Dart implementation of the Model Context Protocol (MCP) for in-app LLM tool calling with support for user input collection, tool previews, and undo operations.
Six tools with explicit schemas and descriptions, but significant quality gaps. All tools have descriptions (10-50 chars, mostly short), and input schemas are present with typed parameters. However, descriptions lack depth, most are under 50 chars and do not explain WHEN to use the tool or what happens on success/failure. Parameters lack enums for constrained values (e.g., travelMode, tripType, weekdays). No output schemas documented. Error handling and recovery guidance absent. Tool composition is reasonable (each does one thing), but parameter naming could be more explicit (e.g., 'weekdays' should clarify the integer range 1-7 in the description, not just the schema). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Overall: functional but below production baseline.
Book a trip. Any missing field (destination, date, trip type, passengers) will be collected from the user.
Open email app with a prefilled draft.
Open calendar to create an event draft.
Echo a message back to the caller. Used to demo codegen.
Open map directions to a destination.
Set a repeating alarm at a specific hour/minute and weekdays list.
Descriptions are too short (10-50 chars) and lack actionable context. None explain WHEN to use the tool, what happens on success, or error recovery. LLMs cannot reliably select tools without richer descriptions (baseline 194 chars).
Constrained parameters lack enums. 'travelMode' accepts 'driving|walking|bicycling|transit' but is defined as free-form string. 'tripType' accepts 'one_way|round_trip' but no enum constraint. 'weekdays' accepts integers 1-7 but no enum. Enums prevent hallucinated values and are self-documenting.
No output schemas documented. Tools return results but LLMs cannot plan downstream calls or extract fields without knowing the response structure. All tools should document return types and field names.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 44 | 2026-07-28+ | v2 |
No error handling or recovery guidance. Tools do not document what errors can occur, whether they are retryable, or what the LLM should do next. E.g., 'book_trip' collects missing fields from user but does not specify error cases (invalid date, no availability).
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). 'schedule_weekday_alarm', 'create_calendar_event', 'compose_email_draft', and 'book_trip' are destructive/side-effecting but lack destructiveHint annotation. Agents need to know which calls are safe to retry.