Start a job from a prompt

Tool descriptions say what each call does. They cannot say how to fly a whole job well: that the sim should idle while the agent thinks, that a hold is timed from the previous step’s settle, that QLOITER overshoots a fast climb, that a number goes in the answer only once the log has shown it. The server’s MCP prompts carry those habits, so a job starts with them instead of rediscovering them.

In Claude Code a server’s prompts appear as slash commands: type /mcp__mcardupilot__ and pick one. Other MCP clients list them wherever they show prompts. Every argument has a default except the log for postmortem.

Fly a hop

hop asks for a hover hop: take off in QLOITER, climb to height_m, hold for hold_s of sim time, land in QLAND.

/mcp__mcardupilot__hop height_m=15 hold_s=20 wind_mps=6 seed=7

The text it hands the agent includes a plan (one fly_steps program whose climb ends a metre short of the target), the pacing and reacting habits, and what to report. A non-zero wind_mps adds seeded Dryden gusts, so the flight can be flown again in the same air.

Compare two settings, or two builds

ab_test takes two parameter changes as NAME=VALUE lists and flies the same manoeuvre with each, in the same seeded wind, one after the other:

/mcp__mcardupilot__ab_test change_a="Q_A_RAT_RLL_P=0.25" change_b="Q_A_RAT_RLL_P=0.4" repeats=3

It asks the agent to confirm with log_compare that the parameters differ in exactly the change under test, and to weigh the gap between A and B against the spread within each. With one flight a side, gaps under about 5 percent count as not shown.

To compare builds instead, pass binary_a or binary_b. They reach open_sitl as its binary argument, and the agent names each session’s provenance (tree SHA, patch hash, build time) in the answer. open_sitl also takes tree, an ArduPilot tree whose build/sitl/bin/arduplane it flies.

Over HTTP

A server on the HTTP transport runs SITL binaries only from inside its configured trees (MCARDUPILOT_ARDUPILOT and MCARDUPILOT_BUILD_TREES), so a remote caller cannot point it at an arbitrary executable.

Read a log

postmortem takes a log the way log_summary does (a session id, a kept log’s name or a path) and an optional question:

/mcp__mcardupilot__postmortem log=20261003T213056Z-hover-10m-wind-west-6mps-seed7.BIN question="why did it settle above 10 m?"

The server reads the log before the prompt is returned, so the agent starts with every phase (mode, armed state, mission item, height, throttle, lift, current, energy) and the autopilot’s texts in order. Repeated texts are folded into one line with a count and a time span, so a pre-arm refusal every three seconds takes one line, not forty. The prompt then sends the agent to log_fields for narrow windows around the moments that matter, and asks it to keep what the log shows apart from what it concludes.

Check the workstation

preflight takes no arguments. It arrives with the live state:

• the SITL binary, its build time and tree SHA, and any sources edited since it was built
• who holds which instances, and ports taken with no lease
• this server’s open sessions
• kept logs against the budget
• whether the default tree may be built, and whether the build Python has ArduPilot’s packages

The agent is asked to say whether the machine is ready to fly and what to fix first, and not to change anything itself.

What every flight prompt asks for at the end

A plain paragraph for a person rather than an engineer; the few numbers from the log behind it, each with what it is; and the recipe, meaning the open_sitl arguments and the step program as JSON, so anyone can fly the same flight again.