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

With no annotations provided, the description fully carries the burden of behavioral disclosure. It meticulously describes the atomic operation: commands are applied in one CLI session, backed up first, saved to EEPROM, reboots, auto-reconnects, verifies by read-back, and rolls back all changes on failure. This is exceptional transparency.

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

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

The description is well-structured and front-loaded with the core purpose. The subsequent paragraphs add essential behavioral detail (atomicity, rollback, verification), prerequisites (gates), and parameter explanation (Args). Every sentence earns its place, with no redundancy or fluff.

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

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

Given the tool's complexity (atomic apply, save, reboot, rollback) and the absence of annotations or output schema, the description is remarkably complete. It covers prerequisites, side effects, failure handling, and the parameter's role. Nothing critical is missing for an agent to use the tool effectively.

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

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

The schema provides zero description coverage for the 'confirm' parameter, but the description's 'Args' section fully explains it: 'True to apply+save+reboot. Default False = dry-run (shows commands).' This completely compensates for the lack of schema documentation, adding precise semantics that the schema omits.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Apply the declared aircraft profile to the FC, then save and reboot.' This specifies a concrete verb+resource+outcome, and distinguishes it from siblings like define_aircraft (which defines the profile) and save_and_reboot (which is generic). It also highlights the atomic nature of the operation, adding further clarity.

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

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

The description provides explicit 'Gates' that must be met: a profile must be defined, the FC must be connected and not armed, and confirm=True is required. It also notes that dry-run is the default. While it clearly states prerequisites and the safe default, it does not explicitly name alternative tools or when to use them instead, so it falls just short of a 5.

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

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

It discloses that the tool computes µs ranges, writes one aux assignment per mode, and defaults to dry-run, plus critical gates. With no annotations, this description carries the full burden and meets it well.

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

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

The description is structured and front-loaded: first sentence states purpose, then behavioral notes, then a clear Args list. No filler sentences.

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

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

It covers purpose, behavior, preconditions, and parameters comprehensively. It omits return value/error handling, but the absence is not critical for a tool that is primarily an action. Overall, it's near-complete.

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

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

Schema has no descriptions (coverage 0%), so the description compensates by detailing each parameter: switch_channel's 1-based AUX numbering, switch_positions' allowed values (2, 3, 6), mode_per_position's key formats and example, and confirm's default. This is high-value addition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Map a multi-position switch's detents to flight modes in one call.' It clearly distinguishes from siblings like set_flight_mode by focusing on multi-position mapping and mass assignment.

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

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

It states the context: 'Dry-run by default' and 'Gates: connected, not armed, auto-backup before write,' which inform when it's safe to run. It does not explicitly name alternative tools, but the one-call mapping purpose is clear.

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

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

With no annotations, the description carries the full burden and does well: it discloses side effects (iNAV reboot and auto-reconnect), the exact command run ('diff all'), the output file pattern, and a return value ('rebooted': True). Minor gaps include whether a connection is required and any potential errors, but the disclosure is solid.

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

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

The description is concise and front-loaded with the primary purpose. Each sentence adds value: the command, output location, iNAV behavior note, and argument explanation. No redundant or verbose text.

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

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

Given the tool's simplicity and lack of annotations, the description covers the essential aspects: action, mechanism, side effects, return value, and argument. It could mention prerequisites like being connected, but that is likely implicit from sibling tools. Overall, adequate for reliable invocation.

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

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

The schema only lists 'label' with no description, but the tool description clearly explains it as 'Optional suffix added to the filename for easy identification.' This fully compensates for the 0% schema coverage and adds meaningful semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear verb+resource+destination: 'Save the current FC config to a timestamped backup file.' It also specifies the implementation ('Runs diff all') and output location, distinguishing it from sibling tools like restore_config and list_backups.

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

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

The purpose implies when to use the tool (to back up config), but it does not explicitly contrast with alternatives such as restore_config or list_backups, nor does it mention any exclusions or prerequisites. Usage context is evident but not stated explicitly.

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

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

With no annotations, the description carries the full burden. It states this is a read operation ('Read') and lists what it returns, implying no side effects. It also discloses the need for an active connection, which is important behavioral context.

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

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

The description is concise and well-structured: a single-sentence summary, a clear bullet-like list of return values, and a critical usage prerequisite. Every sentence earns its place with no redundancy.

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

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

Given the tool's simplicity and lack of parameters, the description is nearly complete. It covers what is returned and the necessary connection prerequisite. A return format or typical usage example would add polish but isn't strictly required for an agent to invoke it correctly.

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

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

The tool has zero parameters, so the baseline is 4. The description adds meaning by explaining what the tool will do and what data it returns, compensating for the absence of a parameter schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb ('Read') and resource ('flight-controller identity over MSP'). It enumerates the returned data (variant, firmware version, board name, etc.), making it easy to distinguish from siblings like get_status or read_sensors.

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

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

The description explicitly says 'Requires an active connection (call connect first)', which is a clear prerequisite and guides usage order. It doesn't mention when not to use it or alternatives, but the context is clear and practical for an agent.

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

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

With no annotations present, the description carries full burden and does well. It reveals the underlying MSP command, the ~2s sampling, automatic EEPROM save, no reboot needed, physical setup requirement, and dry-run behavior based on confirm. This goes beyond the schema and gives the agent critical safety and side-effect information.

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

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

The description is concise, front-loaded with the purpose, and each subsequent sentence adds necessary detail (protocol, EEPROM persistence, physical prerequisites, gates). The line break for the 'BEFORE running' warning improves scannability.

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

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

