Loading ToolBench
A Model Context Protocol service for DJI drone waypoint mission planning
Server has 10 tools with mixed quality. Tools 1-2 and 5 have detailed input schemas with proper constraints (min/max, enums, required fields). However, tools 3-4, 6-8, and 10 lack visible input schemas entirely, only descriptions are provided. Tool 9 (utility_functions) has a complex schema but is a catch-all that bundles 4 distinct operations (convert_coordinates, calculate_distance, analyze_flight_plan, validate_coordinates) into one tool, violating single-responsibility. Descriptions are present but generic (10-50 chars for tools 3-4, 6-8, 10). No tool annotations (readOnlyHint/destructiveHint) despite clear WRITE/READ_ONLY risk labels. Error handling and recovery guidance absent from visible code. Output schemas not documented.
Coordinate multiple flight missions for synchronized execution
Generate KMZ files from mission plans for visualization and sharing
Optimize waypoint order to minimize flight distance, time or energy consumption
Plan an automated mapping survey mission with parallel flight lines
Plan an oblique photography mission with multi-angle camera coverage
Plan a strip-based flight mission for linear area coverage
Plan a basic waypoint mission with specified waypoints and flight parameters
Query DJI device information and capabilities
6 of 10 tools (plan_oblique_mission, plan_strip_mission, coordinate_multi_flights, query_device_info, validate_mission_compatibility, generate_kmz) have no visible input schemas. Only descriptions provided. Cannot verify parameter types, constraints, or required fields.
utility_functions bundles 4 distinct operations (convert_coordinates, calculate_distance, analyze_flight_plan, validate_coordinates) into one tool with a function_type enum. Violates single-responsibility principle. Should be split into 4 separate tools: convert_coordinates, calculate_distance, analyze_flight_plan, validate_coordinates.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear WRITE/READ_ONLY risk labels in metadata. Tools 1-2, 6, 10 are WRITE operations but lack destructiveHint annotation. Tools 5, 7-9 are READ_ONLY but lack readOnlyHint annotation.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 36 | <=2025-11-25 | v2 |
Provide coordinate conversion, distance calculation, flight plan analysis and other utility functions
Validate mission compatibility with aircraft and environmental constraints
Descriptions for tools 3-4, 6-8, 10 are under 20 characters (e.g., 'Plan an oblique photography mission...' is 50 chars but lacks context on when to use vs similar tools). Descriptions should be 50-200 chars and answer: what does it do, when to use it, what does it return?
No output schemas documented for any tool. LLMs cannot infer what fields to expect in responses, preventing downstream tool chaining and forcing agents to guess field names. All tools must document return types.