iNAV MCP Server

Overview Schema Source Related Servers Discussions Admin

check_failsafe

Analyze the failsafe configuration on iNAV flight controllers and explain the RC-loss response in plain English, flagging high-risk settings like disabled procedure or return-to-home without GPS.

Instructions

Read and explain the failsafe configuration (what happens on RC loss).

Reads all failsafe_* settings via CLI get failsafe, summarises the RC-loss procedure in plain English, and flags risky setups (procedure NONE; RTH without GPS).

NOTE: reads over CLI; exiting CLI reboots the FC, so this reboots and reconnects (~7s).

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "check_failsafe"
  }
}

Input Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.5Aug 2, 2026

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It honestly discloses a significant side effect: reading via CLI exits CLI and reboots the FC, causing a ~7s reboot and reconnect. It also explains what the tool does with the data (summarize in plain English, flag risky setups). This goes beyond minimal expectations, though it does not mention permissions or other potential behaviors.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded. The first sentence states the core purpose, the second details the operations, and the final note explains the reboot side effect. No wasted words; each sentence earns its place.

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

Completeness4/5

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

For a zero-parameter tool with no output schema, the description provides a solid picture: reads all failsafe settings, summarizes the procedure, and flags risks with examples. It could optionally describe the exact return format, but the summary and risk-flagging behavior are clear enough to set expectations. A slight gap is lack of detail on how the summary is presented, but overall it is reasonably complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100% (empty properties). The description adds no parameter-specific detail, but with no parameters, baseline 4 is appropriate. It does not need to compensate for any missing schema information.

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?

The description starts with a specific verb phrase 'Read and explain the failsafe configuration' and adds context 'what happens on RC loss'. It clearly distinguishes from sibling tools like set_failsafe (which configures) and get_status (general status) by focusing on failsafe-specific reading and explanation.

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

Usage Guidelines3/5

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

The usage context is implied: use when you want to understand the failsafe/RC-loss procedure. However, there is no explicit when-not-to-use or mention of alternatives (e.g., set_failsafe for changing settings). The description implies read-only analysis but does not distinguish when to choose this over other diagnostic tools.

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