Loading ToolBench
Server has 7 tools with basic schemas and descriptions, but significant gaps limit production readiness. All tools have descriptions (10-50 chars, mostly short) and input schemas with types. However, descriptions lack depth, they state WHAT but not WHEN or WHY to use each tool, and lack dependency hints. Parameter descriptions are minimal (e.g., 'Cube ID to control' without format/constraint details). No output schemas documented. Error handling is generic ('error': str(e)) with no recovery guidance. Tool naming is verb-first and clear (scan_, connect_, disconnect_, get_, motor_, set_), following conventions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear WRITE vs READ_ONLY risk classifications. Composition is reasonable, each tool has one responsibility, but responses lack chaining IDs and pagination support.
Connect to a toio Core Cube
Disconnect from a toio Core Cube
Get a list of connected cubes
Control the motors of a toio Core Cube
Stop the motors of a toio Core Cube
Scan for toio Core Cubes
Set the LED color of a toio Core Cube
Descriptions lack context and recovery guidance. Most are 10-50 chars (below 194-char baseline for A+ tools). E.g., 'Scan for toio Core Cubes' does not explain WHEN to call it, what it returns, or what to do if no cubes are found. LLMs cannot determine tool selection priority.
No output schemas documented. Callers cannot predict response structure (e.g., does scan_cubes return {devices: [...]} or {cubes: [...]}?). LLMs must infer structure from code, risking parsing errors.
Parameter descriptions are minimal and lack constraints. E.g., 'Left motor speed (-100 to 100)' is in the description but not enforced in schema. No enum, min/max, or pattern constraints visible. LLMs may pass invalid values (e.g., 150 for motor speed).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 60 | <=2025-11-25 | v2 |
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk classifications. WRITE tools (connect_cube, motor_control, set_indicator) should be marked destructiveHint=true so agents know they have side effects and require confirmation.
Error handling is generic. Code returns {'error': str(e)} with no recovery guidance. E.g., if connect_cube fails with 'Device not found', the LLM has no hint to retry scan_cubes or try a different device_id. Errors should guide next steps.