An LLM-Agnostic, MAVLink-Based Drone Command and Control Interface and Agentic Harness Using the Model Context Protocol

AI summary

Overview

Research area: Robotics / aerial systems — specifically the interface between large language models (LLMs) and unmanned aerial vehicles (UAVs), spanning the Model Context Protocol (MCP), MAVLink/MavSDK, the ArduPilot and PX4 autopilot stacks, and command-and-control security.

Technical level: Advanced. The paper assumes familiarity with drone autopilot firmware, the MAVLink messaging protocol, MCP server/client roles, and LLM tool-calling APIs.

Scope: The paper presents "DroneServer," an LLM-agnostic MCP-to-MAVLink command-and-control interface and from-scratch agentic harness that lets any MCP-capable LLM command ArduPilot- and PX4-based drones, evaluates it across eleven models in simulation and six models on real aircraft, and reports its security, safety, latency, and failure-mode measurements.

What This Paper Is About

Connecting an LLM to a drone has so far required a purpose-built bridge for each model and each drone platform — the paper calls this the "N × M" integration problem, where N models times M platforms each demand separate engineering. Separately, letting a non-deterministic language model issue commands to a physical aircraft over a network introduces both an attack surface and the risk that the commander itself hallucinates. The paper's goal is a single standardized interface that joins MCP (facing the model) to MAVLink (facing the aircraft), so that any MCP-capable LLM can command any MAVLink/MavSDK-compatible drone, with the LLM treated as an untrusted commander and safety enforced server-side.

Key Contributions

1. An LLM-agnostic, MAVLink-based MCP command-and-control interface. The paper claims this as the first LLM-agnostic and drone-agnostic (within the MAVLink/MavSDK fleet, i.e. ArduPilot and PX4) drone C2 interface built on MCP and MAVLink, demonstrated on real and simulated drones across multiple commercial and locally hosted LLMs. In simulation, eleven models from four providers flew the full mission suite on both firmwares; six distinct models from six providers flew physical aircraft.
2. A from-scratch agentic harness. The agentic loop — delivering the operator request and the 98 tool schemas to a provider API, executing tool-call requests against the server, feeding results back, repeating until the model declares the mission complete — uses no agent framework and no vendor agents SDK. In MCP terms it is a host application containing its own MCP client. Of 22 prior LLM–UAV systems surveyed, none reports a self-implemented, provider-agnostic tool-calling loop.
3. Near-complete MavSDK coverage, fully accounted. 98 tools covering 223 of 238 client-side MavSDK methods, with the remaining 15 documented as not-applicable with reasons (238/238 addressed). 61 of the 98 were exercised against a real autopilot, 58 were chosen by a model in the scored campaigns, and 3 carry no targeted evidence anywhere in the work.
4. A security and command-governance architecture treating the LLM as an untrusted commander, with zero public network exposure (externally verified), per-command authorization and validation, an independent geofence, and measurements of what that governance costs.

Additional named contributions include a server-side mission-state architecture for continuous flight, a quantitative multi-LLM/multi-firmware evaluation, and an empirical capability boundary between single-step and multi-step missions.

Main Findings

