mavlink-mcp

Overview Schema Source Related Servers Discussions Admin

goto_location

Command a flying drone to navigate to a specified GPS waypoint and loiter there. Sets latitude, longitude, altitude above launch, and optional heading, while enforcing geofence and altitude limits.

Instructions

Fly to a single waypoint and loiter there. The vehicle must be flying already (armed + taken off).

Args: latitude_deg: Target latitude (WGS84). longitude_deg: Target longitude (WGS84). relative_altitude_m: Target altitude above the launch point, in meters. Checked against the altitude ceiling. yaw_deg: Heading at the target, 0 = north (default 0).

Rejected in readonly mode. The target is also checked against the soft geofence around home (MAVLINK_MCP_GEOFENCE_RADIUS_M, default 200 m). Returns {"goto_started": true, "target": {...}} — travel is asynchronous; poll get_telemetry to track progress.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "latitude_deg": "<latitude_deg>",
      "longitude_deg": "<longitude_deg>",
      "relative_altitude_m": "<relative_altitude_m>"
    },
    "name": "goto_location"
  }
}

Input Schema

Name	Required	Description	Default
`yaw_deg`	No
`latitude_deg`	Yes
`longitude_deg`	Yes
`relative_altitude_m`	Yes

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Aug 18, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations were provided, so the description carries the full burden of behavioral disclosure. It clearly states the tool is destructive (it sends a movement command) by noting it is 'Rejected in readonly mode.' It also describes the asynchronous nature of the travel ('travel is asynchronous; poll get_telemetry to track progress'), which is critical behavioral context. It could have mentioned if the command is reversible (e.g., can it be cancelled mid-flight?), but the description is strong for a tool with zero annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single paragraph with an Args section and behavioral notes. It is front-loaded with the core action and precondition. Every sentence adds useful information. It is somewhat long at ~100 words, but this length is justified given the four parameters and the need to explain behavior. Minor inefficiency: the Args section could be more concise by relying on the schema, but since schema coverage is 0%, the verbosity is warranted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has 4 parameters with 0% schema coverage, no annotations, and an output schema exists. The description provides a complete understanding: it explains each parameter, notes the prerequisite (must be flying), mentions safety checks (geofence, altitude ceiling), and describes the return value format (including an example). However, it does not explicitly document all output schema fields (just a partial example), and it misses any mention of error conditions or failure scenarios (e.g., what happens if the geofence limit is exceeded). For a tool with this complexity, the description is nearly complete but has a small gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning the input schema provides no descriptions for the parameters. The description compensates by listing and explaining each parameter inline in the docstring. For example, it states 'yaw_deg: Heading at the target, 0 = north (default 0).' It also provides constraints: 'relative_altitude_m: Checked against the altitude ceiling.' This adds value beyond the raw schema, but the documentation is embedded in the text rather than structured. Baseline is 3 due to zero coverage, and the description meets that baseline adequately.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Fly to a single waypoint and loiter there.' The verb 'fly' and resource 'single waypoint' are specific, and the description distinguishes this tool from siblings like 'fly_mission' (which handles multiple waypoints) and 'return_to_launch' (which returns home). The title is missing, but the description compensates fully.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly states a prerequisite: 'The vehicle must be flying already (armed + taken off).' This tells the agent when it is appropriate to use this tool (only after arming and takeoff). It also mentions constraints like the altitude ceiling and soft geofence, guiding proper invocation. No explicit when-not-to-use is given, but the negative condition ('not armed/taken off') is strongly implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server