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

Annotations already declare non-destructive, idempotent behavior, and the description adds real value on top: it discloses the side effect of closing the previous connection, the validation gate (MSP/BTFL/API>=1.40), and the failure semantics (port is closed on rejection). It does not discuss in-flight operations affected by the forced close, but the behavioral picture is strong.

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?

Three dense sentences: action first, then validation/failure behavior, then return values. No filler, no repetition of the title, and the most decision-relevant fact (closing the prior connection) 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?

No output schema exists, so the description correctly carries the return contract (api_version, fc_variant, fc_version), and combined with annotations it covers safety profile, side effects, failure mode, and prerequisites. Nothing an agent needs to invoke it correctly is missing.

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 100%, so both port (default, BETAFLIGHT_PORT env var, auto-detection) and baudrate are already fully documented in the schema. The description adds no parameter syntax or format detail beyond that, so the baseline 3 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?

States a specific verb ("Connecte le serveur au FC via port série") plus the key behavioral qualifier that it closes the previous connection, which cleanly separates it from siblings like disconnect and list_serial_ports. An agent immediately knows this is the session-establishing call.

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?

Usage is implied (this is the entry point before any get_*/set_* call) and the preconditions for success are stated (MSP response, BTFL firmware, API >= 1.40), but it never routes the agent to alternatives such as list_serial_ports for discovery or disconnect for teardown. Adequate context, no explicit when/when-not 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 declare readOnlyHint=true and openWorldHint=false, and the description adds the real behavioral context: it polls over a window rather than sampling once, and returns the peak-delta channel. It does not spell out the exact return shape, but for a read-only polling tool 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?

Front-loads the core behavior, then the protocol, then the rationale, with no filler. Each sentence carries distinct 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?