• Near-complete SDK coverage: 98 tools implement 223 of 238 client-side MavSDK methods; the 15 not-applicable methods break down as 9 duplicate subscription streams, 4 typed-mission variants superseded by the firmware-agnostic raw/QGC mission path, and 2 component_information methods unimplemented in mavsdk_server itself (an upstream gap).
• Coverage is a code-surface claim, not a capability claim: of the 98 tools, 91 carry tool-specific evidence at one or more of three layers, 61 were exercised against a real autopilot by the SITL integration suite, 58 were chosen unprompted by a model in the scored campaigns, 29 carry evidence at all three layers, and 7 carry none — of which 3 carry no targeted evidence anywhere in the study.
• Multi-model benchmark performance: over 1,000 simulated flights ran a ten-mission LLM-UAV control benchmark, and eight of eleven models complete 90.0–100% of its six flying missions.
• Geofence safety result: no aircraft left the permitted zone in 110 geofence-violation trials.
• Adversarial safety suite: the untrusted-commander path passes 29/29.
• Long-mission durability: a scripted client's 37.8-minute autonomous mission (no language model in the loop) survived a 4-minute disconnection, demonstrating server-side mission state. When a model instead supervises the same mission, six of the nine scored trials fail — the paper reports the two results together.
• Real hardware: the unmodified server commanded three quadcopters, GPS-guided and GPS-denied; five providers' models flew an unseen mission, ten of ten.
• Single-step versus multi-step capability boundary: every leading model flies the short, single-command missions of the suite; the multi-step missions separate them, and the separation is architectural rather than a matter of model scale. The mission's defining state (origin, legs, completion criterion) lived only in the model's context window while the tools reported in mission-level vocabulary that only leg-level state backed, and models downstream of those reports obeyed them.
• Failure attribution is separated: the paper reports a failure taxonomy over every failed trial, the share of failures produced by its own instrumentation (separated from the models' own), and a re-flight of the affected trials on a fixed server as a check on that attribution.
• Firmware divergences are real and absorbed by the MCP layer: MAV_AUTOPILOT = 12 on PX4 versus 3 on ArduPilot; offboard and follow-me work on PX4 but are inert on ArduPilot; ArduPilot serves TCP and accepts multiple clients while PX4 is UDP-only and latches to the first client.
• Validation scale: 937 unit tests and 116 SITL integration tests, all passing at the released tag; continuous integration runs linting, formatting, type checking and the 937 unit tests on every push and pull request, while the 116 SITL tests run nightly and on every push to the main branch against the pinned ArduCopter 4.5.7 Docker simulator. The single longer-than-ten-minute long-mission test is deliberately excluded from that gate and run on demand.
• Token cost: the 98 tool schemas are roughly 22k tokens resent every turn, with an observed 58–99% provider-side prompt-cache hit rate — reported as what makes the interface economical.
• Where the field stands: of 22 surveyed prior LLM–UAV systems, 12 are hand-coded to a single LLM, 8 are custom-built but agnostic in principle, only one uses an open standard (an MCP gateway, simulation-only), and none combines an open-standard model interface with a physical aircraft. Twelve of the 22 have no agentic loop at all; five implement their own closed loop but parse free text or JSON rather than provider tool calls; exactly three place structured tool calls in the loop, and all three delegate that loop to third-party software, in simulation.
• Hardware breadth in the literature: of the literature's 59 demonstrated model-family cells, only 9 involve a real aircraft, 4 of those 9 ran the model locally, and only one prior system flies more than a single model family on hardware. The broadest prior matrix, six families, is entirely simulated and entirely cloud-hosted. Where models run splits 23 local, 24 cloud-hosted, and 12 undisclosed.
• Comparison to the SINT Protocol: it specifies an adversary model and capability-based command authorization for the LLM-to-actuator path, ships a MAVLink bridge for PX4 and ArduPilot, and measures 5.1 ms p99 gateway latency, but its network isolation is a deployment pattern it "supports — but does not by itself enforce," it reports no adversarial results of its own, and it has no real-robot evaluation.
• Comparison to the Device Context Protocol: that work elicited 675 tool calls from five LLMs across four vendors and reports that raw MCP schema validation rejects none of 138 capability-escalation attempts and 1% of prompt-injection attempts, against 100% and 78% for its own capability- and range-typed manifest — but its target is the constrained microcontroller rather than the aircraft.
• Onboard-compute trade-off: one compared onboard approach achieves 5–6 tokens/s for a 14B model at 220 W peak, trading reasoning depth and endurance for connectivity-independence; this work makes the opposite trade and relies on autopilot failsafes rather than the link for safety.
• Taxonomy position: on an existing five-level "LLM-as-Parser to LLM-as-Autopilot" taxonomy, this interface operates at Level 4 — the LLM directly issuing flight commands to a real aircraft under a human safety pilot.

Methodology in Plain English

The authors built a server, called DroneServer, that speaks two languages at once. On one side it speaks MCP, the protocol an AI host application uses to discover and call tools, so any MCP-capable LLM can use it without custom glue code per model. On the other side it speaks MAVLink through MavSDK, the standard way ground software commands ArduPilot and PX4 aircraft. The model never speaks MCP itself; a host application the authors wrote from scratch runs the agentic loop, holding its own MCP client and translating between the provider's function-calling API and the server.

The 238 client-side MavSDK methods were mapped into 98 tools rather than one tool per method. The mapping follows three stated principles: split tools by safety relevance and reference frame (for example, clearing a geofence is a separate tool from uploading one because it is safety-relevant and must be tiered independently); compress sprawling read-only families (the camera plugin's 36 methods become 6 tools); and add task-level tools MavSDK lacks, such as an explicit wait/monitor tool, because without it a model will issue takeoff and goto in immediate succession and fly into the ground before reaching altitude.

Every command crosses a server-side safety pipeline before reaching the vehicle — tiers, confirmation handshakes, an independent geofence, and an append-only JSONL audit log — and the guard fails closed, returning a structured refusal with a rule id and remedy rather than an exception. The architecture separates a stateless command plane from a stateful telemetry and mission-state plane, which is how a long mission survives a client disconnection. The entire deployment sits behind a WireGuard/Tailscale overlay with zero publicly reachable ports, verified by external scan, and the only traffic crossing that boundary is the host's outbound API calls to the LLM provider.

Evaluation ran in two modes: interactive (a person typing to an MCP-capable chat client) and scripted (an unattended harness driving the model through a provider's API). In every LLM trial reported, all commands originate with the model — the harness delivers one fixed mission prompt, then records and scores, and never issues a flight command or paces the model. Testing spanned ArduPilot and PX4 software-in-the-loop simulation and real aircraft, with repeated trials, standardized evaluation tasks, prompt sets, tool-call traces, and safety-intervention logs. Note that the supplied paper text is truncated during Section 3.7, so the detailed mechanics of the mission-state machine, along with the full simulation and hardware result tables of Sections 6 and 7, are not available in the content summarized here.

Why This Matters

This work reframes drone–LLM integration as a protocol problem rather than a per-project engineering problem. Instead of writing a bespoke bridge for every model-platform pair, the paper argues that one MCP server driving MAVLink collapses the N × M cost to a thin set of per-provider adapters, and it demonstrates that claim across eleven models from four providers in simulation and six models from six providers on physical aircraft. It also makes security a headline contribution rather than a defensive afterthought, specifying a threat model, implementing network- and command-layer controls, and reporting adversarial-test results and their overhead — a combination the authors state they do not find in the surveyed LLM–UAV literature, where security reporting is almost uniformly absent.

Real-world applications:

• Search-and-rescue and disaster response, where operators issue plain-language missions and the aircraft executes them while an independent server-side geofence constrains where it can go.
• Inspection and survey flights, where the server-side mission-state architecture lets a long autonomous mission continue through a client disconnection — the paper's 37.8-minute mission survived a 4-minute disconnection.
• Multi-vendor fleet operations, where the same unmodified server commands different airframes and firmware stacks (the paper reports three quadcopters on real hardware, GPS-guided and GPS-denied).
• High-stakes constrained environments where the security posture matters: the paper positions drone navigation among the high-stakes MCP domains, and DroneServer's zero-public-port deployment is a concrete answer to that.

Industry relevance: MCP was introduced by Anthropic in 2024 and contributed to the Linux Foundation's Agentic AI Foundation in 2025; MAVLink, ArduPilot, and PX4 span millions of vehicles. Joining the two open standards means the interface reaches most of the open-source fleet at once rather than one vendor's aircraft, and any MCP-capable host gets all 98 tools with no glue code. The paper frames the architecture as a scaffold for a higher-level drone-LLM operating system and a path to agent swarms commanding drone swarms under one security umbrella. The code is open source at the project's GitHub repository, and the materials are deposited at Zenodo under DOI https://doi.org/10.5281/zenodo.22310050.

Future Directions

• Aligning the transport with MCP's stateless revision. The paper implemented DroneServer against the session-based MCP transport current at the time (the initialize / tools/list handshake). MCP's specification revision of 28 July 2026 moved the transport itself to a stateless model, removing that handshake so each call is self-contained. The authors name aligning DroneServer's transport with that revision as a natural item of future work and treat the convergence as external validation of their design split.
• Swarm command. The abstract describes the architecture as a path toward agent swarms commanding drone swarms under one security umbrella — a direction stated but not demonstrated in the available content.
• Extending model and hardware breadth. Eleven models from four providers ran in simulation and six from six providers on hardware; the paper's own account of what the field has left unexplored (breadth of models through one unchanged interface, and flying more than one model family on real aircraft) frames further expansion as the natural next axis.
• Carrying the mission-status design principle forward. The paper derives a design principle from its failure analysis — that the component owning the state must be the component reporting mission status — after finding that its tools reported in mission-level vocabulary while only leg-level state backed those reports. Applying that principle across the tool surface is an open engineering question the work raises.

The paper's Section 8 discussion of limitations and Section 9 conclusions are outside the supplied content, so the authors' own enumerated limitations are not reported here. Likewise, specific latency measurements are named as part of the released tests and datasets but their values are not present in the available text, aside from the 5.1 ms p99 gateway latency attributed to the prior SINT Protocol.

Target Audience

This paper benefits most researchers and engineers working at the intersection of LLM agents and physical robotic systems: drone-autonomy researchers looking for a standardized command interface, robotics and embedded engineers working with ArduPilot, PX4, MAVLink, or MavSDK, and security researchers interested in command governance for safety-critical vehicles driven by non-deterministic models. It is also relevant to MCP and agent-infrastructure developers, since it is a worked example of building an MCP host application and server from scratch without an agent framework, and to practitioners evaluating whether MCP is a viable control plane for hardware rather than only for data and software tools. The advanced technical level means readers should already be comfortable with autopilot firmware, protocol stacks, and tool-calling agent architectures.

Authors’ abstract

Artificial intelligence integrated with drone command and control (physical AI) offers a route to autonomy through large language models (LLMs), yet a unified LLM-to-drone interface has been missing. We present an LLM-agnostic command-and-control interface and agentic harness joining the Model Context Protocol (MCP) to MAVLink, the near-universal drone command-and-telemetry standard: "DroneServer" gives any MCP-capable LLM command, telemetry, mission, and safety functions over ArduPilot and PX4. Its 98 tools cover 223 of 238 client-side methods of MavSDK, MAVLink's library; 61 of the 98 were exercised in software-in-the-loop. We treat the LLM as an untrusted commander: zero public ports (externally verified); every command validated server-side (tiers, confirmation handshakes, independent geofence, audit log), exercised by an adversarial safety suite. Server-side mission state resolves the "fire-and-forget" mismatch: a scripted client's 37.8-minute mission survived a 4-minute disconnection. Over 1,000 simulated flights ran a ten-mission LLM-UAV control benchmark; eight of eleven models complete 90.0-100% of its six flying missions, and no aircraft left the permitted zone in 110 geofence-violation trials. On real hardware, the unmodified server commanded three quadcopters, GPS-guided and GPS-denied; five providers' models flew an unseen mission, ten of ten. The tests and datasets include: repeated trials, standardized evaluation tasks, success/failure statistics, latency analysis, uncertainty treatment, comparative benchmarking across models/platforms, prompt sets, mission complexity, tool-call traces, safety-intervention logs, and safety-performance assessment. The architecture is a scaffold for a higher-level drone-LLM operating system where plain-language commands realize complex missions, and a path to agent swarms commanding drone swarms under one security umbrella.