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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Annotations already establish readOnly, idempotent, closed-world behavior, and the description adds meaningful behavioral context: it reports differences only, explicitly does not judge which side is right, and enumerates what is compared. This goes beyond what annotations 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?

Front-loaded with the framing question, then a tight enumeration of outputs followed by the A/B convention. Every sentence earns its place; only the parenthetical example is mildly decorative.

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?

An output schema exists so return values needn't be explained, yet the description still usefully summarizes what is compared. For a two-param read-only tool, remaining gaps (path format, same-vehicle validation behavior) are minor.

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% on two path parameters, but the description compensates partially by defining the semantic convention for A versus B (earlier/good vs later/bad). It says nothing about acceptable path formats or how the two logs must relate beyond "same vehicle".

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?

Specific verb+resource (compare two logs of the same vehicle) with a concrete framing question, and the content it produces is enumerated. An agent can distinguish it from analyze_log and log_summary without opening the schema.

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?

Strong implied usage context ("it flew fine last week", before/after a change) and the A=earlier/good, B=later/bad convention tell the agent exactly when and how to call it. It does not explicitly name alternatives or state when not to use it, so not 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?

Annotations already declare readOnlyHint, idempotentHint, and closed-world, so the safety bar is lower; the description nevertheless adds real context beyond them — no GPS positions are included (privacy), output is text and nothing is written to disk, and the result is meant for user review before posting.

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?

One dense paragraph, front-loaded with what the artifact is and its contents before the trailing workflow note. Every clause carries information, though the sentence is long and slightly meandering.

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?

An output schema exists, so return structure need not be re-explained, and annotations cover the safety profile. The description rounds this out with content, privacy, and review-workflow details; the only real gap is the unexplained 'path' parameter.

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 'path' parameter has 0% schema description coverage, so the description must carry the burden, but it never clarifies what path is expected (a log file, a directory, an existing analysis). It only hints at a log source indirectly through the report contents.

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 names a specific artifact (a Markdown reply for a discuss.ardupilot.org thread) and enumerates its contents: vehicle/firmware, onset and impact, findings with corroborating log records, and text plots. It is clearly distinguishable from all siblings (analyze_log, log_summary, incident_timeline, etc.), though the generative verb itself is only implied rather than stated.

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 gives a workflow instruction ('Review it with the user and add what they saw before they post it'), which implies the intended use case, but never states when to reach for this tool over siblings like analyze_log or incident_timeline, nor any prerequisites (e.g., what log must already be loaded).

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?

