Use with coding agents

Connect a coding agent to UXDuck on this computer to read vehicle telemetry, parameters and messages. The in-app AI chat is currently hidden in production; MCP works through your external coding agent.

Check the connection

Start UXDuck, then reconnect or restart the agent's MCP connection after adding it. Ask: “List the vehicles UXDuck can hear, and show the running version and link status.” It should use vehicle_list, daemon_about and link_list.

An empty vehicle list means the connection reached UXDuck but has no vehicle to inspect. Follow Connect a vehicle or Troubleshooting. A simulation running only inside a browser is separate from the installed UXDuck that uxduck mcp connects to.

What it may do

• Reading vehicles, telemetry, parameters and history needs no approval.
• Commands and changes wait for your approval in UXDuck, unless you already allowed that tool. The request offers Allow once, Allow for this connection, Always allow and Deny. An unanswered request is denied after 60 seconds.

Answer from a terminal:

uxduck approvals
uxduck approvals allow <id>
uxduck approvals deny <id>

Change tool permissions in Settings › Agents and tools. Read access can inspect what is happening without arming, changing modes or writing parameters.

Investigate a vehicle

Start with vehicle_list, telemetry_get, vehicle_messages and vehicle_history. Useful questions include:

• “Why won't this vehicle arm? Read its latest pre-arm messages and relevant parameters; explain the evidence before proposing a change.”
• “This altitude looks wrong. Compare the home, sea-level and terrain frames, their units and their timestamps.”
• “Is the vehicle still sending telemetry? Compare heartbeat age, link status and the age of the raw messages.”

Use param_get to read a parameter's actual value and describedBy before interpreting it. Parameter descriptions must match the firmware; a description from another version can mislead.

Compare telemetry over time

Ask: “Summarise battery voltage, GPS fix and EKF health over the last 60 seconds. Show the coverage and missing signals, and correlate any changes with vehicle messages.”

telemetry_window reads selected signals already captured in memory. It retains up to five minutes, subject to memory limits, and reports timestamps, units, numeric extrema and text-state summaries. It is useful for voltage dips, changes in GPS fix or rising vibration while you reproduce a problem.

The result includes coverage, missing keys and historyTruncated. Returned samples and distinct text states are bounded separately. A short window after starting UXDuck, a restart, or a limit can leave less evidence than you requested. Ask the agent to report these limits before drawing a conclusion. Numeric extrema cover retained observations even when fewer samples are returned.

mavlink_inspect shows raw-message freshness and rates; mavlink_history shows retained raw messages. vehicle_messages is a snapshot: call it again for newer messages. These tools do not analyse onboard DataFlash or ULog files, and capture can miss brief events between updates.

If setup fails

1. Run uxduck --version and uxduck status in a terminal. If uxduck is not found, finish installation and restart the coding agent so it sees the updated PATH.
2. Check that the MCP command uses the same --dev or --data-dir option as the running UXDuck. For example, use uxduck --dev mcp for a development installation.
3. After updating UXDuck, restart it when you are ready, then reconnect MCP. The running version from daemon_about is the one that supplies the tools; replacing the CLI alone does not update a running process.

MCP uses standard input and output; add it as an MCP server rather than running it as an ordinary chat command.