Covers the full workflow including the prerequisite get_rc call and the per-axis repetition, which is exactly what an agent must know before invoking it. Absence of an output schema is compensated by the description naming what is returned.

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 100%, so baseline, threshold, and duration_s are already documented. The description still adds provenance for baseline (must come from get_rc's channels field) and frames duration_s as an observation window, going slightly 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?

States a specific verb and resource (polls RC channels, returns the channel with the largest baseline delta over a window) and explicitly contrasts itself with the instantaneous alternative. An agent can distinguish this from get_rc and snapshot_rc_delta without opening any 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?

Gives the full when-and-how: a numbered protocol (get_rc baseline, ask user to move ONE control, call this tool, repeat per axis) plus the reliability rationale. Usage is unambiguous and nothing is left to 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 and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the ~50 Hz sampling rate, the bounded observation window, and the fact that the result depends on user-supplied stick/switch movement. It stops short of describing output shape, but that is minor given the no-annotation-burden baseline.

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 passive-mode behavior, then classification taxonomy, then the sibling routing, then the user instruction. Dense and information-rich with no filler, though the classification enumeration makes it longer than strictly minimal.

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?

There is no output schema, so the description carries the return-value burden — and it does so by listing the classification labels the agent will receive and noting which channels stay ambiguous. A caller has essentially everything needed to invoke and interpret 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?

Schema description coverage is 100% – duration_s is already documented with its max (60 s) and meaning in the schema. The description's 'pendant N secondes' merely echoes this without adding format or edge-case guidance, so the baseline 3 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?

States a specific verb (échantillonne/classifie), the resource (all RC channels), and enumerates the exact output classification vocabulary (throttle, stick, switch_2pos, switch_3pos, unused) plus the TAER/AETR convention detection. It differentiates itself from the sibling detect_rc_channel_move by naming the residual ambiguity it cannot resolve.

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?

Explicitly frames this as 'mode passif', states the prerequisite user action (ask the user to move all sticks/switches during measurement), and names the alternative tool (detect_rc_channel_move) with the exact condition under which to combine it. Both when-to-use and the workaround path are given.

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 non-read-only, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds genuine behavioral detail beyond that: the close waits for the in-flight MSP request rather than aborting it, which tells the agent this is a graceful teardown and safe to call at any point.

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 short sentence with no filler, and the core action is front-loaded. It is arguably terse, but every word earns its place and 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?

For a no-argument, no-output-schema teardown tool whose annotations already convey safety and read/write semantics, the description covers what the agent needs: what it closes, when it takes effect, and that it is safe. Only minor context (e.g. what happens to subsequent calls) is absent.

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 baseline of 4 applies. Nothing in the description needs to explain parameter meaning, and no parameter-related gaps exist.

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: closing the serial connection to the flight controller. That is unambiguous and implicitly the inverse of the sibling 'connect'. It stops short of explicitly naming 'connect' as the counterpart, so it is clear but not sibling-differentiating in the strongest sense.

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 parenthetical '(après la requête MSP en cours)' gives useful timing context, implying this should be called when serial work is finished. However, it never says when to reach for this versus alternatives (e.g. when to disconnect before reconnecting, or relative to 'connect'/'list_serial_ports'), 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 and openWorldHint=false, so the safety profile is covered. Beyond that the description adds only a topic list: it says nothing about whether the values reflect live FC state or the saved profile, whether missing values are omitted, or how the payload is shaped.

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?

It is a single terse fragment with no wasted words, which is good, but it is under-specified rather than concise — the space saved was spent on nothing that helps selection.

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 tool with annotations covering the safety profile and no output schema, the description is minimally adequate: it tells the agent what subject matter comes back. It falls short on routing the agent among the many sibling config getters.

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 there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. The content list is a bonus but is not required here.

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 the resource ('Config avancée') and enumerates the content it exposes (gyro/PID denominators, ESC/DSHOT protocol, PWM rate), so an agent can infer roughly what it returns. However, there is no verb, so it reads as a label rather than a statement that this tool *retrieves* the config, and it does not distinguish itself from close siblings like get_pid_advanced, get_filter_config or get_rates.

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 indication of when to call this tool versus the many overlapping config readers in the sibling list (get_pid_advanced, get_filter_config, get_rates). The agent is left to guess from the topic list alone.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful context beyond the schema by disclosing the data source (barometer) and the units (m and cm/s), which helps the agent interpret the values, but it says nothing about update rate, latency, or availability conditions.

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 short sentence that front-loads both returned quantities and their units and source. Every element 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?

For a parameterless read-only sensor tool with no output schema and annotations covering the safety profile, the description supplies what an agent needs: what is returned, in what units, and from which sensor. Minor gap is the absence of any note on when the barometer reading is or is not valid.

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 the schema carries no semantic burden and the baseline of 4 applies. The description correctly adds no parameter information because there is none to add.

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 the specific resource (altitude and variometer) and the source (barometer), with units for both values, so an agent can distinguish it from siblings like get_attitude or get_imu_data. It lacks an explicit verb, but as a parameterless getter the intent is 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?

There is no guidance on when to call this tool versus alternatives such as get_attitude or get_imu_data, nor any stated prerequisites or conditions. The agent must infer usage entirely from the tool name and sibling list.

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?

The readOnlyHint and openWorldHint annotations already establish this as a safe, local read, so the bar is lower. The description contributes the unit of the returned values (degrees), which is genuine added context, but says nothing about frame of reference, update rate, or freshness of the reading.

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 short sentence that front-loads the resource and then lists the exact fields returned. Nothing is redundant or 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 no output schema, the description carries the burden of describing the return values, and it does so by naming roll, pitch and heading plus their unit. Only minor details (reference frame, whether heading is magnetic or true) are absent.

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 the baseline is 4. The description's unit information (degrees) pertains to output rather than input and does not affect parameter 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?

States a specific verb (get) and resource (drone attitude) and enumerates the returned quantities: roll, pitch, heading. It does not differentiate itself from the closely related sibling get_imu_data, which an agent could reasonably confuse it with, so it falls short of a 5.

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?

Usage is only implied: a zero-argument getter whose name and description make its purpose self-evident. There is no statement of when to prefer it over get_imu_data or get_altitude, and no exclusions or prerequisites are given.

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 and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond the unit annotations (V, A) and unitless fields like mAh and RSSI — nothing about freshness, sampling, or error states.

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?

It is a single compact fragment with zero filler and the payload fields are front-loaded. It is arguably too terse rather than bloated, so it is efficient but not exemplary.

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 no output schema, the description usefully enumerates the returned fields (voltage, current, mAh, RSSI), which is the main value it adds. However, for a telemetry tool sitting among many similar battery/meter siblings, the absence of any selection guidance leaves the definition only minimally 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 takes zero parameters, so the baseline is 4. The description correctly implies a plain parameterless read, and there is nothing for it to document or mis-document.

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 lists the telemetry it returns (voltage, current, mAh consumed, RSSI) but uses no verb and never states that the tool retrieves/reads this data. It also fails to differentiate from close siblings such as get_battery_state, get_voltage_meters, and get_current_meters, which appear to overlap in scope.

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 guidance, no conditions, and no mention of alternatives. An agent cannot tell from this text why it would call get_battery rather than get_battery_state or the individual meter 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds value by giving units (0.01 V, mAh) and identifying that battery_meter/current_meter are measurement sources, but it says nothing about whether values are live vs. stored defaults or what the response shape looks like.

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 line with no filler; the key list is front-loaded and every token carries information. It is slightly cryptic (French prose mixed with English CLI names) but wastes nothing.

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 no output schema, the description carries the burden of describing what comes back, and it partially does so by listing the config keys and units. It still omits the overall return structure and gives no hint that set_battery_config is the write counterpart, leaving the agent with an incomplete picture.

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 the baseline is 4. The description's enumeration of config keys and their units is extra value, though it describes returned fields rather than inputs, which is a completeness rather than parameter concern.

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 the resource ("Config batterie") and enumerates the specific configuration keys it covers (vbat_min/warning/max_cell_voltage, bat_capacity, battery_meter, current_meter), which goes beyond the name. However, it never states a verb or explicitly says it retrieves/returns these values, and it does not distinguish itself from siblings like get_battery, get_battery_state, or set_battery_config.

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 guidance, no mention of prerequisites, and no reference to alternatives. Given the crowded sibling set (get_battery, get_battery_state, get_voltage_meters, get_current_meters, set_battery_config), the agent gets no help deciding when this tool is the right one.

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 readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine domain context beyond that: the exact returned fields, the 0.01 V unit scaling, and the derivation rule floor(tension / vbat_max_cell_voltage) + 1 — details an agent could not infer from the empty 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?

Two tight sentences with no filler; the field list and unit is front-loaded and the cell-count formula follows as supporting detail. The only structural weakness is that it enumerates the return payload before stating plainly that the tool reads the profiles.

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 no output schema, the description carries the return-value burden and does so thoroughly: field names, units, and the cell-count formula. For a read-only, zero-parameter getter whose annotations cover the safety profile, that is nearly everything an agent needs; error/absence behavior is the only unaddressed 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?

The tool takes zero parameters and the schema is empty, which is the baseline-4 case. The description correctly implies the call is unparameterized — it simply returns the profiles — so nothing is left ambiguous here.

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 — 'Les 3 profils batterie' — with the version gate (Betaflight 2026.6+) and the exact field set, which cleanly separates it from telemetry siblings like get_battery and get_battery_state. It never states the retrieval verb explicitly, and it does not name get_battery_config or set_battery_profile to sharpen the boundary, so it stops short of a 5.

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 '(Betaflight 2026.6+)' qualifier is a real usage constraint, telling the agent this call is only meaningful on newer firmware. Beyond that, there is no when-to-use vs. when-not, no mention of how it differs from get_battery_config or get_battery_state, so the guidance is implied rather than 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 and openWorldHint=false, so safety is covered. The description does add a genuine behavioral hint that no annotation provides — that health is reported as one of OK/WARNING/CRITICAL — plus the data categories returned. With no output schema, it could have said more (units, freshness, whether it reads live telemetry vs cached config), so a 3 is fair rather than 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?

A single compact sentence that front-loads the resource and then lists the payload. No filler, no redundant restatement of the name.

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-argument read tool with safety annotations already in place, the description covers the essentials of what comes back. The remaining gap is sibling routing — nothing tells the agent how this differs from `get_battery` — which is minor here but real given how many battery-related siblings exist.

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 there is nothing for the description to disambiguate; per the rubric, 0 params sets the baseline at 4. The description does not need to explain inputs and does not waste space pretending 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?

Names a specific resource (battery) and enumerates what the state report contains — cells, capacity, status. That is far more informative than a tautology. It does not, however, distinguish itself from the sibling `get_battery` (or `get_battery_config` / `get_battery_profiles`), so an agent cannot tell from the description alone why it would pick this one.

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 guidance and no mention of any alternative, despite `get_battery` and `get_battery_config` sitting in the same sibling set. The agent must infer usage purely from the tool name.

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 and openWorldHint=false, so the safe-read profile is covered structurally. The description adds the concrete contents of the response (firmware variant, version, board, MCU, API version), which is genuinely useful given there is no output schema, but it says nothing about caching, connection requirements, or failure modes.

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 a colon-delimited field list; every token earns its place and there is no filler or repetition of the tool name.

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 no parameters, no output schema, and read-only annotations, the description's enumeration of returned fields is the key missing piece and it is supplied. The only gap is the absence of any routing hint against the overlapping get_fc_status sibling, and the description is written in French while the name and siblings are English.

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 there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The enumerated return fields are the only semantics available and they are stated.

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 (Retourne) and resource (l'identité du FC) and enumerates exactly what identity means: firmware variant (BTFL), version, board, MCU, API version. An agent knows precisely what data comes back, but nothing distinguishes it from the similar-sounding sibling get_fc_status, so it stops short of a 5.

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 indication of when to call this versus get_fc_status or get_advanced_config, and no prerequisites or exclusions are stated. The agent must infer usage purely from the field list.

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 and openWorldHint=false, so the safety profile is covered by structured data. The description only echoes that it returns a listing; it adds nothing about what an ammeter entry contains or whether the call can fail.

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 short sentence with no filler, and the operation (list all) is front-loaded. Nothing needs trimming.

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 no output schema present, the description ideally would sketch what an ammeter object returns, but it does not. For a trivial zero-arg read it is minimally adequate, and annotations cover the safety aspects.

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 no parameter syntax the description could meaningfully explain.

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 resource (ampèremètres/current meters) and scopes it to the flight controller, so the verb+object is legible. However, it largely restates the tool name and offers no differentiation from the very similar sibling get_voltage_meters or from get_battery, leaving the agent to infer the distinction.

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 call this versus the near-identical get_voltage_meters, get_battery, or get_battery_state siblings. No prerequisites, no context — the agent must guess based on the name alone.

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 and openWorldHint=false, so the safety profile is covered. The description adds that the response is an aggregate status including cycle time and CPU load, but says nothing about refresh cadence, cost, or whether values are instantaneous vs averaged.

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 front-loaded fragment — the subject ("État général du FC") comes first, followed by a colon and a terse list of the fields returned. No filler, 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?

With no output schema, the description carries the burden of telling the agent what comes back, and the field list (cycle time, sensors, arming flags, CPU load) does that adequately. A note that it is a snapshot rather than a historical series would complete it, but nothing essential is missing.

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 and the empty schema leaves nothing to document, so the baseline of 4 applies. There is no argument syntax for the description to clarify.

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 ("FC") and scope ("État général") plus the concrete fields returned — cycle time, active sensors, arming flags, CPU load. This distinguishes it from narrower siblings like get_sensor_config or get_board_info by signalling an aggregate snapshot, though it never names those alternatives to sharpen the contrast.

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 enumerated contents imply this is the broad 'what is the FC doing right now' call, which is useful context, but there is no explicit when-to-use, when-not-to-use, or reference to any sibling such as get_imu_data or get_advanced_config for deeper detail.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful content by enumerating the kinds of feature flags returned (AIRMODE, LED_STRIP, GPS), but says nothing about return format, whether values are booleans, or whether the list is complete.

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 short clause with no filler; the resource is stated immediately. It is arguably terse to the point of under-specification, but nothing in it 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 no-argument read-only getter with no output schema, the description conveys what the call returns via representative examples. A brief note on the return shape would fully close the gap, but the essential information an agent needs is present.

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 no parameter documentation is needed and the baseline of 4 applies. The description correctly implies a no-argument call by describing a global feature list rather than a targeted lookup.

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 resource ('Features Betaflight activées') and gives concrete examples (AIRMODE, LED_STRIP, GPS), so an agent knows it retrieves the enabled feature flags. It does not, however, distinguish itself from adjacent config getters such as get_advanced_config, get_filter_config, or get_sensor_config.

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 indication of when to call this tool versus the many sibling config getters, nor any prerequisite (e.g. being connected to the flight controller) or exclusion. The agent must infer the use case purely from the resource name.

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 and openWorldHint=false, so the safety profile is clear. The description adds useful context by enumerating the filter configuration categories returned (e.g., notches, RPM filter), but does not disclose behavioral details like authentication needs, rate limits, or response format beyond what annotations provide.

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 a single concise phrase that front-loads the core purpose and then lists specific filter categories. It is appropriately sized, though the fragment structure lacks a verb and could be slightly more polished.

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 no input parameters or output schema, the description should convey what the tool returns. It lists the relevant filter settings and CLI names, which is sufficient for an agent to understand the return content. However, it could more explicitly state that it returns the current configuration values.

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 score of 4 applies. The description does not need to explain parameter semantics, and the schema is empty and fully described by default.

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 tool name and description clearly indicate retrieval of filter configuration, with a detailed list of included filter settings and CLI names. However, the description does not explicitly differentiate this tool from sibling tools like set_filter_config or get_advanced_config, leaving some ambiguity about scope relative to alternatives.

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 no guidance on when to use this tool versus alternatives, nor does it mention prerequisites or exclusions. An agent must infer usage solely from the tool name and sibling context.

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 and openWorldHint=false, so the safe-read profile is covered by structured data. The description adds the unit conventions for each channel, which is genuinely useful context, but says nothing about sampling behavior, freshness, or the shape of the returned values.

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 compact fragment with the resource named first and the channel details after; nothing is wasted. It is terse to the point of being a label rather than a sentence, but every element 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 read-only tool with no output schema and annotations covering safety, the description supplies the one thing an agent cannot infer: what channels are returned and in what units. Only the absence of any output-shape or usage context keeps it below 5.

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. The description correctly spends its words on the output channels rather than inventing parameter 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?

States a specific resource (IMU data) and enumerates the three sensor channels with their units (accelerometer in g, gyroscope in °/s, magnetometer), which is more informative than a bare 'get IMU data'. It does not, however, differentiate itself from near siblings such as get_attitude or get_rates, which read related sensor-derived values.

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 guidance on when to call this rather than get_attitude, get_rates, or the other sensor getters in the sibling list. No prerequisites, polling rate, or context is given, leaving selection entirely to 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 and openWorldHint=false, so the safety profile is covered. The description adds only the scope detail that these are active RC modes / AUX switches and the field set, which is useful but not rich behavioral context (no auth, rate-limit, or return-shape detail beyond the field names).

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 short line with no filler, and the resource name is front-loaded before the field list. It is appropriately sized for a simple zero-parameter getter, though the telegraphic fragment style leaves the action implicit.

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 should carry the return-value semantics, and it does list the relevant fields (box_id, canal, min/max µs). However, it omits when the tool is applicable relative to siblings such as get_rc, leaving a meaningful gap for an agent deciding what to call.

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 0 parameters (empty input schema, 100% coverage), so there is no parameter documentation burden. Per the baseline for zero-parameter tools this sits at 4; the field names in the description describe returned data rather than inputs.

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 is a noun phrase naming the resource ('Plages de modes RC actifs (AUX switches)') plus the returned fields, rather than a specific verb+resource statement. An agent can infer it is a read of active RC mode ranges, but the purpose is not sharply stated and there is no differentiation from siblings like get_rc or get_feature_config.

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 when-to-use guidance, no prerequisites, and no mention of alternatives such as get_rc or get_feature_config. The description gives no context for choosing this tool over its many sibling getters.

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 and openWorldHint=false, so the safe-read profile is covered. The description adds genuinely useful semantics beyond that: the unit is microseconds and a value of 0 means the motor is inactive. It does not explain ordering, count, or whether values are live or last-commanded, so it is additive but not rich.

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 compact clause plus a unit annotation and an edge-case definition — no filler at all. The most important information (what is returned, in what unit) 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?

With no output schema and no parameters, the description is the only place return semantics could be documented. It gives the unit and the zero-value meaning, which is a good start, but omits how many motors are returned, their order/indexing, and whether the reading is live PWM output — details an agent would want before relying on 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 tool takes zero parameters, so the 0-param baseline of 4 applies. Schema description coverage is 100% and there is nothing to document; the description correctly spends no words on parameters.

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 resource (motor outputs) and its unit (µs), which distinguishes it from telemetry siblings like get_imu_data, get_attitude, or get_battery. It is a noun phrase rather than a verb+resource, but the intent is unmistakable. No explicit differentiation from the other get_* tools beyond the resource name.

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 call this tool versus alternatives, nor any prerequisite or context (e.g. 'use to verify motor outputs before arming'). The usage is only implied by the resource name. Basic telemetry reads need little guidance, but nothing here helps an agent choose among the ~20 sibling get_* 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?

readOnlyHint=true already tells the agent this is a safe read, so the description need not restate safety. It does add useful field-level context, including version-dependent CLI naming (d_min_* before Betaflight 2025.12), which helps interpret results. It says nothing about the active-profile coupling beyond the naming, so it is adequate but not rich.

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?

It is a single front-loaded sentence that leads with the resource and then enumerates contents; every token carries technical meaning with no filler. The enumeration is dense, but nothing is redundant.

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 no output schema, the description carries the burden of describing returned content, and the field-group enumeration largely does that. It is sufficient for a read-only getter, though it omits units/ranges and how the 'active profile' is determined.

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 and schema coverage is 100%, so there are no parameter semantics to explain; baseline for a no-arg tool is 4. The CLI naming detail concerns returned field identities rather than inputs.

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 the specific resource ('Réglages PID avancés du profil actif') and enumerates the exact setting groups it returns, which distinguishes it from the sibling get_pid_values and get_advanced_config. It lacks an explicit action verb (no 'get/retrieve'), so it reads as a noun phrase rather than a verb+resource statement, but the scope is 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?

There is no statement of when to use this tool versus alternatives such as get_pid_values or get_advanced_config, and no preconditions or exclusions. The field list implies scope but the agent must infer when this getter is the right choice.

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 and openWorldHint=false, so the safety profile is covered. The description adds useful return-content context by naming the axes returned, but says nothing about units, structure, or how it relates to the advanced PID 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?

A single compact sentence with the key information (PID values, per-axis scope) front-loaded and no filler. It is arguably too terse to route against siblings, 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?

With no parameters and no output schema, the description is the only source of return-value information, and it does name the axes. However, it omits units and the distinction from get_pid_advanced, leaving a gap an agent would need to resolve.

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 the baseline of 4 applies; the schema has nothing to document and the description appropriately spends no space on inputs.

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 the resource (PID P/I/D values) and enumerates the axes covered (roll, pitch, yaw, level, mag), so the agent knows what it retrieves. It does not distinguish this from the sibling get_pid_advanced, which covers a related but different dataset, so it falls short of a 5.

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 call this versus get_pid_advanced, set_pid_values, or the profile tools. The read-only nature is only inferable from the name and annotations, not from the text.

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 and openWorldHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond annotations: battery_profile only exists on Betaflight 2026.6+. It says nothing about return format, ordering, or how profile indices map to configuration.

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?

Extremely compact and front-loaded: the key term 'Profils actifs' comes first, followed by the returned fields. Nothing is padding, though the lack of a verb makes it read as a label rather than a complete instruction.

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 no output schema, the description must carry the return-value burden, and it does list the returned profile fields, including the version-gated battery_profile. It still omits what the values mean (index numbers? names?), their ranges, and the unit/scaling of pid_profile_count, leaving an agent partially informed for a read 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 tool takes zero parameters, so the baseline of 4 applies. The description instead documents the response keys, which is the relevant semantic information for a parameterless read.

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 the resource (active profiles) and enumerates exactly which profile indices are returned (pid_profile, pid_profile_count, rate_profile, battery_profile), which lets an agent distinguish it from siblings like get_battery_profiles (a list of available battery profiles) or select_profile (which switches them). It is clear but written as a noun fragment with no explicit retrieval verb.

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 call this versus get_pid_values, get_rates, get_battery_profiles, or select_profile. The word 'actifs' implies a read-current-state purpose, but no context, prerequisites, or exclusions are given.

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 and openWorldHint=false, so safety is covered. The description adds real behavioral context beyond that: the values are expressed in configurator units and depend on the active rates_type (BETAFLIGHT, RACEFLIGHT, KISS, ACTUAL, QUICK), disclosing a state dependency the agent must account for.

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 that leads with the resource and scope before enumerating fields. It is dense but every clause (units, rates_type, field list, throttle block) carries information; the trailing field list is the only slightly bulky part.

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 no output schema, the description usefully enumerates the returned fields and their unit context, which compensates for the missing return contract. For a simple zero-parameter getter this is close to complete, though it does not describe the exact shape/nesting of the returned structure.

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 there is nothing for the description to disambiguate; the 4 baseline applies. The listed field names are return content, not inputs, and do not misrepresent the empty 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?

States a specific resource (RC rates per axis: roll, pitch, yaw) and enumerates exactly what is returned (rc_rate, rate, expo, labels, rate_limit_dps, max_rate_dps, throttle mid/expo/limit/hover). An agent can immediately distinguish this read tool from the sibling set_rates writer and from get_rc.

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?

Usage is implied by the content (read the currently active rates configuration) but there is no explicit when-to-use or when-not guidance, and the sibling set_rates is never named as the alternative. An agent can infer the intent from the name and description, but nothing routes it between readers and writers.

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 and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful interpretation context — the unit (µs) and typical range 1000-2000 — but says nothing about return structure, channel count, or sampling 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 single clause with a parenthetical qualifier; zero padding and the unit/range information is front-loaded alongside the 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 parameterless, annotation-covered read tool, the description supplies the essentials: current values, unit, and expected magnitude. The only real omission is differentiation from snapshot_rc_delta and channel-count specifics.

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 no parameters, so the 4 baseline applies. The description correctly implies a parameterless read of all RC channels and adds only unit context, which is appropriate.

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?

Names a specific verb+resource ('Valeurs actuelles des canaux RC') and adds the unit (µs) and expected range, so an agent knows exactly what is returned. It does not, however, distinguish itself from the very close sibling snapshot_rc_delta, which also deals with RC channel values.

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 guidance on when to call this versus alternatives such as snapshot_rc_delta, nor any stated preconditions (e.g. connection state). Usage must be inferred from the name alone.

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 declare readOnlyHint=true and openWorldHint=false, so the agent knows it's a safe, non-mutating, local read. The description adds only the list of sensors covered, which is useful but not rich behavioral context (e.g., return format, whether it reflects live or stored config). With annotations covering safety, a 3 is appropriate.

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 phrase that efficiently states what the tool does. It is slightly terse and lacks a verb, 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?

Given the tool has no parameters, no output schema, and annotations covering the safety profile, the description is minimally adequate. It tells what configuration is retrieved but doesn't say how it relates to other config getters or whether it returns a structured object. For a simple getter, this is acceptable but not 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?

There are zero parameters, so the baseline is 4. The description correctly implies no input is needed and specifies what information is returned. No parameter semantics to add.

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 the resource ('Configuration des capteurs') and enumerates the sensor types (accelerometer, barometer, magnetometer), so the agent knows it retrieves sensor configuration. However, it lacks a clear verb, reading as a noun phrase rather than stating 'returns' or 'gets'. It also doesn't differentiate from siblings like get_filter_config or get_advanced_config.

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 guidance on when to use this tool versus alternatives such as get_imu_data or get_attitude, which may overlap in sensor-related data. No context of use is provided.

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 and openWorldHint=false. The description adds no behavioral context beyond that—no return format, pagination, or scope exclusions—so it earns little beyond structured data.

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 sentence that is front-loaded and contains no filler or redundant 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?

For a zero-parameter, read-only list tool with annotations covering safety and no output schema, the description is nearly complete. It still omits any routing or usage context relative to sibling tools.

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 input parameters, so the baseline score is 4. There is nothing further to clarify in the description.

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 'Liste' and resource 'voltmètres', with scope 'disponibles sur le FC'. It does not differentiate from sibling sensor-list tools such as get_current_meters or get_battery, so it is clear but not sibling-distinguishing.

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 when-to-use, when-not, or alternative-tool guidance is provided. The name implies a list operation, but routing among the many sibling get_* tools is left implicit.

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 and openWorldHint=false, so the safety profile is covered by structured data. The description adds the useful behavioral detail that detected Betaflight flight controllers are flagged over USB, but does not describe the shape of the returned port list or any ordering/completeness guarantees.

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 short sentence with the core action front-loaded and no filler. Every clause (list ports, is_betaflight meaning) carries 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?

With no output schema present, the description carries the full burden of explaining return values, yet it only explains one field (is_betaflight) and omits the rest of the port record shape (device name, path, etc.). For a zero-param list tool this is adequate but leaves a real 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?

The tool takes zero parameters, so per the rubric the baseline is 4. Nothing in the description is needed to disambiguate parameters, and none are misdescribed.

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 gives a clear verb+resource ('Liste les ports série') and the resource is unique among siblings, so an agent can identify it without confusion. It adds a hint about one returned field ('is_betaflight signale les FC Betaflight détectés'), though this drifts into output territory rather than pure purpose.

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 use this tool, when not to, or which sibling to prefer (e.g. versus get_board_info or connect). Usage must be inferred entirely from the tool name and resource.

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 cover safety (readOnlyHint=true, openWorldHint=false), and the description adds behavioral context beyond that: it polls for N seconds at ~50 Hz and the returned figure is a 95th-percentile deviation, not a raw reading. It doesn't mention blocking behavior during the measurement window, so it stops short of full 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?

Two sentences: the first front-loads the action, sampling rate, and return values; the second states the usage precondition. 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?

With no output schema and only two well-documented parameters, the description carries the return semantics (noise percentile + suggested deadband) and the usage precondition adequately. Minor gap: it doesn't say what the caller should do with the suggested deadband or how the N-second poll behaves for 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 100% – channels (0=roll…17=aux14, default all) and duration_s (max 60) are already documented in the schema. The description adds 'par canal' for the deadband output but no new parameter syntax or format detail, so baseline 3 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?

States a specific verb (poll) and resource (RC channels) plus exactly what it returns: measured noise as the 95th percentile of deviation and a per-channel suggested deadband. This distinguishes it from siblings like get_rc, snapshot_rc_delta and detect_rc_mapping, which have different outputs.

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?

"À utiliser sticks au repos" gives a clear condition for correct use (the measurement is only meaningful with sticks at rest). It does not name alternatives or state when not to use it, but the placement condition is explicitly given.

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?

Annotation already flags this as destructive and non-idempotent, so the description earns credit for going further: it discloses the guard condition ('refusé si armé'), the post-condition (the connection is closed by the call), and the required recovery step with timing. That is exactly the behavioral context an agent needs before invoking a destructive reboot.

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 short sentences, both load-bearing: the first covers the action and its refusal condition, the second covers the side effect and recovery. Nothing is padded and the refusal condition 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 no-parameter destructive tool with no output schema, the description covers the essential pre-state, post-state, and recovery guidance. The only minor gap is the vague 'quelques secondes' timing and no note on what the agent should observe to confirm the FC is back up.

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 there is no parameter semantics to explain; baseline is 4. The description correctly contains no parameter discussion, though there is nothing extra it could add here.

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 ('Redémarre le FC') and immediately couples it with a scope condition ('refusé si armé'). An agent can distinguish this from sibling connect/disconnect/get_fc_status without opening any 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?

Gives a clear precondition for refusal (armed state) and a follow-up action (call connect after a few seconds). It does not name an explicit alternative tool or say when a restart should be chosen over, e.g., disconnect + connect, but the operational context is unambiguous.

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 destructiveHint=true, idempotentHint=true and readOnlyHint=false, so safety is covered. The description adds context annotations cannot convey: the write target is EEPROM (persistent, overwriting stored config) and this call is a mandatory completion step in a write workflow, which materially changes how an agent sequences its calls.

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 sentence with the action and destination front-loaded and the workflow obligation in a short parenthetical. Nothing is padded and no sentence 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?

With no output schema, no parameters and full annotation coverage, the description supplies what an agent needs to call it correctly. It could go slightly further by noting side effects common to EEPROM commits on flight controllers (e.g. brief disconnect/reboot), but nothing essential is absent.

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 no argument syntax the description needs to explain. No parameters are left 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 verb and resource ('Sauvegarde la configuration courante') plus the exact destination ('en EEPROM du FC'), so the agent knows this persists config to non-volatile memory rather than just reading or transmitting it. The parenthetical ties it to the SET-family siblings, distinguishing it from every get_*/set_* tool in the list.

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?

'obligatoire après tout SET' gives an explicit triggering condition, which is exactly the routing information an agent needs after calling set_pid_values, set_rates, etc. It stops short of stating when NOT to call it (e.g. after pure read operations) or naming specific alternatives, so it falls just below the full when/when-not/alternatives bar.

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?

Adds substantial behavior beyond the annotations: out-of-range indices are silently ignored by firmware, the call is rejected while armed, persistence requires a separate save_config, and firmware may auto-change the PID profile on battery connect. These side effects and guards are not derivable from destructiveHint/idempotentHint alone.

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 and each sentence carries distinct information (index handling, armed guard, persistence, auto-switch). It is dense but not padded; the trailing note is the only slightly tangential element.

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 mutation tool with annotations and no output schema, the description covers guards, persistence semantics, and an unexpected side effect, which is close to complete. It could still clarify whether rates/battery selections share the same persistence and auto-switch caveats.

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 100%, so the schema already documents kind (enum) and index. The description adds only that the profile count varies by firmware and the 2026.6+ applicability, which is marginal over 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?

States a specific verb ("Active") and resource ("un profil PID, de rates ou batterie") with the applicable firmware version. An agent can tell it activates one of three profile kinds rather than reading them, though it does not explicitly name which siblings (e.g. get_profiles, set_battery_profile) it supersedes.

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 real preconditions: refused when the FC is armed, and the selection only survives reboot after save_config, plus a pointer to get_pid_advanced for auto-switching. No explicit "use this instead of X" routing, so it stops 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?

Annotations already flag destructive=true and idempotent=true, but the description adds the preconditions and side effects that matter: rejection while the FC is armed, the mandatory save_config + reboot_fc follow-up sequence, the reboot_required signal in the response, and the firmware version floor. This is exactly the behavioural context 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 and the pointer to get_battery_config are front-loaded, and each following clause carries a distinct constraint (units, ordering, sensor rule, workflow, version, armed refusal). It is dense but no sentence is filler; slightly telegraphic phrasing is the only cost.

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?

One required nested object with full schema coverage, no output schema, and the description covers the remaining gaps an agent needs: preconditions, follow-up tools, refusal state, and the reboot_required response signal. Nothing required to call it correctly is missing.

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 100%, so baseline is 3, but the description adds real meaning beyond the schema: the mandatory ordering min <= warning <= max, the 0.01 V unit convention, and the rule that current_meter=NONE applies when the FC lacks a current sensor. These are constraints the schema does not encode.

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 (modify battery config) and immediately disambiguates from the sibling get_battery_config by naming it as the reference for CLI names. An agent can tell this is the write counterpart to get_battery_config without opening either 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?

Gives concrete usage conditions: refused when the FC is armed, requires save_config then reboot_fc when changing a measurement source, and requires Betaflight 2025.12+. It does not, however, contrast this tool with the neighbouring set_battery_profile/set_battery_config vs profile tools, so the alternative-selection guidance is incomplete.

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 destructiveHint=true, idempotentHint=true, readOnlyHint=false, so the safety bar is lower. The description still adds real value beyond them: partial-update semantics ('only provided fields change'), the min<=warning<=full<=max validation rule, the armed-state refusal, and the fact that persistence requires a follow-up save_config call.

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?

Four tight clauses, front-loaded with the action and target, then validation, precondition, and required follow-up. 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?

For a mutation tool with no output schema, it covers the key gaps an agent needs: partial update semantics, validation ordering, state precondition, and the persistence step. What it lacks is guidance on failure modes (invalid index, rejected values) beyond the armed case.

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 100%, with index range and per-field firmware ranges already documented in the schema. The description restates the ordering constraint that the schema already states, adding no new parameter-level detail beyond the 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?

Specific verb+resource+targeting key: modifies a battery profile by index. An agent can tell it apart from get_battery_profiles and set_battery_config by the index-based profile scope, though the description never explicitly contrasts itself with the similarly named set_battery_config 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?

Gives concrete operational context: requires Betaflight 2026.6+, is refused when the FC is armed, and instructs to call save_config afterwards. It stops short of naming alternatives or stating when-not-to-use beyond the armed precondition.

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 the safety profile (destructive, idempotent, non-read-only), yet the description adds substantial behavior: partial-update semantics, the firmware may silently correct inconsistent values and the response returns re-read values, the armed refusal, a firmware/API version gate, and a required follow-up call. This is well beyond what structured fields 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?

Six compact sentences, front-loaded with the mutation action followed by scope, behavior, constraints, and the next step. Dense but every sentence carries distinct information; minor cramping from packing version, armed gate, and follow-up into one block.

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 mutation tool with a single nested object parameter, full schema coverage, and no output schema, the definition covers everything an agent needs: what changes, version prerequisite, armed guard, silent firmware correction with re-read confirmation, and the required save_config follow-up.

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 100% and the schema already enumerates every accepted setting, its firmware range, and enum literals, so the baseline is 3. The description adds that keys use Betaflight CLI names and points to get_filter_config as the naming source, which is a modest but real gain over 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 opens with a specific verb+resource ('Modifie des filtres') and immediately scopes it: global gyro filters plus D-term and yaw_lowpass_hz of the active PID profile. It references the sibling get_filter_config for CLI naming, so an agent can distinguish this from the read-only counterpart and from set_pid_values without opening any 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 clear operational context: only supplied fields change, the FC must not be armed, the tool requires Betaflight 2025.12+ / API >= 1.47, and save_config must be called afterwards. It does not name competing setters (e.g. set_pid_values) or state when-not-to-use beyond the armed refusal, so it falls short of full routing 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?

Beyond the annotations (which already flag destructive/idempotent/non-read-only), it discloses partial-update semantics ('Seuls les champs fournis changent'), the armed-state refusal, firmware/API gating, that values are re-read on return, and the persistence requirement via save_config.

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?

Dense but front-loaded: purpose first, then partial-update rule, then the side effect, gating, refusal condition, return behavior and follow-up. Every sentence earns its place, though the run-on sequencing is slightly crowded.

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 mutation tool with a deep nested schema and no output schema, it covers prerequisites, failure conditions, return behavior and the required follow-up call, leaving nothing an agent needs missing.

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 100% and the single nested object is exhaustively documented per field, so the baseline is 3; the description adds the update-only-provided-fields contract and routes the agent to get_pid_advanced for valid CLI names, plus the simplified_pids_mode side effect.

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 (Modifie) plus resource and scope (réglages PID avancés du profil actif), and points to get_pid_advanced for CLI field names, which cleanly separates it from the getter and from set_pid_values.

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 sequencing guidance ('Appeler save_config ensuite') and a prerequisite (Betaflight 2025.12+/API 1.47, refusé si FC armé), plus a semantic warning about simplified_pids_mode=OFF. It does not explicitly contrast with set_pid_values, so it falls short of full when-not routing.

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 it is a write operation (readOnlyHint=false), destructive (destructiveHint=true), and idempotent (idempotentHint=true). The description adds useful behavioral context beyond that: it clarifies that only the specified axis is modified while other axes are preserved, and it warns that save_config must be called afterwards to persist changes.

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 short sentences plus a follow-up instruction, with the core action and scope front-loaded. Every sentence earns its place: it names the action, the preserved scope, and the required next step.

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 4-parameter configuration setter with full schema coverage and rich annotations, the description covers the essential action, the partial-update semantics, and the save_config follow-up. It does not mention prerequisite connection state, but that is a minor gap given the annotations already convey the safety profile and there is no output schema to explain.

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 100%, with all four parameters documented in the schema (including ranges 0-250 and the axis enum). The description repeats the axis list but adds no new syntactic or semantic information about the P, I, and D parameters, so the schema carries the full burden and the baseline of 3 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 states a specific verb ('Modifie') and resource ('valeurs PID pour un axe') and enumerates the valid axis values. It is clearly distinct from read-oriented siblings like get_pid_values, but it does not distinguish itself from the more advanced sibling set_pid_advanced, so it falls short of a 5.

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 when to use the tool (to change PID values for one axis) and provides a crucial follow-up instruction to call save_config afterwards. However, it gives no explicit guidance on when to prefer this over alternatives like set_pid_advanced or set_rates, so usage guidance remains implied rather than explicit.

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 destructive=true and idempotent=true, so the safety profile is covered. The description adds real behavioral context beyond them: only supplied params change, values are interpreted in the FC's CURRENT rates_type units, and the call returns re-read values plus max_rate_dps.

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 paragraph that front-loads the action and partial-update rule before the unit caveats and the save_config follow-up. Slightly redundant with the per-parameter schema text, but every sentence carries operational 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?

For an 11-parameter mutation tool with no output schema, the description covers the missing pieces: unit interpretation depends on rates_type, all params are optional, and the return payload (re-read values + max_rate_dps) is disclosed. Only the exact error/failure behavior is unstated.

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 100% (baseline 3), and the description goes further by tying each parameter's meaning and expected range to the active rates_type (e.g. ACTUAL → rc_rate is Center Sensitivity in °/s, BETAFLIGHT → rc_rate 0-2.55, super rate 0-1, expo 0-1), which the schema only alludes 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?

States a specific verb and resource ('Modifie les rates par axe') and immediately clarifies partial-update semantics ('Seuls les paramètres fournis changent'), which distinguishes it from full-config writers like set_pid_values and from the read-side sibling get_rates.

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 explicit workflow ordering: call get_rates first to learn the active rates_type, then call save_config afterwards to persist. This is exactly the when-to-use / prerequisite guidance an agent needs before invoking a state-mutating 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?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond that: it returns only channels exceeding the threshold and names the default (200 µs), clarifying the output shape. It does not describe channel ordering or whether the achieved delta is returned.

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?

Three compact sentences, action front-loaded, then return value, then use case. No filler, though the description is in French while the tool name is English — a minor consistency wrinkle rather than a size problem.

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?

A read-only two-parameter tool with a fully documented schema and no output schema; the description covers purpose, the default threshold, and the intended use case, which is sufficient for correct invocation. The only real gap is not disambiguating against the similar RC-detection 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?

Schema description coverage is 100%, and the schema itself documents both 'baseline' (format, source from get_rc) and 'threshold' (minimum delta in µs, default 200). The description merely restates the default threshold, adding little the schema does not already carry. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (compare current RC snapshot to a baseline) and even names the return semantics (channels whose delta exceeds the threshold). It contrasts implicitly with the raw get_rc by referencing the get_rc channels format as the baseline. It doesn't explicitly name a sibling to differentiate from detect_rc_channel_move, which is its closest analogue.

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 concrete use case — detecting which channel moves when a stick or switch is actuated — which implies when to reach for it. But it never names alternatives (detect_rc_channel_move, measure_rc_noise, detect_rc_mapping) nor any when-not condition, so the agent must infer routing from context.

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