Annotations already declare readOnlyHint, idempotentHint and closed-world behavior, so the safety profile is covered. The description goes beyond that by disclosing the shape of the result (total, metadata_url, note, documented, undocumented) and the important caveat that a value outside the documented range or list is not necessarily wrong, plus offline/bundled firmware definitions.

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 purpose and the name_glob format, then the output caveats. It is dense but each sentence carries information; the explanation of return fields is somewhat redundant given an output schema exists, though the interpretation caveats earn their 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 two-parameter read tool with annotations and an output schema, this covers what the agent needs: purpose, glob semantics, fallback path, and interpretation caveats. The only real hole is the undocumented `path` parameter.

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 carry the load. It explains name_glob well (case-insensitive glob with a concrete example like 'INS_HNTCH_*'), but the required `path` parameter is never described, leaving half the parameters undocumented.

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 verb and resource ('Parameter values recorded in the log's PARM dump') and scopes it to the log's firmware, which distinguishes it from siblings like list_events, query_timeseries, and log_summary without needing the schema.

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 gives a clear conditional route to an alternative: if the snapshot looks incomplete (truncated log), ask for the exported .param file and use load_param_file. It also advises how to interpret out-of-range values. It does not cover when to prefer this over other parameter/event siblings, but the key alternative is named.

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?

Annotations already cover the safety profile (readOnly, idempotent, closed-world), so the remaining burden is interpretive guidance. The description supplies exactly that with 'Time order only — never causation', telling the agent how to read the output and warning against causal inference, plus the tagging scheme that shapes interpretation.

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?

Two sentences, front-loaded with the mental model of the output and then the usage question; every clause (onset, impact, tag list) maps to real content the agent must understand. The single sentence is long but not padded.

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?

With an output schema present, the description needn't explain return values, yet it still characterizes them well via the phase tags. For a one-parameter read-only analytics tool this is close to sufficient; only the path parameter's meaning is left entirely unaddressed.

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% and the single parameter 'path' is undocumented in the description, so the agent gets no format, source, or relative-vs-absolute guidance. The parameter is largely self-evident, which keeps this from being worse than baseline.

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 names a concrete analytic artifact (an ordered incident timeline of onset, impact, firmware verdicts and findings) and enumerates the phase tags it emits, which is far more than a restatement of the name. It does not explicitly contrast itself with siblings such as list_events or log_summary, so it stops short of full sibling differentiation.

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 gives an explicit use case in the user's own words: 'what failed first, and is the rest just the crash?'. That is clear context for when to reach for this tool, but no alternative tool is named and no when-not condition is stated.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety and determinism profile is fully covered elsewhere. The description adds only the modest context that the checks form an 'extensible catalogue' (i.e., the list is a registry that can grow), which is genuine but thin; no cost, rate, or ordering behavior is disclosed.

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 front-loaded sentence with zero padding. Every word earns its place and the core action leads the sentence.

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 list tool with a full output schema and complete annotations, the definition is close to sufficient — return values are documented elsewhere and behavior is covered by hints. It stops short of 5 because nothing tells the agent where this catalogue sits relative to the diagnostic siblings.

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 takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to disambiguate, and the schema description coverage is 100%.

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?

States a specific verb and resource ('List the registered diagnostic checks') and adds a scope hint ('the extensible catalogue'). It is clear what the tool returns, but it never differentiates itself from similarly named siblings such as list_events or get_params, leaving the agent to infer the distinction from the resource noun alone.

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?

There is no when-to-use or when-not-to-use guidance, and no alternative is named. The agent gets no signal on whether this should be called before analyze_log, incident_timeline, or the other siblings, or what a prerequisite would be.

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?

Annotations already declare readOnly, idempotent, closed-world behavior, so safety is covered. The description adds genuinely useful context not in structured data: the event families that exist (ERR/MODE/EV/MSG) and that time values are seconds. It says nothing about ordering or result volume, so it stops short of a 4.

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?

Two tight sentences with no filler, and the core resource is front-loaded. The telegraphic style ('times are seconds') is efficient, though the terseness slightly reduces readability.

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?

An output schema exists so return values need no explanation, but with 0% parameter coverage and no when-to-use guidance, the definition is only minimally complete for a log-querying tool. The 'path' argument is never described, leaving one required parameter's meaning entirely to the caller.

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 carry the load, and it partially does: it explains that 'kinds' filters event families and enumerates the valid families, and that time parameters (start_s/end_s) are in seconds. Only 'path' is left unexplained.

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 names a concrete resource and scope: a decoded ERR/MODE/EV/MSG event timeline. An agent can tell it returns parsed log events rather than raw logs or a summary, though it never explicitly contrasts itself with the nearby incident_timeline sibling.

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?

There is no statement of when to reach for this tool versus list_checks, incident_timeline, or log_summary, and no prerequisite or context guidance. The agent must infer usage purely from the resource noun.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: it reads an authoritative complete config and, when firmware is supplied, attaches documented metadata and lists names not documented for that release. It does not detail error behavior or path requirements, so not a 5.

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-loads the core action, then immediately gives usage conditions and parameter effects. The four sentences are dense but every one adds distinct information, with no repetition 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?

Output schema exists, annotations cover safety and idempotence, and the description covers usage context and two of three parameter effects. It is nearly complete for invoking correctly, though it omits explicit path/error semantics and does not mention what loading returns, which the output schema presumably covers.

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 carry parameter meaning. It explains name_glob as a filter and firmware as attaching documented metadata and listing undocumented names, but path is only implied by 'parameter file' and lacks format details such as absolute/relative path handling. Partial compensation for three parameters warrants a 3.

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?

States a specific verb and resource: loading a user-exported ArduPilot parameter file (.param/.params), and frames it as the authoritative complete configuration. It explicitly contrasts this with the log's PARM snapshot and with get_params, so an agent can distinguish it from siblings without opening schemas.

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?

Gives concrete when-to-use conditions: when the log's PARM snapshot is truncated/incomplete, or to compare flown config from get_params against the user's current/intended config. It names the alternative get_params and explains the comparison use case, leaving little inference.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety and side-effect profile is covered structurally. The description's only extra behavioral signal is 'cheap,' which usefully conveys low cost/latency and orients it as a lightweight probe. It adds little else about 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?

A tight one-line phrase with the leading qualifier 'Cheap orientation' front-loaded, so the key framing lands first. It is telegraphic but wastes no words.

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?

An output schema exists, so return values need not be explained, and annotations cover safety. However, the tool omits any guidance on the required path argument and no usage context, leaving it only minimally complete for calling 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 single 'path' parameter has 0% schema description coverage and the description never mentions it, adding no meaning about what path refers to (log file, directory, etc.). With low coverage the description should compensate, and it does not.

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?

States a specific resource (a flight log) and enumerates exactly what the summary returns: vehicle, firmware, duration, message counts, flight modes, max altitude, integrity. This lets an agent distinguish it from a deeper tool like analyze_log. It stops short of explicitly naming a sibling, so it is clear but not fully differentiated.

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?

'Cheap orientation' implies this is the fast first-pass tool to run before heavier siblings like analyze_log, but the description never says when to use it versus alternatives or any prerequisites. Usage is only implied, not stated.

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?

Annotations already establish readOnly/idempotent/closed-world, but the description adds genuinely useful behavior: multi-instance messages are returned one instance at a time with a default of the first, values are index-aligned with times_s, and output is decimated to at most max_points. These are traits the annotations cannot express.

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?

Purpose is front-loaded, followed by behavioral caveats in a logical order with no filler. The parenthetical enumeration of VIBE/IMU/GPS/MAG/BAT/XKF examples is slightly heavy but earns its place by clarifying what 'multi-instance' means.

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?

An output schema exists, so return formatting need not be described, and the key runtime behaviors are covered. The gap is parameter documentation: for a 7-parameter tool at 0% schema coverage, five parameters are left for the agent to infer from names alone.

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 carries the full parameter burden, yet it only clarifies two of seven parameters (instance default and max_points decimation). Path, message_type, fields, start_s, and end_s get no explanation at all, leaving most of the schema undocumented.

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?

States a specific resource and scope: 'Numeric time series for a message type and fields,' and adds the intent 'for drilling into a finding.' No sibling tool overlaps directly, but the description never explicitly differentiates itself from near-neighbors like log_summary or analyze_log.

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 phrase 'for drilling into a finding' implies when the tool is appropriate, and 'see available_instances' points to a related call. However, there are no explicit when-not conditions or named alternatives among the eleven siblings, so usage is only implied.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety is covered. The description adds genuine value beyond them: it names the data sources the recommendation is derived from (batch sampler, IMU, in-flight FFT, ESC RPM) and stresses 'Recommendation ONLY — never applied', confirming the analysis never mutates the craft.

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 dense sentence plus a short emphatic caveat, with the core purpose front-loaded. The parenthetical list is information-rich rather than filler, though it is packed tightly enough to read as a fragment.

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?

An output schema exists, so return values need not be described, and the read-only nature is well covered. However, for a tool requiring a 'path' argument, the description never says what that path should reference or what the tool needs in order to produce recommendations, leaving a real invocation gap.

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 schema documents nothing. The description partially compensates by implying the set of values the 'area' parameter can take (harmonic notch, PID, autotune), but the required 'path' parameter is left completely unexplained — an agent cannot tell whether it points at a log, a config, or a directory.

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?

States a specific verb+resource (advisory tuning recommendations) and enumerates the concrete subject areas: harmonic notch, PID, autotune. It is clearly distinct from siblings like analyze_log or get_params, though it never names a sibling to route against.

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 statement of when to choose this over analyze_log, log_summary, or get_params, and no prerequisites (e.g. what input is needed first). The only usage-adjacent content is the caveat that the output is advisory only, which is a constraint rather than selection 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?

Annotations already establish read-only, idempotent, closed-world behavior. The description adds genuinely non-structured context: the profile is *inferred* from the log rather than measured, and hover throttle / power margin is flagged as the key derived insight, warning the agent these are estimates to be combined with user-supplied physical facts. It stops short of stating accuracy limits or which log conditions degrade the inference.

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?

Two sentences, front-loaded with the resource and then the enumerated contents. The parenthetical 'the key physical insight' is slightly editorial but earns its place by signaling which output matters most; nothing is padded.

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?

An output schema exists, so return values need no further explanation, and annotations cover the safety profile. For a single-parameter read-only tool the description is nearly complete; the only real hole is the unexplained 'path' parameter.

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 is a single required 'path' parameter with 0% schema description coverage, and the description never explains what the path points to, its accepted format, or expected file types. The phrase 'inferred from the log' weakly implies it is a log file path, which is minimal compensation for the coverage gap.

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 resource (physical/architecture profile of the aircraft) and enumerates the concrete outputs it produces: frame class/type, motor count, battery cells/capacity, hover throttle, power margin, thrust-to-weight. That content footprint is distinct enough from siblings like log_summary or get_params that an agent can route correctly, but no sibling is named explicitly.

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 gives a usage context ('use this to reason about the craft physically and to combine with real-world details the user gives'), which implies when the tool is useful. However, it offers no when-not guidance and never names an alternative (e.g. get_params for raw parameter values), so selection among siblings still requires inference.

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