diagnose

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

Annotations already declare readOnly/idempotent/non-destructive, and the description corroborates rather than repeats: it specifies that firmware checks are run 'not change' and that parameters are downloaded, plus a concrete latency expectation ('several seconds'). It also flags that `vehicle_text` is untrusted and issues an explicit safety constraint against declaring the vehicle airworthy — behavioral context the annotations cannot carry.

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?

Front-loaded with the core purpose, then layered with behavior, output semantics, and safety constraints — each sentence carries information. Slightly dense, with the finding-kind enumeration and the safety admonition competing for space, but nothing is wasted.

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 parameterless read-only diagnostic whose output schema exists, the description supplies everything the agent still needs: what is collected, the severity vocabulary for findings, the latency expectation, and the handling of untrusted vehicle text. No meaningful gap remains.

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?

Zero parameters, so there is no schema semantics to supplement and the baseline applies. The description instead documents the finding taxonomy (`fault`, `warning`, `suspected`, `not_checked`, `passed`), which meaningfully improves interpretation even though a full output schema exists.

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 first sentence names a specific verb and scope ('Diagnose configuration and readiness problems'), and the follow-up enumerates exactly what the tool touches: sensor health, firmware pre-arm checks (run, not change), parameters, platform rules. That enumeration implicitly distinguishes it from the parameter-centric siblings like params_list and params_diff.

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 scope phrase 'configuration and readiness problems' gives an implied usage context, and the latency note hints at a cost trade-off. However, no sibling tool is named as an alternative and there is no explicit when-not-to-use guidance versus params_diff or vehicle_status.

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