ardupilot-mcp

Overview Schema Source Related Servers Discussions Admin

analyze_log

Read-onlyIdempotent

Run a deterministic diagnostic suite on ArduPilot .bin or .tlog flight logs to return severity-ranked findings, evidence, per-check results, and guidance.

Instructions

Run the full deterministic diagnostic suite over an ArduPilot .bin log (or a ground station's .tlog).

A .tlog is the telemetry the ground station received: a few Hz, the primary sensor and EKF core only, and gaps where the radio link dropped. Checks that would read a link dropout as a vehicle fault (log integrity, timing) are skipped on it; prefer the onboard .bin when the user has it.

Returns severity-ranked findings (each with concrete evidence AND official ArduPilot doc links), per-check results, a plain-language summary, and guidance. Read the cited references for the log's firmware version, call vehicle_profile for the airframe's physical configuration, and fold in any real-world details the user gives — then explain and cite sources. Every finding is grounded in the log; do not invent causes beyond them.

Input Schema

Name	Required	Description	Default
`path`	Yes

Output Schema

Name	Required	Description
`results`	No	Per-check outcomes, including skipped/errored checks.
`findings`	No	All findings, sorted by severity (most severe first).
`guidance`	No	How the LLM should use this report: read the cited docs for the log's firmware version, factor in the vehicle_profile (frame, motors, battery, power margin) and any physical details (weight, prop size) the user provides, then explain and cite sources.
`incident`	No	Onset/impact summary when the log shows an anomaly while armed; the full event list is available from the incident_timeline tool.
`info_count`	No
`references`	No	De-duplicated documentation links across all findings.
`warn_count`	No
`log_summary`	Yes
`summary_text`	No	Deterministic summary skeleton. The LLM enriches this; it never invents findings.
`checks_skipped`	No
`critical_count`	No
`logging_advice`	No	Copter/Heli: LOG_BITMASK bits that are off and whose data a check needed.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 19, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already declare read-only, idempotent, closed-world, but the description adds substantive behavior the annotations cannot: .tlog inputs skip integrity/timing checks and why, findings are severity-ranked with evidence and doc links, a `guidance` field is returned, and causes must not be invented beyond the log. That is real operational context beyond the safety profile.

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?

Front-loaded with the core action, then structured into input caveat, return shape, and agent workflow. The closing guidance sentence is slightly redundant with the workflow sentence, but every paragraph carries distinct information and there is no filler.

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

Completeness5/5

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

For a read-only one-parameter analysis tool with an output schema, the description covers the input caveats, the nature of the results, and the expected reasoning workflow. Nothing an agent needs to call it correctly is missing; return-value detail is present even though the output schema already carries it.

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?

The single parameter `path` has 0% schema description coverage, so the description must compensate. It implies accepted input formats (.bin or .tlog) but never states that `path` is a filesystem path to that file, nor any format or constraint details. Partial compensation only.

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?

States a specific verb and resource ('Run the full deterministic diagnostic suite over an ArduPilot .bin log'), and immediately distinguishes the two accepted inputs by explaining what a .tlog is versus the onboard .bin. It also names the related sibling vehicle_profile, so an agent can place it in the workflow without opening other schemas.

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

Usage Guidelines4/5

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

Gives a clear selection rule for inputs ('prefer the onboard .bin when the user has it') and a follow-up workflow (read cited references, call vehicle_profile, fold in user details). It does not, however, state when to reach for analyze_log versus siblings like log_summary, list_checks, or compare_logs, so no true exclusion guidance is present.

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

Deploy Server