Loading ToolBench
Natural language drone control system with coordinate transformations, telemetry, and command execution. Integrates with Claude Desktop and other MCP-compatible clients for multi-language drone command support.
DroneSphere exposes 5 drone control tools with moderate definition quality. Tool names follow verb_noun convention (execute_, get_, check_, transform_, smart_), which is positive. However, critical gaps exist: parameter descriptions are present but often generic; schemas lack proper JSON Schema structure with explicit type declarations; no documented output schemas for any tool; error handling is minimal with no recovery guidance; no input validation rules documented. The 'smart_navigate' tool is particularly problematic, it accepts 14 optional parameters with minimal type constraints, inviting LLM confusion about which coordinate system to use. Tool descriptions range from 74 - 243 characters, meeting the 10 - 1024 baseline, but lack guidance on when to use each tool vs. similar alternatives (e.g., execute_drone_command vs. smart_navigate for movement). No tool declares what data it returns or how to chain results to downstream calls. Security concerns: the natural-language command parameter in execute_drone_command could be injection-prone if the backend doesn't validate drone_id before executing. Overall: tools are functional but under-specified for safe LLM composition.
Check status of executing commands. Can check specific command by ID or show all active commands.
Execute natural language drone command. Commands execute asynchronously in background. Returns immediately with acknowledgment. Examples: 'takeoff to 10 meters', 'go north 5m then wait 3 seconds then land', 'fly forward 10 meters', 'بلند شو به ۱۵ متر' (Persian)
Get comprehensive drone telemetry and status. Includes position, attitude, battery, GPS info, and PX4 origin.
Smart navigation tool that handles ALL coordinate types automatically. Intelligently detects the coordinate type and performs all necessary transformations internally. Supports absolute GPS coordinates, NED from PX4 origin, offset from reference point, and body frame coordinates. The LLM only needs to understand user intent.
Transform body frame coordinates to NED frame. Body frame: X=forward, Y=right, Z=down (drone's perspective). NED frame: X=north, Y=east, Z=down (world coordinates). Useful for commands like 'fly forward 10m' or 'move right 5m'.
No documented output schemas. None of the 5 tools specify what fields they return, their types, or how results chain to downstream calls. LLMs cannot plan multi-step sequences without knowing what data is available.
smart_navigate accepts 14 optional parameters with minimal type constraints (no enums, no bounds). LLMs will guess which coordinate system to use, leading to wrong drone movements. E.g., latitude/longitude vs. north/east, no validation that only one coordinate type is provided.
No error handling guidance. If a command fails or drone is unreachable, what should the LLM do next? Retry? Check status first? Call a different tool? No recovery paths documented.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | <=2025-11-25 | v2 |
Parameter descriptions lack format/range constraints. 'command' in execute_drone_command says 'Natural language command' but doesn't specify length limits, injection safety, or what happens if the backend fails to parse it. 'drone_id' defaults to 1 but no min/max bounds documented.
execute_drone_command description doesn't state that commands are ASYNC ('Commands execute asynchronously in background. Returns immediately with acknowledgment.'), making it unclear whether the LLM should poll check_command_status afterward or if results appear immediately. This breaks tool composition.
Multi-language support mentioned for execute_drone_command ('Persian: بلند شو به ۱۵ متر') but no validation rules. Will the backend accept any language? Which ones are supported? What happens if an unsupported language is sent?
No tool declares idempotency. If execute_drone_command is retried on network failure, does it execute the same command twice (double takeoff)? Or is it safe to retry? Agents need this classification.
Tool composition is broken. execute_drone_command and smart_navigate both control drone movement. When should an LLM use execute_drone_command with a natural-language string vs. smart_navigate with structured coords? No guidance provided.