Loading ToolBench
MCP server for controlling ArduPilot-based drones via MAVLink protocol. Provides tools for arming/disarming, flight mode changes, takeoff/landing, mission management, and position tracking.
The ArduPilot Controller MCP Server exhibits serious definition quality gaps across multiple dimensions. While all 12 tools are explicitly registered with the @mcp.tool() decorator and have descriptions, there are critical deficiencies in schema completeness, parameter documentation, and error handling guidance. Most tools lack properly constrained input schemas with enum values where applicable (e.g., change_mode has a free-form 'mode' string instead of an enum of valid modes). Parameters often lack detailed descriptions explaining format, constraints, and expected ranges. Output schemas are not documented anywhere in the visible code. Error messages are generic and do not guide LLMs on recovery steps. The tool descriptions, while present, range from adequate to vague and lack actionable context about when to use each tool and what prerequisites exist. No tool demonstrates the multi-step composition patterns needed for agent planning (e.g., takeoff implicitly requires arming, but this dependency is not documented). Security concerns are present: connection credentials are hardcoded in the source (tcp:127.0.0.1:5762), and no secret injection pattern is evident. The server operates primarily in Japanese (comments, error messages), which may limit LLM comprehension. Examining individual tools reveals a pattern of under-specified inputs and missing enum constraints that would force LLMs to guess at valid values.
Arm the aircraft for flight. Ensures the aircraft is in an armable flight mode (GUIDED if necessary) before arming.
Build and upload a star-shaped mission pattern with alternating outer and inner waypoint radii.
Change the aircraft flight mode to the specified mode.
Clear all waypoints from the aircraft's current mission.
Disarm the aircraft, stopping all motors.
Retrieve the current GPS position, altitude, and heading of the aircraft.
Retrieve current aircraft status including armed state, flight mode, and system status.
Output schemas are not documented for any tool. LLMs cannot determine what fields to expect in responses, forcing them to infer structure from descriptions alone, which is error-prone and prevents downstream tool chaining. (E.g., get_status and get_position return structured data but do not document field names or types.)
change_mode accepts a free-form 'mode' string with no enum constraint. The description lists valid modes (GUIDED, LOITER, STABILIZE, ACRO, ALT_HOLD, BRAKE, DRIFT, POSHOLD, SPORT) as text examples, but these should be declared as a JSON Schema enum. Free-form strings invite hallucinated mode names that will fail at runtime.
Numeric parameters lack min/max constraints. E.g., takeoff(altitude) has no documented range (what is min altitude? max?). upload_mission waypoints have lat/lon/alt as uncontrained floats. build_star_mission has outer_radius, inner_radius with no units or constraints. LLMs will pass arbitrary values that may be invalid or cause runtime errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 54 | 2026-07-28+ | v2 |
Command the aircraft in GUIDED mode to fly to a specific GPS coordinate at a given altitude.
Land the aircraft at the current location by switching to LAND mode.
Start executing the uploaded mission, switching to AUTO mode.
Arm the aircraft, switch to GUIDED mode, and initiate takeoff to specified altitude.
Upload a list of waypoints to create a mission for the aircraft to follow.
Parameter descriptions are absent or minimal. E.g., build_star_mission parameters are described only by name ('Center latitude in degrees', 'Outer star points from center'). What are the valid ranges? What is 'outer_radius' in absolute terms? Is it in meters? What is the minimum/maximum value? LLMs must guess, leading to invalid calls.
Tool descriptions lack actionable context and recovery guidance. Errors are not handled with explanatory messages. E.g., if change_mode fails, the error does not tell the LLM why (was the mode invalid? was the aircraft in flight?) or what to do next. No recovery patterns are implemented.
No tool compositions or multi-step workflows are documented. E.g., takeoff implicitly requires arming and mode change, but these dependencies are not stated in the tool descriptions. Build_star_mission uploads a mission but does not document that start_mission must be called afterward. LLMs cannot plan multi-step workflows effectively without this guidance.
Hardcoded connection credentials (tcp:127.0.0.1:5762) appear in the source code. Secrets should never be exposed in tool parameters or source code. Use environment variables or server-side secret injection to manage credentials securely.
Descriptions and error messages are in Japanese, which may limit LLM comprehension in English-first agent environments. Tool descriptions should be in English for broad compatibility.
Irreversible operations (clear_mission, disarm, land) lack confirmation or dry-run mechanisms. An LLM could accidentally clear a mission or land the aircraft. Critical destructive operations should support a confirmation step or require explicit approval.
Tool annotations (readOnlyHint, destructiveHint, idempotentHint) are not present. The MCP spec (2026-07-28) recommends annotating tools to signal read-only, destructive, and idempotent operations, which helps LLMs plan safer, more efficient workflows. E.g., arm and disarm should be marked destructiveHint; get_status and get_position should be marked readOnlyHint.