Take a simple request: “Return to the launch point.”
On a normal chat screen, it is a short line of text. In the Mini Talon project, the request can be associated with a function, checked by the application and, if permitted, passed to ArduPilot. From there, it may produce a real change in the aircraft’s behavior.
This article follows that path. It does not reproduce an operational interface or describe a particular flight. The aim is to understand what must happen before words can reach a physical machine.
In my previous article, Real-World AI Doesn’t Need Legs, I introduced the Mini Talon and the two AI systems used around it. I connected Claude to a limited set of operational tools through MCP. I used OpenAI GPT-6 Astra as the engineering and analysis model within an application that collects flight data, reconstructs missions and displays them in 3D. ArduPilot remains onboard and controls the aircraft.
The aircraft came first. I spent much more time assembling and testing it than writing the MCP layer or building the analysis application. I could only design those tools after I understood the machine they were meant to support.
From Request to Command #
“Return to the launch point” describes what the operator wants. It says nothing about motor power, control surfaces or the corrections needed to keep the aircraft stable.
Claude can associate the sentence with one of the functions I make available through MCP. It can then propose a tool call in a fixed format. My application and the MCP server check that request against the rules implemented in the system. If it passes those checks, the server can translate it into a MAVLink command for ArduPilot.
The language model never receives a direct connection to the motor or servos.
MCP works like a menu of named functions. Each function has a description and a set of expected inputs. The server will only execute the functions it exposes. An invented tool name, a missing parameter or a value outside the accepted range must be rejected.
This structure narrows what the model can ask the system to do. It does not determine whether the action is suitable for the aircraft at that moment. A value can have the right format and still be unsafe for the current situation.
The MCP tools specification says that users should be able to reject tool calls. It also requires servers to validate their inputs and apply appropriate permission checks. The protocol supplies a way to describe and call a function. The people building the application must define the operating limits around it.
For the Mini Talon, the path is therefore more detailed than a direct conversation between a person and an aircraft. Claude proposes a known function. The application checks it. The MCP server executes the permitted tool. MAVLink carries the resulting command, and ArduPilot decides how to handle it within its own flight logic.
When the System Must Refuse #
Before a request can continue, the system needs enough information to evaluate it. It must know which aircraft is involved, whether the available telemetry is recent enough and whether the requested function is permitted.
A system intended for operational use would also need to verify the identity behind the request and the permissions associated with that identity. Some actions would require a separate approval for one aircraft, one command and a limited period of time.
In the current prototype, confirmation is handled at application level. It is useful during development and testing, but it is not a complete authorization system. A confirmation field alone cannot prove that one identified person approved one specific action.
This distinction matters when software begins to affect physical equipment. In 2026, the US National Cybersecurity Center of Excellence published a concept paper on identity and authorization for software and AI agents. The work also considers auditing and the problem of attributing an agent’s actions to the correct person or organization.
These questions cannot be solved by the language model. They depend on how the wider system is designed.
My work on the aircraft made this clear very early. Before exposing a function, I needed to understand what that function meant for this Mini Talon. That required knowledge of ArduPilot, the mechanical configuration, the electrical system and the communication links. It also required practical experience with the aircraft on the bench.
The components were already old when I started the project. Most had been in my lab for more than ten years. Their age was useful because it removed some of the fascination associated with new hardware. A faster processor or a more expensive sensor would not have replaced the need to understand the aircraft.
The operating limits came from that understanding. They could not be obtained from a clever prompt.
Who Controls the Aircraft #
Claude can help with decisions that take seconds. ArduPilot must react continuously while the aircraft is flying.
The flight controller reads the sensors, stabilizes the aircraft and controls the motor and servos. These tasks stay onboard. A remote language model should not be part of this fast control loop.
The ArduPilot documentation describes a similar division for companion computers. They can receive MAVLink data and support higher-level decisions, while the flight controller remains responsible for the vehicle.
The communication path does not change this responsibility. A request may travel through a 4G connection or through a satellite link and a remote service. These links extend the distance from which the aircraft can be monitored. They can also become slow or unavailable.
The Mini Talon must continue under its onboard configuration if the network or the language model disappears. Flight stability cannot depend on a cloud service.
I first test new functions in simulation and on the bench. ArduPilot provides Software in the Loop, usually called SITL, for this purpose. It lets me check the path between an external request and the simulated aircraft without putting the real airframe at risk.
A successful SITL test has clear limits. It validates behaviour inside the simulation. It does not validate the airframe, the actuators, the radio links or the complete operational chain. Those parts require separate tests.
Checking What Happened #
Sending a command and observing its result are separate events.
A light switch offers a simple comparison. Pressing it, receiving an electrical signal and seeing the lamp turn on are three different moments. An aircraft introduces many more variables, but the principle remains the same.
The request may reach ArduPilot and be accepted. The flight mode may then change. After that, telemetry and logs can show how the aircraft responded.
The MAVLink command protocol makes this distinction explicit. A MAV_RESULT_ACCEPTED acknowledgment means that the flight controller considers the command valid and will attempt it. The aircraft’s resulting state must still be checked through telemetry or logs.
I use Astra after the flight, when I need to examine those records. The workspace combines the 3D reconstruction, synchronized plots, component information and the flight logs. It is not tied to one fixed view. I can bring different parts of the workspace forward as the question changes.
A question about the route leads to the 3D reconstruction. A question about power consumption leads to the electrical data recorded during the relevant part of the flight. A mechanical question may require a comparison between vibration data and information about the installed components.
Astra helps me compare the available evidence and develop possible explanations. A correlation in a log is not proof of a mechanical cause. I still need engineering knowledge and, when necessary, another controlled test.
For now, Astra works on engineering and post-flight data. Automatically connecting every MCP request to its exact physical result remains a separate integration step. Similar timestamps can help an investigation, but they do not prove that one event caused another.
I also exposed equivalent backend functions through a custom OpenAI GPT. This showed that the same application functions can be reached from more than one model interface. I kept the roles separate for clarity: Claude remains on the operational side, while Astra is used for engineering and post-flight work.
This division makes the architecture easier to understand. It would become a security boundary only if supported by separate identities and permission systems.
Beyond the Mini Talon #
The problem is no longer limited to one personal UAV project.
On August 27, 2026, Anthropic opened a research preview of the Model Hardware Standard, or MHS. It proposes a common device description and driver for programmable equipment. An AI system can access an MHS implementation through MCP or other software interfaces.
An MHS driver can describe the state of a device, the operations it supports and the limits that should be enforced. The project is still at an early stage, and its safety evaluations are being developed with the first users. It should therefore be read as a direction of research rather than a finished industrial standard.
Anthropic and Andon Labs also published Project Pilot. The project combined demonstrations with a small commercial quadrotor and Drone-Bench, a software benchmark that divided an indoor locate-and-follow task into five parts.
The aircraft moved at low speed in a limited environment. Even the strongest model did not perform every part consistently. The results do not establish general drone autonomy. They show that newer models are becoming more capable of assembling and using software functions created for common hardware.
As these capabilities improve, reducing human supervision may appear attractive. It saves time and makes systems easier to scale. It also places more responsibility on the software that checks permissions and limits.
My Mini Talon makes another part of this change visible. None of its main components is new. The aircraft has gained a different role because the software around it has changed.
The same pattern can appear in laboratories, factories, vehicles and non-civil applications. Existing machines do not need to be replaced before they can be connected to language models. In many cases, the hardware is already available.
The Mini Talon project taught me to define the roles before connecting the parts. Claude interprets a request. My application checks it. ArduPilot controls the aircraft. The recorded data helps me understand what happened afterwards.
These roles only make sense when they are based on knowledge of the real machine. I could write the MCP layer and the analysis application only after assembling, testing and understanding the aircraft. That order will remain important as AI systems move further into the physical world.