For a one-parameter, no-output-schema tool, this description covers purpose, usage, procedure, side effects, and preconditions comprehensively. It also distinguishes from its sibling calibrate_magnetometer. No gaps appear for execution.

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

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

The single boolean parameter `confirm` is explained: true executes calibration, false performs a dry-run. This adds essential meaning beyond the schema field name 'Confirm', which would otherwise be ambiguous.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description explicitly names the action and resource ('Calibrate the accelerometer') and ties it to a concrete outcome ('Fixes most 'not level' / 'accel not calibrated' arming blocks'). This clearly distinguishes it from sibling tools like calibrate_magnetometer.

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

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

The description states specific conditions for use: when the aircraft has 'not level' or 'accel not calibrated' arming blocks, and provides prerequisites (level surface, don't move, gates). However, it does not explicitly mention when not to use or alternatives such as why_wont_it_arm or diagnose, so it earns a 4.

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

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

With no annotations provided, the description carries the burden of disclosure. It explains the protocol (MSP_MAG_CALIBRATION), the 30-second rotation requirement, automatic saving, and the dry-run behavior when confirm is not true. This is solid transparency for a simple calibration action.

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

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

The description is concise and structured in three short paragraphs: purpose, procedure, and gates. Every sentence adds value and is front-loaded with the key purpose.

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

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

Given a single boolean parameter, no output schema, and no annotations, the description covers purpose, procedure, timing, result handling, and preconditions. It lacks details on possible errors or post-calibration verification, but those are not critical for this simple tool.

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

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

The only parameter, confirm, is fully explained in the description: 'confirm=True (dry-run otherwise)'. This adds meaning beyond the schema's bare definition and clarifies the exact behavioral difference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool calibrates the compass/magnetometer, using a specific verb and resource. It distinguishes from the sibling calibrate_accelerometer by explicitly naming the magnetometer and describing the rotation procedure.

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

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

It provides explicit prerequisites: 'Only useful if a compass is installed' and gates: 'connected, not armed, confirm=True (dry-run otherwise)'. While it doesn't explicitly contrast with sibling calibration tools, the conditions and dry-run behavior give clear guidance on when to use it.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It reveals the mechanism ('Runs diff all via CLI, parses key settings') and the specific ARM mode check, which adds useful context. However, it does not explicitly state that the operation is read-only, nor does it describe the output format or any side effects, leaving some ambiguity for an agent.

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

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

The description is three tight sentences with the main action front-loaded in the first sentence. The 'Useful after' clause adds practical guidance without redundancy, and there is no filler or repeated information.

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

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

For a read-only diagnostic with no parameters, the description covers the source of truth, the method, the scope of checks, and the typical use case. It lacks explicit output format details, but since no output schema exists, the description is sufficiently complete for tool selection and invocation.

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

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

The tool accepts zero parameters, so the baseline is 4. The description correctly avoids inventing parameters and focuses on the tool's behavior, which is appropriate for a no-argument check command.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Compare' and identifies the exact resources: the FC's actual configuration vs the declared aircraft profile. It distinguishes itself from siblings like apply_aircraft_setup by framing the action as a verification step, and it references define_aircraft() to clarify the source of the declared profile.

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

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

It explicitly states when to use the tool: 'Useful after apply_aircraft_setup() or to sanity-check a partially configured FC.' This provides clear contextual guidance. It does not mention when not to use it or explicitly name alternatives, but the intended timing is well understood.

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

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.

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.

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.

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.

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.

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.

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

With no annotations available, the description fully discloses key behaviors: dry-run default, confirmation requirement, safety gates (connected, not armed), and auto-backup before write. It also explains the underlying mechanism (CLI 'aux'). This is comprehensive for a mutation tool and exceeds typical disclosure.

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

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

The description is concise and front-loaded with the main purpose, then dry-run behavior, gates, and argument details. Each sentence delivers essential information without waste, making it easy to parse quickly.

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

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

The description covers purpose, behavior, gates, and parameters, which is complete for this tool's complexity. However, it doesn't specify what happens after a successful write (e.g., return value or automatic save) or behavior when mode_name is not found, leaving minor gaps.

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

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

The schema has no descriptions (coverage 0%), but the description compensates fully. mode_name is explained with exact format and examples, and confirm is described as 'True to apply. Default False = dry-run.' This provides complete meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool removes all switch assignments for a flight mode, using a specific verb ('Remove') and resource ('switch assignments for a flight mode'), and adds context via 'disables its slots via CLI aux'. This distinguishes it from sibling tools like assign_switch or set_flight_mode.

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

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

The description provides clear usage context, including dry-run default, the confirm flag to apply, and prerequisites (connected, not armed, auto-backup). While it doesn't explicitly name alternatives, the purpose statement makes the tool's role clear, and the gates give conditions for use.

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

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

With no annotations, the description fully carries the behavioral burden. It discloses critical details: FC reboot on CLI exit, auto-reconnection, persistence behavior for writes, motor safety gating (props_removed, armed refusal, never saved), and the difference between confirm_for_writes and props_removed.

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

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

The description is long but every sentence is essential for a raw CLI tool with dangerous motor capabilities. It is well-structured with clear paragraphs for general behavior, safety warnings, usage preference, and parameter details. No fluff.

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

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

For a tool with high complexity and zero annotations, the description covers all essential context: what the tool does, when to use it, safety hazards, persistence mechanics, and parameter semantics. An output schema exists, so return values need not be described. This is fully complete.

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

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

Schema description coverage is 0%, but the description provides a dedicated Args section explaining each parameter: command (without trailing newline), confirm_for_writes (allow and persist writes), and props_removed (safety for live motor test). This fully compensates for the lack of schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: "Raw CLI escape hatch — run any iNAV CLI command directly." It also distinguishes itself from siblings by explicitly recommending dedicated write tools for normal use and positioning this as the fallback for one-off commands.

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

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

Provides explicit when-to-use guidance: "Prefer the dedicated write tools (they back up and verify). Use this for one-off commands the other tools don't cover." It also differentiates read-only, write, and motor command use cases with precise gating requirements.

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

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

With no annotations provided, the description fully discloses critical behaviors: the cost of each CLI session (reboot + USB re-enumeration), the session exit semantics (no save for reads, save once for writes), the all-or-nothing policy on FC rejection, and rejection of motor commands. It also mentions the backup and return values, giving the agent a complete mental model of side effects and safety.

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

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

The description is front-loaded with the core purpose in the first line, then uses clear section headers (Args, Behaviour) and bullet lists to organize dense information. Every sentence earns its place, explaining the why (reboot cost), the how (batch behavior), and the safety mechanisms without redundancy.

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

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

Given the tool's complexity (batching, side effects, safety semantics) and lack of output schema, the description is remarkably complete. It covers the reboot implications, read vs write behavior, all-or-nothing persistence, motor command restrictions, and explicitly states what the return value contains, so the agent has all necessary context to invoke it correctly.

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

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

The input schema only lists types and defaults, but the description adds meaningful semantics: 'commands' is an 'Ordered list of CLI commands' and 'confirm_for_writes' must be set to run a batch containing writes. It explains why the confirmation is needed (write safety) and that a backup is taken, going far beyond the minimal schema definition.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Run MANY CLI commands in ONE CLI session — a single reboot for the whole batch,' which is a specific verb+resource statement that clearly distinguishes this tool from the single-command 'cli' sibling. It also contrasts with dedicated write tools by positioning itself as the escape hatch for ad-hoc multi-command work.

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

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

Provides explicit guidance: 'Prefer it for any ad-hoc multi-command work' and notes that dedicated write tools already batch internally, so this tool is only for other cases. It also tells users to use cli(..., props_removed=True) for motor tests, offering an alternative. This is clear when-to-use and when-not-to-use guidance.

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

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

Without annotations, the description carries the full burden. It discloses that the operation is an 'atomic CLI write', that confirm='True to apply (save+reboot)', and 'Dry-run otherwise.' It also mentions 'auto-backup' and that the FC validates the provider. This gives significant behavioral detail beyond the schema.

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

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

The description is concise, using a single purpose line, a compact arg list, and a gates line. Every sentence contributes information without redundancy.

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

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

The description covers purpose, parameters, usage constraints (gates), and post-application guidance. Given there is no output schema, it appropriately focuses on the action's behavior and follow-up. It's complete for a configuration tool of this complexity.

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

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

Schema coverage is 0%, so the description must explain the parameters. It does so for each: provider with examples, sbas with options and optionality, and confirm with behavior. This exceeds what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states 'Enable the GPS feature and set the receiver provider / SBAS (atomic CLI write).' This is a specific verb+resource combination that clearly distinguishes this tool from sibling tools like read_gps and other configuration tools.

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

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

The description lists explicit gates: 'connected, not armed, auto-backup.' This tells the agent when the tool can be used and prerequisites. It also advises 'After applying, give the GPS time to acquire satellites and check read_gps().' This provides clear post-conditions and a follow-up action, though it doesn't name alternative configuration tools.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does disclose the return fields (board variant, firmware version, etc.), but it fails to mention the side effect of leaving the connection open or the need to call 'disconnect' afterward. This is a significant behavioral trait that is not addressed.

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

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

The description is well-structured with a concise opening sentence, a clear 'Args' section, and a 'Returns' list. It is appropriately sized for the information conveyed, with no superfluous words or repetition.

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

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

For a simple connection tool with only two parameters and no output schema, the description covers the purpose, parameters, and return values thoroughly. It falls short only in not explaining when to use it in the broader workflow (e.g., before other commands) or the need to disconnect, but overall it is largely complete for a basic connect operation.

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

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

Despite 0% schema description coverage, the description thoroughly explains both parameters. It provides concrete examples for 'port' (e.g., 'COM3', '/dev/ttyACM0') and explains the default 'baud' (115200) by referencing iNAV's default. This adds significant meaning beyond the raw schema definitions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Open the serial connection to the FC and return board identity', using a specific verb ('open') and resource ('serial connection to the FC'). It distinguishes itself from sibling tools like 'board_info' by emphasizing the connection establishment, and from 'disconnect' by being the inverse operation.

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

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

The description implies the tool is used to establish a serial connection, but it does not explicitly state when to use it versus alternatives like 'find_fc' or 'list_serial_ports'. There is no mention of prerequisites (e.g., knowing the port) or exclusions, so usage context is only implied rather than clearly guided.

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

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

With no annotations present, the description fully discloses behavior: it is an offline planner with no side effects on the FC, generates commands, and returns a plan dict containing profile, commands, summary, and warnings. This gives the agent a clear model of what happens when invoked.

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

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

The description is long but well-structured with an Args section and Returns section. The first sentences establish the core purpose and usage context, and the parameter list is formatted for quick scanning. Every sentence earns its place given the 9 parameters.

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

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

The tool has 9 parameters, no annotations, and no output schema. The description compensates by documenting all parameters, return values, and workflow integration with apply_aircraft_setup(). It is fully self-contained and leaves no critical gaps for the agent to guess.

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

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

Schema description coverage is 0%, so the description carries full parameter meaning. It explains every parameter with types, allowed values (e.g., wing_type options, esc_protocol list), defaults, and purpose (e.g., motor_poles default 14 with a verification note). This goes far beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it 'Defines the aircraft hardware profile and generates a configuration plan,' which is a specific verb+resource combination. It differentiates itself from sibling tools by emphasizing it is an OFFLINE planner and instructing to call apply_aircraft_setup() next.

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

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

The description explicitly says when to use: 'Call it first to review the generated CLI commands, then call apply_aircraft_setup() to apply.' It also states 'no FC connection required,' providing clear context for when it is appropriate and which alternative to use subsequently.

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

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

With no annotations, the description carries the full burden. It discloses that the tool collects data, runs all diagnostic rules, and returns a prioritized problem list with fixes. It does not explicitly state whether the tool is read-only, but the diagnostic framing and the absence of mutation language are reasonably transparent. It adds useful detail beyond a simple 'diagnose' label.

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

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

The description is compact, front-loaded with the flagship role, and uses a concise bullet-like list to convey the collected items. Every sentence adds information: scope, inputs collected, processing, output, and usage trigger. There is no filler or repetition.

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

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

For a zero-parameter diagnostic tool with no output schema, the description is complete. It explains the tool's purpose, the data it uses, the kind of results it produces, and when to invoke it. Nothing essential is missing for an agent to select and use it appropriately.

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

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

The tool has zero parameters, and the schema has no properties, so the baseline is 4. The description adds value by explaining what data is gathered during the diagnostic sweep, which indirectly clarifies why no parameters are needed. There is no schema coverage issue.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb phrase ('Full diagnostic sweep') and identifies the resource/responsibility as the 'flagship troubleshooter.' It enumerates the exact domains covered (arming flags, sensor health, RC channels, battery, GPS, attitude, mode assignments) and the output (prioritized problem list with concrete fixes), which distinguishes it from sibling tools like why_wont_it_arm or get_status.

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

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

The description provides an explicit usage trigger: 'Use this when something is wrong but I'm not sure what.' This gives clear contextual guidance. It does not explicitly exclude or reference alternatives, but the use case is distinct enough, and the guidance is practical.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It states the action and target, but does not disclose side effects, idempotency, or behavior when the connection is already closed. This is acceptable for a very simple tool but lacks deeper context.

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

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

A single, clear sentence that is front-loaded and free of any filler. Every word contributes to communicating the tool's purpose.

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

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

For a 0-parameter, no-output-schema tool, this description is nearly complete. It clearly names the action and target, though it could benefit from a note about what happens if no connection is active or whether this aborts other operations.

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

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

The tool has zero parameters, so the description need not add parameter-level detail. Baseline for 0 parameters is 4, and the empty schema and 100% vacuous coverage mean no information is missing.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Uses specific verb 'Close' and resource 'serial connection to the FC', clearly identifying the action and target. This distinguishes it from sibling tools like 'connect' and 'find_fc' by describing exactly what is disconnected.

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

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

No guidance on when to use this tool versus alternatives such as 'connect' or 'save_and_reboot'. The description states what it does but does not mention when it is appropriate to disconnect or any prerequisites.

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

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

Since no annotations are provided, the description carries the full burden. It discloses the mechanism ('Briefly opens each likely USB-serial port and asks for MSP identity'), the return value ('returns the ports that answered as an FC (variant + firmware)'), and a safety consideration ('avoids poking unrelated devices like Bluetooth/modems'). It does not mention potential edge cases like timeouts or no-FC-found behavior, but the core behavior is well covered.

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

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

The description is appropriately sized and front-loaded. It opens with a one-sentence summary, then a concise behavioral paragraph, followed by a well-formatted Args block. Every sentence contributes value with no redundancy or fluff.

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

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

Given this is a simple 2-parameter tool with no annotations and no output schema, the description is remarkably complete. It covers what the tool does, how it works, what it returns, parameter semantics, safety implications, and the next step in the workflow ('Then call connect(port)'). No significant gaps.

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

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

The schema has 0% description coverage, but the description fully compensates. It explains 'baud' with meaning and default context ('Baud to probe at (default 115200, iNAV's USB VCP default)') and 'probe_all' with clear behavioral implications ('If True, probe EVERY serial port; otherwise only USB-serial-looking ones — safer'). This adds substantial meaning beyond the raw schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose with a specific verb and resource: 'Auto-detect which serial port has a flight controller'. It also distinguishes itself from sibling tools like list_serial_ports by focusing on detection rather than mere listing, and it provides a concrete workflow by saying 'Then call connect(port)'.

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

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

The description gives context on when to use the tool ('so you don't guess') and a follow-up action ('Then call connect(port)'). It also explains a conditional usage for the probe_all parameter ('If True, probe EVERY serial port; otherwise only USB-serial-looking ones — safer'), but it does not explicitly name alternative tools or situations where they should be used instead.

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

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

With no annotations, the description carries the full burden. It discloses that the profile must have been previously declared, implying state-dependent behavior. However, it does not mention what happens if no profile is set (e.g., error or empty response), leaving a gap in behavioral transparency.

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

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

The description consists of two short, front-loaded sentences with no waste. It directly states the purpose and the required prior call, earning a perfect score for conciseness and structure.

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

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

The tool is simple (no params, no output schema), and the description gives the essential purpose and prerequisite. However, it omits likely edge-case behavior (e.g., no profile declared), which would improve completeness for an agent invoking this tool without prior context.

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

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

There are zero parameters, so the schema covers everything. The description adds no parameter-specific meaning, but with no params to explain, the baseline of 4 is appropriate. The prerequisite note adds context about the tool's overall usage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns the currently declared aircraft profile. The verb 'return' and resource 'aircraft profile' are specific, and the prerequisite note helps distinguish it from sibling tools like define_aircraft and apply_aircraft_setup.

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

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

It explicitly instructs to call define_aircraft() first, which is the key usage prerequisite. This provides clear context on when to use this tool, though it does not explicitly mention alternatives or when not to use it, which is less critical given the low complexity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states it reads via both MSP and CLI and details the return data (MSP_STATUS fields, CLI status and tasks output). This goes beyond a simple 'gets status' and gives the agent a clear picture of what to expect, though it doesn't mention connection requirements or side effects (which are presumably none).

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

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

The description is brief and front-loaded with the core purpose in the first sentence, followed by a clear breakdown of return values. No redundant words; every sentence adds informative detail. Perfectly concise for the tool's simplicity.

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

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

Given the tool has zero params, no output schema, and no annotations, the description is well-rounded: it explains what the tool does and what it returns. It could optionally mention if a connection is required or how to interpret the output, but for a straightforward status read, it is sufficiently complete.

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

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

The tool has zero parameters and an empty schema, so the description does not need to explain parameter meanings. Per rubric, 0 params earns a baseline of 4. The description adds no parameter-specific info but also doesn't need to.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read FC status via both MSP and CLI' with a specific verb and resource. It distinguishes this tool from siblings like get_aircraft_profile or board_info by specifying it returns MSP_STATUS data plus CLI status/tasks output, making its unique purpose unambiguous.

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

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

The description implies usage when you need flight controller status, but it does not provide explicit when-to-use, when-not-to-use, or alternative tool guidance. It lacks exclusions or comparisons with sibling tools like why_wont_it_arm or diagnose, so the agent gets no help in choosing between them.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the output fields (path, modified time, size, line count, label), the ordering ('newest first'), and the fact that no FC connection is needed. It does not mention potential error cases or side effects, but for a simple list operation this is adequate.

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

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

The description is two sentences long, front-loaded with the core purpose, and contains no wasted words. The first sentence states the action, and the second sentence explains the return values and usage context, making it efficiently structured.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is reasonably complete. It explains what the tool does, what it returns, and how the output connects to restore_config. However, it does not mention edge cases like an empty backup directory or error handling, which would make it fully complete.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information because none exist, but it does explain the return values which helps the agent interpret the tool's output.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('List saved config backups'), the resource ('config backups'), the location ('under ./backups/'), and ordering ('newest first'). It clearly distinguishes this from sibling tools like backup_config and restore_config by focusing on listing rather than creating or restoring.

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

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

The description provides clear usage context: 'No FC needed' tells the agent this can be used without a connection, and 'so you can pick one to replay with restore_config(path)' implies its role as a precursor to restore. However, it does not explicitly name alternatives or state when not to use it, so it falls slightly short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses the return payload structure, including the critical arm_assigned flag, and the verb 'List' implicitly suggests a read-only operation. However, it does not explicitly address behavior on connection failure or clearly state that no changes are made, leaving some transparency gaps.

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

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

The description is front-loaded with a clear one-sentence purpose, followed by a compact structured list of return fields and a final practical tip. Every sentence earns its place with no redundancy or filler.

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

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

For a zero-parameter, read-only tool with no output schema, the description adequately explains the return values and includes a critical flag (arm_assigned). The workflow tip adds valuable context. It stops short of a 5 by not mentioning what happens if the FC is not connected or if read_rc_channels() fails.

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

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

The tool has zero parameters and the schema covers 100% of them (none). The description therefore has no need to explain parameter semantics, and the baseline of 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List all available flight modes') and clearly scopes the resource to 'current switch assignments.' It distinguishes itself from sibling tools like assign_switch and set_flight_mode by focusing on listing rather than modifying modes.

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

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

The tip explicitly recommends calling read_rc_channels() first and assign_switch() after, giving clear usage context and alternatives. It does not explicitly state when not to use this tool, but the practical workflow and 'critical to know before first flight' note provide strong contextual guidance.

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

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

No annotations are provided, so the description carries the burden of disclosing behavior. It clearly states this is a read-only listing operation ('List all available serial ports') and offers helpful naming conventions ('STM32', 'CP210x') without promising any side effects. This is sufficient for a simple enumeration tool.

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

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

The description is concise and front-loaded. The purpose is stated in the first sentence, followed by practical usage instructions. Every sentence contributes value, and there is no fluff.

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

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

Given the tool's simplicity (zero parameters) and the presence of an output schema, the description is complete. It tells the agent when to call it and what to expect, making it fully self-contained for selection and invocation.

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

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

The tool has zero parameters, so there is nothing to explain. The baseline for a no-parameter tool is 4, and the description adds useful context about how to interpret the output, which is effective.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'List all available serial ports', a specific verb+resource combination. It further explains the practical use (finding the FC's COM port or /dev/tty* device), which clearly distinguishes it from sibling tools like find_fc or connect.

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

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

The description gives clear when-to-use guidance: plug in the FC, run this, and look for a new entry. It implies this is the first step for locating the FC's port. It doesn't explicitly mention alternatives, but the context is enough for an agent to select it appropriately.

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

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

With no annotations provided, the description carries full behavioral disclosure. It explicitly states 'Read-only (MSP_RAW_GPS, no reboot)', revealing the safe, non-destructive nature and lack of reboot side effects. This goes beyond what structured fields provide and is essential for agent decision-making.

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

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

The description is compact and front-loaded. The first line summarizes the tool's output, the second line adds safety context, and the third gives usage guidance. Every sentence earns its place with no redundancy or fluff.

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

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

Despite having no output schema or annotations, the description is complete for a simple read tool. It specifies the data returned (fix type, satellites, position, speed, HDOP, nav-readiness), the read-only nature, and the appropriate usage context. Given the complexity is low, this fully covers the agent's needs.

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

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

The tool has zero parameters, so the baseline score is 4. The description correctly omits parameter details, as there are none to document. No further meaning is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as reading live GPS status, enumerating specific data fields (fix type, satellites, position, speed, HDOP, nav-readiness). The verb 'read' is implied and the resource is unambiguous, distinguishing it from sibling tools focused on other functions.

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

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

The description explicitly states when to use the tool: 'Use this before relying on RTH or any position-holding navigation mode.' It provides clear context but does not explicitly name alternatives or exclusions, which would earn a 5.

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

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

With no annotations, the description carries the behavioral burden. It discloses the output format (up to 16 channel values in microseconds), the typical range, and the meaning of the values for switch mapping. It doesn't state prerequisites or error behavior, but for a simple read operation this is adequate.

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

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

The description is three short sentences, front-loaded with the core function, then output details, then a usage scenario. Every sentence earns its place with no fluff.

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

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

For a simple read-only tool, the description covers purpose, output format, range, and a practical workflow scenario. It lacks explicit connection requirements, but overall it is highly usable and complete for its complexity.

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

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

There are no parameters, so the description does not need to explain them. It still adds context about the output format and practical use, which is helpful beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Read live RC channel values via MSP' with a specific verb, resource, and method. It distinguishes from sibling tools like read_sensors by focusing on RC channel values and directly linking to flight mode assignment.

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

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

The description provides a practical use case via 'Core UX: flip a switch and watch which channel value changes — that's the aux channel to use when assigning flight modes.' This implies when to use the tool but does not explicitly discuss alternatives or when not to use it.

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

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

With no annotations, the description carries the transparency burden. It discloses what values to expect (attitude ~0°, sensors OK, battery voltage) and implies a read-only, non-mutating operation. It lacks explicit statements about connection prerequisites or error behavior, but for a simple read tool this is adequate.

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

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

The description is concise and well-structured: a one-line summary followed by a short bulleted list of checks. Every sentence adds value, and the most important information is front-loaded.

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

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

For a simple, parameterless read tool, the description is complete. It explains what is read, how to interpret the values, and what the expected behavior is. The output schema is absent, but the description compensates by providing interpretive guidance.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter-specific semantics because there are none to describe. This is acceptable given the empty input schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: "Read live sensor values: attitude, per-sensor health, and analog (battery)." It enumerates specific sensor categories, making the purpose unambiguous and distinct from sibling tools like read_rc_channels or get_status.

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

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

Provides clear usage context with "Good for a quick sanity pass before flying," indicating when to use it. It does not explicitly mention when not to use it or name alternatives, but the context is sufficiently clear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It importantly warns that exiting CLI reboots the FC, so this tool reboots and reconnects (~7s), which is a critical side effect. It also discloses the return content, though it doesn't explicitly state that no configuration is changed.

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

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

The description is three sentences: the first states the purpose, the second the return structure, and the third the critical side effect. It is front-loaded, succinct, and every sentence adds essential information without redundancy.

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

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 sufficiently covers what it does, what it returns, and a key operational side effect. It could perhaps specify units or detailed format, but the overall context is complete enough for correct invocation.

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

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

The tool has zero parameters, so the input schema provides no meaningful constraints. The description adds value by enumerating exactly what data is read (PIDs, rates, filter cutoffs), which effectively explains the tool's behavior in lieu of parameter details.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool reads fixed-wing PID gains, rates, and filter cutoffs, which distinguishes it from sibling tools like set_pid (write) and read_rc_channels. It also specifies the return format (PIDs grouped by axis, rate and low-pass-filter settings), making the purpose unmistakable.

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

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

The description clearly implies usage for reading tuning parameters on fixed-wing aircraft, and notes the CLI-based access. It doesn't explicitly contrast with alternatives like cli_batch or set_pid, but the context is sufficient for an agent to select this tool over siblings.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It fully explains the atomic workflow: pre-restore backup, replaying commands in one CLI session, saving to EEPROM, rebooting, and reconnecting. It also explicitly warns that any line error triggers a rollback. This is exceptionally transparent about side effects and safety behavior.

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

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

The description is efficient and well-structured. The first sentence states the core purpose, followed by a concise paragraph detailing the atomic behavior, and a clear Args section. No redundant or filler sentences exist; every word adds value.

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

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

The description covers the tool's behavior, parameters, and safety mechanisms, which is sufficient for a complex restore operation. However, it does not mention what the tool returns or how success/failure is reported beyond rollback on error. Since there is no output schema, a brief note on the return value would have made it fully complete. Still, the core usage is fully specified.

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

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

The input schema provides only names and types, with 0% description coverage. The description adds critical meaning: path is defined as 'Path to a backup file (as returned by backup_config)' and confirm is explained as 'Must be True to apply. Dry-run by default.' This fully compensates for the schema's bare bones, making the tool safely invocable.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states 'Restore FC config by replaying a backup file's CLI commands, then save+reboot.' This names the specific verb (restore), the resource (FC config), and the mechanism (replaying CLI commands). It also distinguishes itself from sibling tools like backup_config (which creates backups) and save_and_reboot (which only saves and reboots without restoring).

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

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

The description provides clear context for when to use this tool: restoring a backup file. It also explains the dry-run default and that confirm must be True to apply. However, it does not explicitly name alternative tools or when not to use this tool, such as noting that save_and_reboot is only for saving settings without restoring, or that cli/cli_batch are for manual command execution. This omission keeps it from a 5.

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

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

Even without annotations, the description discloses important behaviors: it takes a backup, performs a save+reboot, auto-reconnects after ~7 seconds, and defaults to a dry-run unless confirm=True. This fully covers the tool's side effects and safety mechanism.

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

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

The description is well-structured, front-loaded with the core action, and includes a clear note and parameter explanation. Every sentence provides useful information without padding.

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

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

Despite being a simple one-parameter tool, the description thoroughly covers purpose, usage context, behavioral consequences, and parameter details. It is fully self-contained for an agent to decide and invoke correctly.

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

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

The schema only defines 'confirm' with a default of false, but the description explains that 'confirm: Must be True to proceed. Dry-run by default.' This adds crucial meaning beyond the bare schema, clarifying exactly how the parameter controls execution.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'Save the running config to EEPROM and reboot the FC.' It also distinguishes itself from dedicated write tools by noting they already save automatically, and this tool is specifically for raw cli() changes or forcing a clean reboot.

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

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

Explicit usage guidance is provided: 'the dedicated write tools already save automatically on iNAV, so you rarely need this — it's for persisting changes made via raw cli() reads or to force a clean reboot.' This clearly tells when to use versus avoid the tool.

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

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

With no annotations, the description fully carries the transparency burden. It discloses atomic write behavior (backup → apply → save+reboot), dry-run default, partial-argument changes, rollback on invalid values, and unit conversion (×10 for iNAV). This is exemplary behavioral disclosure.

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

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

The description is well-structured with a front-loaded summary, an Args list, and a Gates section. Every sentence adds essential information; there is no redundancy or filler. The length is appropriate for the tool's complexity.

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

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

Given the 5 parameters, no output schema, and no annotations, the description is remarkably complete. It covers purpose, all parameter semantics, gates, failure behavior, conversion details, and alternatives to sibling tools. The agent has everything needed to invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description compensates completely. Each parameter is explained with meaning, constraints, and units: procedure (firmware-dependent tokens, rollback), throttle_us (clamped 1000–2000), delay_s (guard time, ×10 conversion), off_delay_s (stage time, ×10), confirm (apply vs dry-run).

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: "Set the core failsafe behaviour," and immediately clarifies the atomic CLI write mechanism. It distinguishes itself from sibling failsafe knobs by pointing to cli('set failsafe_...') for distances/angles, and from check_failsafe which is for checking.

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

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

Explicit guidance is given: "dry-run by default" and when to use confirm=True. It states alternatives for other failsafe knobs (use cli), conditions under which RTH fails ('RTH without GPS will not work — use DROP/LAND'), and preconditions ('Gates: connected, not armed, auto-backup').

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

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

With no annotations, the description carries full responsibility for behavioral disclosure. It is outstanding: it states the operation is read-modify-write, creates or modifies an existing slot, is dry-run by default, requires confirm=True, and mentions gates (connected, not armed, auto-backup). It even notes dry-run returns the command only. This is exemplary transparency.

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

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

The description is well-structured with a concise opening sentence, followed by key behavioral details, and a clear argument list. Every sentence adds value—no fluff. It is appropriately sized for the tool's complexity and front-loaded with the core purpose.

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

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

Given the tool's complexity (5 parameters, no annotations, no output schema) and the presence of sibling tools, this description is remarkably complete. It covers behavior, parameter semantics, prerequisites, side effects (backup), and return behavior. It provides all the information an agent needs to select and invoke the tool correctly.

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

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

Schema description coverage is 0%, so the description must fully compensate. It does: mode_name is defined as exactly matching list_flight_modes, aux_channel is defined as 1-based with RC channel mapping, range_low and range_high have units and constraints, and confirm has a clear purpose and default. This is comprehensive and adds significant meaning beyond the bare schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Assign a flight mode to an aux channel range'. It uses a specific verb (assign) and resource (flight mode to aux channel), and distinguishes itself by mentioning the read-modify-write via CLI 'aux' and the dry-run default, setting it apart from sibling tools like clear_flight_mode or assign_switch.

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

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

The description explains when to use the tool (to assign or modify a flight mode on an aux channel) and provides critical usage prerequisites: use list_flight_modes for exact mode names, and confirm=True is required to apply. It also notes the dry-run behavior. However, it does not explicitly mention alternatives or when not to use it, which would have made it a 5.

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

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

With no annotations, the description fully discloses the tool's behavior: atomic write, partial updates, dry-run semantics, confirmation trigger involving save and reboot, and GPS/home fix prerequisites. This goes well beyond a basic 'set parameters' statement.

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

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

The description is compact but packs in essential behavioral, parameter, and gate information. Each section earns its place, though it is longer than strictly necessary due to the args list.

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

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

Given the absence of annotations and output schema, this description covers all needed context: tool purpose, parameter semantics, execution model, and preconditions. An agent can correctly select and invoke this tool without additional information.

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

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

The schema has zero descriptions, but the Args list compensates fully: each parameter gets its unit, underlying CLI parameter name, and allowed values where applicable (e.g., rth_allow_landing). This is a model of parameter documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Set core fixed-wing navigation / RTH parameters (atomic CLI write)', which uses a specific verb and resource. This clearly differentiates from sibling tools like set_pid, set_failsafe, and set_flight_mode.

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

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

The description provides clear usage context including the dry-run default, the need for confirm=True to apply, and the operating gates (connected, not armed, auto-backup). It does not explicitly name alternative tools for when not to use this one, but the context is strong.

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

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

With no annotations provided, the description carries full burden and does an excellent job: it discloses dry-run default, the confirm flag causing save+reboot, the safety warning, and the preconditions (gates). It also clarifies that only passed parameters are changed. This is far beyond the minimum and gives the agent confidence in invoking the tool.

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

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

The description is well-structured and front-loaded with the core purpose. The args section is compact, the warning is a single line, and no sentence is wasted. It fits the maximum guidance for a tool with this complexity.

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

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

Despite no output schema or annotations, the description covers the essential operational context: purpose, parameter semantics, dry-run behavior, confirmation effect, safety implications, and prerequisites. For a 6-parameter CLI write tool, this is complete enough for an agent to invoke it correctly.

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

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

Schema description coverage is 0%, so the description must explain parameters. It does so thoroughly: axis values are enumerated, p/i/d/ff map to fw_p_<axis> etc., and confirm's meaning is explicit. This fully compensates for the schema's lack of descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with a clear, specific action: 'Set fixed-wing PID gains for ONE axis (atomic CLI write).' This includes the verb, resource, and scope, and distinguishes it from sibling tools like read_tuning or set_nav. It also clarifies the atomic nature of the operation.

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

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

The description provides context on when to use the tool (changing PID gains per axis) and notes the dry-run default and gates. It does not explicitly name alternatives such as read_tuning for viewing gains or cli_batch for bulk operations, but the 'ONE axis' framing and atomic write hint at its niche. The gates (connected, not armed, auto-backup) are practical usage conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explicitly states 'Pure knowledge — no FC needed,' disclosing that it has no side effects on hardware. It also clarifies that it returns a plan rather than applying changes, which is important behavioral context. It could mention any limitations or error conditions, but for a knowledge-only tool, this is solid.

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

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

The description is well-structured and appropriately sized. It leads with a one-sentence summary, expands with relevant details, and breaks out arguments in a clear list. No wasted words, and each sentence contributes meaningful information.

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

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

The tool is a simple knowledge/recommendation utility with 3 optional parameters and no output schema. The description covers its purpose, parameter semantics, and return value (a layout plan to be used with assign_switch()). This is entirely adequate for the tool's complexity and context.

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

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

The input schema has 0% parameter description coverage, but the description's 'Args:' section effectively explains all three parameters: skill_level (with allowed values), num_switches (what it counts), and has_gps (how it affects RTH suggestion). This fully compensates for the schema's lack of documentation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: 'Recommend a fixed-wing flight-mode/switch layout.' It uses a specific verb (recommend), resource (flight-mode/switch layout), and scope (fixed-wing). It distinguishes itself from the sibling assign_switch by noting the output can be handed to assign_switch() to apply, showing a clear complementary relationship.

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

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

The description implicitly conveys when to use the tool via 'Pure knowledge — no FC needed,' indicating it's for planning without hardware interaction. It also ties to assign_switch() as the next step. However, it does not explicitly state when NOT to use it or compare with other alternatives, so slightly short of a 5.

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

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

No annotations are provided, so the description carries full responsibility—and it delivers. It discloses that the tool drives a live motor output, enforces safety gates (props_removed, confirm, armed check, clamps), and explains side effects (stops on reboot/power loss, always returns to stop). This is exemplary transparency beyond what a schema could convey.

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

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

The description is well-structured with sections for danger, safety gates, behavioral notes, and args. Every sentence adds essential information—no fluff. The front-loaded warning is appropriate given the danger level.

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

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

For a tool with no annotations, no output schema, and 5 parameters, this description covers all necessary context: purpose, safety, parameter semantics, behavior, and failure modes. It leaves no critical gap for an agent to safely invoke the tool.

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

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

Schema description coverage is 0%, so the description must compensate. It does so thoroughly: motor is 1-based with others held at stop, throttle_us has units and recommended starting value, duration_s has range, and props_removed/confirm have explicit MUST semantics. This adds meaning far beyond the bare JSON schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb+resource: 'Spin ONE motor briefly for a bench test (direction / wiring / response).' It clearly distinguishes this tool's narrow scope from sibling tools like calibrate_accelerometer or set_failsafe, leaving no ambiguity about what it does.

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

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

It clearly states the use case (bench test for direction/wiring) and instructs to keep throttle low for direction checks. It does not explicitly contrast with alternatives (e.g., when not to use), but the context is clear enough that an agent would know when to select it.

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

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

With no annotations provided, the description carries the full burden of transparency. It clearly explains what the tool does (decodes flags, checks ARM mode) and the output structure (name, reason, fix), but does not explicitly state that the operation is read-only or whether a connection is required. For a diagnostic tool, this is a minor gap but not a contradiction.

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

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

The description is concise and front-loaded with the main purpose in the first sentence. The sentence about it being the #1 question adds context but is somewhat optional; still, the overall length is appropriate and efficient.

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

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 adequately covers what the tool does and what the user can expect (flag name, reason, fix, ARM mode check). It lacks mention of prerequisites like a live connection, but given the simplicity, the description is sufficiently complete.

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

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

The tool has zero parameters, so the schema is trivially complete. According to the rubric, a baseline of 4 is applied for 0 params. The description adds no parameter details because there are none to describe.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb 'Decode' with a clear resource 'FC's arming-prevention flags' and explains the output in plain English. It distinguishes itself from sibling tools by focusing on arming issues, stating each set bit is mapped to a name, reason, and fix, plus checking ARM mode switch assignment.

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

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

The description implies a clear use case ('the #1 question from new iNAV users' when a craft won't arm) but does not explicitly contrast with alternative tools like 'diagnose' or 'get_status'. It lacks explicit when-not-to-use guidance or mention of prerequisites such as an active FC connection.

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