Betaflight MCP

by bvandevliet

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0-alpha
Disambiguation5/5
Every tool has a uniquely named parameter or action, and the descriptions clearly distinguish each one. There is no ambiguity between tools.
Naming Consistency5/5
All tools follow a strict verb_noun pattern (get_*, set_*, calibrate_*, cli_*, etc.) with consistent snake_case naming. No mixed conventions.
Tool Count2/5
With 795 tools, the server is massively overgrown for typical MCP use. While it comprehensively covers Betaflight parameters, such a large number overwhelms the interface and leads to poor agent navigation.
Completeness5/5
The server provides exhaustive coverage of Betaflight configuration parameters, including get/set for virtually all settings, calibration routines, CLI commands, and flight data retrieval. No obvious gaps for the intended domain.
Average 3.7/5 across 648 of 795 tools scored. Lowest: 1.7/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 23 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavior. It states reordering happens 'without rewiring', but does not mention side effects, required conditions, or the inconsistency between described parameters and 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.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a redundant title and a parameter hint that conflicts with the schema. It could be restructured to clarify the parameter issue.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (motor output reordering is a significant operation), the lack of output schema, annotations, and the contradictory parameter mention make the description incomplete and confusing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implies parameters (output indices) but the schema declares zero properties. This contradiction undermines semantic clarity. Schema coverage is 100% only because there are no properties, so the description adds no valid parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description claims the tool reorders motor output channels, but contradicts itself by mentioning parameters ('Specify the output index') while the input schema has no properties. This makes the purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or distinguish it from siblings. The description does not address contexts or alternatives among the many get/set tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry behavioral disclosure. It does not state whether this is read-only, has side effects, or what happens on invocation. The '[UINT8, 0–150, default: 0]' contradicts the empty parameter schema, causing confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short but relies on an ambiguous cross-reference and includes technical bracket notation that does not belong in a description. Structure is poor.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to explain what 'vbat_duration_for_critical' means, what the returned value represents, or how it relates to other battery tools. With no output schema and minimal description, the tool is insufficiently documented for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. However, the description includes a misleading spec that seems to describe a parameter but no actual parameter is defined, reducing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description only says 'Get vbat_duration_for_critical: Same as above but for the critical threshold.' It relies on an unclear 'above' reference and does not clearly state what the tool does. The technical spec in brackets does not clarify the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_vbat_duration_for_warning. The description lacks any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. The description mentions it is for SBUS receivers that support fast mode, but does not indicate that it is a read operation (retrieving the current setting), nor does it describe the return value. The conflicting verb 'enable' may mislead about its side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains contradictory and extraneous information (e.g., parameter type/default without schema support). It is not structured clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with no output schema, the description should explain what the returned value represents. It does not, leaving the agent without information about the output format or possible values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes '[UINT8, default: OFF]', implying a parameter exists, but the input schema has no properties (0 parameters). This contradicts the schema. Since schema coverage is 100% (empty), the description should not introduce non-existent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get sbus_baud_fast: Enable fast (200kbps) SBUS mode.' This is contradictory: the tool name suggests a read operation ('get'), but the description describes it as enabling (a write operation). The purpose is unclear and potentially misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like the sibling 'set_sbus_baud_fast'. The description implies a specific use case (SBUS receivers that support fast mode) but does not clarify that this is a read operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the tool name (says 'Enable' for a getter). No annotations exist to clarify behavior. The description also mentions a default value without explaining its significance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short, but the two fragments are not well-structured and contain contradictory information. It is not concise in a helpful way.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns (e.g., current pull-up state). It does not. The context of parameters is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0 parameters, so baseline is 4. However, the description adds no meaningful parameter info; mentioning '[UINT8, default: ON]' is irrelevant without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name indicates a getter, but the description says 'Enable pull-up' which implies a write operation. This misalignment makes the tool's actual purpose unclear and misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives like set_usb_msc_pin_pullup. The context of use is not provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must clarify behavior. It says 'Enable' which suggests a write operation, conflicting with the 'get' naming. This inconsistency misleads the agent about whether the tool is safe or mutating.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but the structure is flawed due to the misleading action verb. The bracketed info adds minimal value without context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks output schema, so description should fully explain what the tool returns (e.g., current half-duplex state). It does not describe possible values or behavior. Also fails to mention the existence of a set_ variant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has no parameters, so description should explain what the tool returns. It mentions a UINT8 with default OFF, which might indicate the return format, but it's unclear and not linked to any schema definition. The 'Enable' phrasing further confuses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description contradicts the tool name by saying 'Enable' while the name implies reading. It merely restates the tool name and adds an action that doesn't match the 'get' prefix. The purpose of retrieving the current half-duplex setting is not clearly stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over siblings like get_esc_sensor_halfduplex or get_serialrx_halfduplex. It does not explain the context or provide any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description notes a requirement, but it confuses get and set behavior. Without annotations, the description should clearly indicate this is a read-only operation, but it instead suggests mutation. The return type hint [UINT8, default: OFF] is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes a redundant prefix 'Get i2c1_pullup:'. This could be removed for conciseness without loss of meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks a clear explanation of what the tool returns or how the pull-up state is represented. Given no output schema, more detail about the return value is needed. The requirement is included, but overall it's incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. However, the description provides a requirement and hints at the return value format, which adds some value, but the confusing wording reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get i2c1_pullup' but then describes 'Enable internal pull-up resistors', which is a set action. This is misleading and fails to clearly state that the tool retrieves the current pull-up configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a requirement ('Requires: USE_I2C_DEVICE_1'), but provides no guidance on when to use this tool versus its sibling 'set_i2c1_pullup' or other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure, but it only states it's a get operation (implied by name) and includes an ambiguous '[UINT8, default: 0]' which may refer to return type but is not clearly labeled. No side effects, auth needs, or other behaviors are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but wastes words by repeating the tool name. The inclusion of type information is useful but poorly formatted, mixing with the title. It could be more concise and structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fails to provide any context about what 'pitch expo' means, its role in the system, or how the returned value is used. Without output schema, the agent has no idea what to expect from this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema is empty, so parameter semantics are not applicable. The description's '[UINT8, default: 0]' could be misinterpreted as a parameter but is likely describing the return value. Since schema coverage is trivially 100%, the description does not need to compensate, but the unclear annotation reduces its value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description essentially repeats the tool name ('Get pitch_expo: Pitch expo') without specifying what 'pitch expo' refers to in the system context. It fails to distinguish this tool from siblings like get_roll_expo or get_yaw_expo, leaving the agent guessing about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Among hundreds of sibling tools, there is no indication of prerequisites, context, or scenario where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description contradicts the tool's own name and expected behavior: it says 'Overclock' (a mutation) but the tool is a getter with no parameters. No annotations exist to clarify read-only nature. This is a serious omission for a tool that should be non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but packs a misleading verb. It could be concise if accurate, but the inaccuracy makes it poor. Slightly below average due to ambiguity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description fails to explain what the tool returns. Among many sibling getters/setters, it does not clarify its role. The description is incomplete and misleading for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline score of 4 applies. The description does not add parameter-specific information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name indicates a getter ('get_'), but the description uses the verb 'Overclock', which implies a mutation. The tool's purpose is ambiguous: it appears to both retrieve and perform an overclock action, lacking a clear, consistent verb-resource pairing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage condition ('Use only if CPU load is too high and the board supports it') that is more appropriate for a setter. There is no guidance on when to use this getter versus the sibling set_cpu_overclock or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description claims the tool 'enables' crash recovery, which is a write operation, but the tool name and empty input schema indicate it is a read-only getter. This is deeply misleading. With no annotations to clarify, the description actively contradicts the expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but poorly structured. It mixes a contradictory purpose statement with parameter-like details. It could be cleaner by stating explicitly that it retrieves the current crash recovery mode and then explaining the possible values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations or output schema, the description should clearly explain what the tool returns and that it is a read operation. It fails to do this, instead using language that implies a write. The mention of values is helpful but incomplete without confirming that it is a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100% (empty). Per the guidelines, baseline is 4. However, the description adds something by listing possible values (BEEP, DISARM, OFF) and the default, which provides some meaning about the output. But the confusion over whether this is a getter or setter reduces the value to a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get crash_recovery: Enable crash recovery,' which is contradictory: 'Get' implies retrieving a value, but 'Enable' suggests setting or modifying. It does not clearly state that the tool reads the current crash recovery mode setting. The mention of BEEP, DISARM, and OFF further confuses, as these are configuration values, not actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its sibling 'set_crash_recovery'. The description lacks any context about appropriate usage scenarios, prerequisites, or differentiation between reading and writing crash recovery settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description claims to 'Enable' but the tool name is 'get', creating confusion about whether this tool modifies state or only reads it. No mention of side effects, permissions, or that it simply returns the current value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is overly terse (one sentence) and redundantly repeats the tool name. It could be improved by removing the name repetition and clarifying the read-only nature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description should at least state that this is a read-only retrieval of a boolean (or UINT8) setting. The current wording 'Enable...' misleads the agent into thinking it performs an action, leaving the tool's actual behavior ambiguous.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters with 100% coverage. The description adds a type hint '[UINT8]' and default 'OFF', which provides some insight into the value format. However, with no parameters, the added value is minimal but acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get use_cbat_alerts: Enable capacity-based OSD/beeper warnings.' This mixes a 'get' verb with 'enable', suggesting it both retrieves and activates the setting, which is contradictory. The name indicates a read operation but the description implies a write.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_use_vbat_alerts (voltage-based alerts) or set_use_cbat_alerts (to modify the setting). The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavior. It implies a mutation ('Reverses') which contradicts the read-only nature of a get tool. No mention of side effects or safety.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but misleading. The first sentence incorrectly describes a set action, making conciseness detrimental.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should clarify what value is returned. It does not state that the tool returns the current state of yaw_control_reversed, nor does it explain the possible values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is trivial. The description adds value by specifying the INT8 type and default OFF, which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Reverses the direction of yaw stick,' which describes a set operation, but the tool is a get tool. This is misleading. The data type and default are mentioned, but the core action is wrong.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_yaw_control_reversed or other yaw-related get tools. Lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It claims 'recalibrates gyro' which conflicts with the 'get' naming, and does not clarify whether the tool reads a setting or performs an action. The note '[UINT8, default: OFF]' hints at a parameter reading but is ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but wastes the first sentence by repeating the tool name. The remaining sentences are functional but could be better structured to avoid redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify what the tool returns. '[UINT8, default: OFF]' hints at the return type but is vague. The tool's overall purpose (read vs. write) is not clearly defined, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the description does not need to explain input semantics. However, the included '[UINT8, default: OFF]' is contextually useful but could be misinterpreted as a parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Recalibrates gyro on first arm' which implies a write action, but the tool name is 'get_gyro_cal_on_first_arm', suggesting a read operation. This contradiction makes the purpose unclear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Useful if the FC warms up and gyro drifts before the first arm,' providing a specific use case. However, it does not mention when to avoid using the tool or suggest alternatives from the extensive sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It fails to clearly state that this is a read operation returning profiling data, and the phrase 'Enables CPU task profiling' is misleading for a getter. The output format or behavior is not described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three segments) but includes extraneous details about turning off and default values that are more appropriate for a setter. It is not concise in its purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what the tool returns. It only vaguely mentions 'CPU task profiling visible via `tasks` CLI command' without specifying the format or structure. The tool is part of a large family of get_* tools but lacks integration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter info is needed. However, the description includes '[INT8, default: ON]' which is irrelevant and potentially confusing, as it suggests a parameter that does not exist. This adds no value and undermines clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get task_statistics' but then says 'Enables CPU task profiling', which conflates a getter with an enabling action. The purpose is somewhat clear as retrieving profiling data, but the verb mismatch reduces clarity. It does distinguish from siblings by referring to task statistics specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'get_tasks' or 'cli_status'. The mention 'Turn OFF to reduce overhead' is more relevant to a setter and does not help with tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavioral disclosure. It does not state that the tool is read-only, what it returns, or any side effects. The focus is on the parameter's effect rather than the tool's behavior, leaving the agent uncertain about the output.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short but mixes tool purpose, parameter explanation, and usage tips. It could be restructured to separate the tool's action from the parameter description. The addition of the bracketed type info is unnecessary and confusing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters, no output schema, and no annotations. The description fails to explicitly state what the tool returns (the current thrust_linear value). While it explains the parameter's meaning, it omits critical information about the return format or how to interpret the result. A complete description would say 'Returns the current thrust_linear value (UINT8, 0–150)'.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, yet the description includes '[UINT8, 0–150, default: 0]', which describes a non-existent parameter. This directly contradicts the schema and misleads the agent. Schema coverage is 100% (no params), so the description should not add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get thrust_linear', clearly indicating the tool retrieves the thrust_linear setting. However, it conflates the tool action with an explanation of the parameter effect, which slightly dilutes clarity. A more precise statement like 'Retrieves the current thrust_linear value' would be better.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides advice on parameter values ('20–40% is typically enough') but no guidance on when to use this tool versus siblings. Given the sibling set_thrust_linear, it would help to mention that get_thrust_linear is used to read the current value before modification. No context on tool selection is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description adds confusion by saying 'Enable' for a getter. It does not indicate that the tool is read-only, non-destructive, or retrieves a configuration value. The behavioral purpose is unclear due to the verb mismatch.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence plus parenthetical requirement and type/default. However, the first word 'Enable' is misleading for a 'get' tool, reducing structure effectiveness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter of a single setting, the description covers the prerequisite and gives the type/default. However, it does not specify the format of the returned value (e.g., 0 for OFF, 1 for ON) or clarify if it returns the entire pullup configuration. No output schema exists, so more detail would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (empty schema), so the description provides additional context by specifying the setting type (UINT8) and default value (OFF). This helps the agent understand what the returned value represents, adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Get i2c2_pullup' but then describes 'Enable internal pull-up resistors', which is a mismatch: 'Get' implies reading a current state, while 'Enable' suggests a write operation. This contradiction confuses the tool's purpose. The resource 'i2c2_pullup' is clear, but the verb is misleading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_i2c2_pullup or get_i2c1_pullup. Only a prerequisite is mentioned (USE_I2C_DEVICE_2), but no context on typical use cases or differentiation from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only repeats schema constraints (UINT8, 0–150) and mentions a default (0). It does not describe side effects, persistence, or whether a restart is required, leaving important behavioral information missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but the phrase 'Same as above' indicates it was likely copied from a list without adaptation. This reduces clarity and suggests poor structure, as the description should be self-contained.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description does not explain the system-level role of vbat_duration_for_critical (e.g., battery alert duration). The schema covers all parameters, but the agent lacks understanding of the parameter's purpose within the broader battery monitoring context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the default value '0', which is not present in the input schema, providing useful context beyond the schema's min/max/description. This extra information helps the agent understand the expected initial state.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The verb 'Set' clearly indicates a write operation, and the resource 'vbat_duration_for_critical' names the parameter. However, the phrase 'Same as above' is ambiguous because there is no preceding description in this context, making the purpose less clear than it could be.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives like set_vbat_duration_for_warning. The agent receives no context about how the critical threshold differs from the warning threshold or when each is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description claims the tool 'detects' and 'disarms,' which may be misleading for a read-only configuration retrieval. It does not clarify that the tool merely reads the current setting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes redundant repetition of the tool name. It is not overly verbose, but the phrasing could be more efficiently structured to convey purpose without repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain what the tool returns. It only mentions detection and disarming, omitting that it likely returns a numeric value or setting state. The return format and behavior are unclear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds no parameter info, but baseline for zero parameters is 4. The mention of '[UINT8, default: ALL]' appears to describe the return type, not parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it 'detects gyro ADC saturation and disarms,' but as a 'get' tool, it likely reads a configuration value rather than performing detection. The purpose is somewhat clear but ambiguous; it could be interpreted as an action rather than a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Sibling 'set_gyro_overflow_detect' implies a pairing, but no explicit context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It says 'Enable' which implies mutation, conflicting with the tool name 'get' (read). No mention of side effects, return value, or that this is a read of the current state. This is confusing and incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but includes unnecessary markdown formatting (underscores, italics) and the prerequisite in parentheses could be integrated better. It is somewhat concise but not optimally structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description should clarify the tool's behavior (get vs set). It fails to differentiate from siblings like get_i2c1_pullup and does not explain what the returned value represents. The ambiguity about read/write makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to elaborate on parameters. It adds context by specifying '[UINT8, default: OFF]' which hints at the value type and default, though this is not a parameter. This is sufficient given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the resource (I2C bus 3) and action ('Get'), but the phrase 'Enable internal pull-up resistors' contradicts the 'get' verb, causing ambiguity about whether this is a read or write operation. It is somewhat clear but has a mismatch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'set_i2c3_pullup' or similar tools for other I2C buses. Only a prerequisite condition ('Requires: USE_I2C_DEVICE_3') is provided, which does not help with selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose any behavioral traits. It does not mention that the tool is read-only (though implied by 'Get'), nor does it describe side effects, performance, or safety considerations. For a tool with zero annotation coverage, this is a critical gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one line), which is concise, but it is unstructured and lacks separation of purpose from additional info. It reads like a fragment. While no words are wasted, a more organized presentation would improve clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having no parameters and no output schema, the description does not fully explain the tool's purpose. It does not describe what 'pitch super rate' means or how it relates to other tools (like get_roll_srate). The context among hundreds of get_* tools is missing, making it harder for an agent to determine when this specific tool is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is empty. However, the description adds meaningful context about the return value: type (UINT8) and default (67). This goes beyond the schema, which provides no return info. The description compensates by clarifying what data the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the pitch super rate value, using a specific verb 'Get' and resource 'pitch_srate'. It distinguishes from setter counterparts (e.g., set_pitch_srate) and other axis-specific srates (get_roll_srate, get_yaw_srate) by name. However, the description does not explicitly state that it reads a flight controller parameter, relying on context from the many get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not state prerequisites, typical use cases, or when not to use it. Given its simplicity (no parameters), some basic context like 'Use to read the current pitch super rate setting' would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies mutation ('Set') but does not state whether the setting is persistent, requires permissions, or has side effects. The prerequisite is noted but insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one line with parenthetical notes. It front-loads the action and includes essential prerequisites and type info. However, it could be better structured with a more complete sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and the tool is a setter with a non-obvious parameter (align_mag), the description lacks context about what 'align_mag' is, how it affects the magnetometer orientation, or the range of valid values. This is insufficient for an agent to confidently set the correct value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% parameter coverage (one param with description 'Value for align_mag (UINT8)'). The description adds '[UINT8, default: DEFAULT]', which indicates type and default but does not clarify valid values (e.g., range 0-255) or what 'DEFAULT' means. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set align_mag: Magnetometer orientation,' providing a specific verb and resource. It distinguishes from the sibling get_align_mag via the set/get naming convention. However, it does not differentiate from other similar set_* tools beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (Requires: USE_MAG) but gives no explicit guidance on when to use this tool versus alternatives like get_align_mag or other set tools. No when-not-to-use or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states it's a getter (reading custom commands) but does not mention any requirements (e.g., connected flight controller), side effects, or return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but contains the redundant tool name prefix and unnecessary type info ('[UINT8, default: —]') that does not correspond to any parameter. It could be more concise without the extraneous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It fails to explain what the custom commands are used for, how they are formatted in the response, or any prerequisites for invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to add parameter info. However, it includes the irrelevant text '[UINT8, default: —]' which is confusing and may mislead. A score of 3 is baseline for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves custom NMEA sentences for GPS module initialization, specifying it's for NMEA provider only, which distinguishes it from many sibling get_gps_* tools. However, it doesn't specify the format of the returned data (e.g., list of strings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only hints at usage context ('NMEA provider only') but provides no explicit guidance on when to use this tool vs alternatives like get_gps_data or when not to use it. No comparison with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, but it only states the action without any behavioral traits. It does not disclose return format, error conditions, or whether a connection is required. The description is insufficient for an agent to understand side effects or output characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It is efficient but could be slightly expanded to add behavioral details without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of output schema and annotations, the description is too sparse. It does not explain what 'serial port configuration' entails (e.g., baud rate, protocol) or what the return value looks like. The tool requires more context for proper agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100% (trivially). Per calibration, baseline for 0 parameters is 4. The description adds no parameter info, but since there are none, it is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ("Get") and resource ("serial port configuration"), and it is specific. However, it does not differentiate from potential sibling tools like `list_serial_ports`, which might list ports but not their configuration. The uniqueness is implied by the tool name, so it's clear but not explicitly distinguished.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are no prerequisites, exclusions, or context about typical use cases. The agent is left to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions the data type (UINT32) and default (OFF), but does not describe side effects, persistence, or whether immediate changes occur. The description is minimal and omits critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but somewhat redundant: 'Set blackbox_disable_setpoint:' repeats the tool name. It conveys the purpose efficiently, but could be more concise without the leading repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple single-parameter tool, the description should still explain whether changes take effect immediately, if persistence requires a save, or any side effects. The description lacks this context, making it incomplete for an agent to use reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a clear enum and description. The tool description adds the default value ('default: OFF'), which is not in the schema, providing a small extra benefit. However, no further meaning is added beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Set blackbox_disable_setpoint: Exclude setpoint data.' It specifies the resource (blackbox_disable_setpoint) and the purpose (exclude setpoint data). However, it does not differentiate this from many similar sibling tools like set_blackbox_disable_acc, which share the same pattern.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not explain typical scenarios for excluding setpoint data or any prerequisites. With a large set of similar tools, this lack of usage context hinders correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states that it sets the value and mentions the default (OFF), but does not disclose side effects (e.g., whether a reboot is required, if it affects arming, or if changes are persistent). For a configuration tool, such details are important.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences plus type/default) and front-loads the purpose. It contains no unnecessary words, but it could be more structured (e.g., separate sections for behavior, parameters). Still, it is efficient for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers the basic purpose and when it might be needed. However, it lacks details about valid parameter values (e.g., whether to pass 'ON'/'OFF' or 1/0) and does not explain any dependencies or effects on flight controller operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage with 'Value for serialrx_inverted (UINT8)', but the tool description adds a default ('OFF'). However, it introduces ambiguity by saying 'UINT8' while the schema declares the parameter type as string. The meaning of valid values (e.g., numeric 0/1 or string 'ON'/'OFF') is unclear, reducing clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Set) and resource (serialrx_inverted), and explains the action (Invert the serial RX signal) with context about when it's needed (Required for some receivers on certain FC designs). This distinguishes it from other serial RX settings, though not explicitly from siblings like set_serialrx_halfduplex.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a hint about when to use the tool ('Required for some receivers on certain FC designs'), but it does not specify when not to use it, nor does it compare to alternatives like set_serialrx_provider or set_serialrx_halfduplex. The guidance is 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the setting's exclusion purpose and type info, but does not disclose that it is a read-only operation with no side effects. Minimal transparency beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) but lacks structure. It could be improved by front-loading the key information, but it is not overly verbose. Adequate but not exemplary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, and the description does not explain the return value format (e.g., 0 or 1). It only mentions the type and default, leaving the agent to infer the exact output. Lacks completeness for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so description adds no parameter information. According to the rubric, zero parameters yields a baseline of 4, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exclude altitude data' combined with the tool name clearly indicates this retrieves the blackbox altitude exclusion setting. It is specific and distinguishable from sibling tools like get_blackbox_disable_acc, but could be more explicit about returning the current state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Given the many sibling get_blackbox_disable_* tools, it would help to state that this is used to check if altitude logging is disabled, but no such context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description only repeats the tool's name and adds the data type and default value. It does not disclose any behavioral traits such as side effects, required permissions, or whether it reads from hardware or cache.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence plus parenthetical type/default info. It front-loads the key information without unnecessary text, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description provides the basic purpose and data format. However, it lacks context about when auto-rearming occurs or how this setting interacts with other crash-flip parameters. Completeness is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no input parameters, so the description does not need to add parameter details. The description includes the data type and default of the retrieved value, which is slightly helpful but not about input parameters. Baseline score of 3 is appropriate for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'crashflip_auto_rearm' setting and explains what it does ('automatically re-arm after a successful crash flip recovery'). However, it does not differentiate from other getter tools, which are abundant among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While it is a simple getter, the description does not mention when querying this specific parameter is appropriate or what problem it solves.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only says 'Get' without disclosing any behavioral traits (e.g., idempotent, read-only). The default value hint is somewhat helpful but insufficient for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundancy by repeating the tool name. It is front-loaded but could be more concise by removing 'Get f_pitch:'.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description should clarify what value is returned (e.g., current feedforward value) and its unit/format. The default value hint is a start, but overall it is incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are 0 parameters with 100% schema coverage. The description adds a default value of 125, which is not in the schema, providing extra context beyond the minimal schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the feed forward for pitch (f_pitch), distinguishing it from get_f_roll and get_f_yaw. However, the exact meaning of 'feed forward for pitch' may not be immediately intuitive to all agents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives such as get_f_roll or set_f_pitch. The description does not provide any context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies a read operation but discloses no side effects, permissions, or other behavioral traits beyond the output format hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a type hint, very concise. It could be more structured but wastes no words and front-loads the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should fully explain the response. It hints at the format but lacks details about which pins are configured, possible values for active-high/low, open-drain, etc., leaving the agent with incomplete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters, baseline is 4, but the description only adds a type and default hint. It does not explain the meaning of the four UINT8 values, so it adds limited semantic value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get pinio_config: PINIO output configuration', specifying the verb and resource. It distinguishes from sibling getters by naming the specific configuration, though it doesn't differentiate from the related 'get_pinio_box' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_pinio_box' or 'set_pinio_config'. The description does not provide usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description should disclose traits like whether this reads from the flight controller or config, or if it returns a cached value. It only states the type and default, lacking behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a bracketed note), which is concise but lacks structure. It front-loads the name but provides minimal detail, making it adequate but not well-organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
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 should explain the return value's meaning and format. While it mentions UINT8 and default, it does not describe how the scale is used (e.g., multiplier applied to raw RSSI) or any units. Incomplete for a parameterless tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters and 100% schema coverage, the baseline is 4. The description adds value by specifying the return type (UINT8) and default (100), which helps interpret the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves the RSSI scale and specifies the data type (UINT8) and default value (100). The purpose is clear as a getter for a scaling parameter, but could be more explicit about the role of the scale (e.g., multiplier for RSSI readings).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other getters or the related set_rssi_scale. The description does not differentiate it from the many siblings or explain prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the data type (UINT8) and default value (OFF), adding transparency beyond the empty schema. However, no annotations are provided, so the description should clarify read-only nature; it only implies it's a getter via the name. Side effects and safety are not addressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but repeats the tool name. It mixes the getter action with the parameter's function. Could be more concise by leading with 'Retrieves the serialrx_inverted setting' and removing the redundant name prefix.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should specify what the tool returns (e.g., the current inverted setting). It only mentions the default value and type, but not the actual return value. For a simple getter, this omission reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds context about the parameter's meaning (invert signal, required for receivers), which is useful but not required for parameter semantics. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets the serialrx_inverted setting and explains the parameter's purpose (invert signal, needed for some receivers). However, it uses the verb 'Invert' which could be confused with the setter action, and doesn't explicitly state it returns the current value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions the parameter is required for some receivers on certain FC designs, implying when the tool might be relevant, but offers no guidance on when to use this getter versus the setter or related tools (e.g., get_serialrx_halfduplex). No when-not-to-use or alternatives provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the data type (UINT8), valid range (0–100), and default value (0), which cues the agent about the return format. With no annotations, these details partially compensate, but the description does not explicitly state that the operation is read-only or safe, nor does it mention any side effects. There is no contradiction with annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short, but it redundantly restates the tool name ('Get thr_expo:'). The bracketed type/range information is useful. Overall minimalist but could be more efficient by omitting the redundant name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description should explain the meaning of 'throttle expo' (e.g., how it affects throttle stick response) to be complete. Currently, it only provides technical constraints without semantic context, leaving the agent to guess the parameter's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so schema coverage is 100% by default. The description adds value by specifying the return value's type, range, and default, which are not present in the schema. This information helps the agent understand what to expect from the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get thr_expo: Throttle expo' which identifies the tool as a getter for the throttle expo parameter. However, it does not explain what throttle expo is or its role in the system, making it minimally clear. The sibling 'set_thr_expo' distinguishes this as a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, context, or reasons to choose this getter over other getters or set_{thr_expo}. An agent must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states 'Set adc_device' and 'default: 2', but does not mention side effects, persistence, validation, or any constraints beyond the schema. The integer range is vaguely implied by 'INT8' but not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a bracketed note, which is concise and to the point. It is front-loaded with the key action and resource. Slightly more structure could include valid range or impact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is minimal. It lacks explanation of what the ADC device influences, valid values (beyond 'INT8' which contradicts schema min/max), and expected behavior. The contradictory range cues are confusing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter fully (100% coverage). The description adds a default value (2) not present in the schema, which provides extra context. However, it does not explain the meaning of different values or the practical effect of changing the ADC device.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the ADC device used for voltage/current sensing. The verb 'Set' and resource 'adc_device' are explicit. The sibling 'get_adc_device' contrasts by action, but no explicit differentiation is given.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like other set_* tools. No context on prerequisites, effects, or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Only states the requirement. Does not disclose side effects, persistence, or if a reboot is needed. Minimal behavioral information for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with purpose, then prerequisite and type/default. Every part is functional, but could be more informative without being wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple tool with one parameter and no output schema. Description covers prerequisite and default but does not list acceptable values or explain effect of setting. Adequate but has gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (parameter described). Description adds default value 'SPI' and type hint 'UINT8', but no additional semantics beyond what schema provides. Baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states action ('Set baro_bustype') and resource ('Barometer bus type'), with a prerequisite. Distinguishes from its getter (get_baro_bustype) but not from other barometer-related setters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only mentions a prerequisite (USE_BARO). No guidance on when to use this tool versus alternatives like set_baro_hardware or set_baro_i2c_address, nor when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It mentions default OFF and the effect, but there is an inconsistency: description says 'UINT32' while the schema uses a string enum ('OFF', 'ON'). This confuses the expected type. No information on persistence, side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (11 words) and front-loads the purpose. It includes a default value. No wasted words, but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple tool (1 param, no output schema), the description covers the basic purpose and default. However, the type inconsistency and lack of usage context make it less complete. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (enum values described). The description adds only 'default: OFF', which is already implied by the enum ordering. No additional meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set), the resource (blackbox_disable_acc), and the purpose (Exclude accelerometer data). It distinguishes from sibling tools like set_blackbox_disable_alt by specifying accelerometer data. However, it could be more precise about the effect on blackbox logging.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not explain contexts (e.g., reducing log size, troubleshooting) or provide any usage scenarios. The description is purely functional without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behaviors. It only states that attitude data is excluded from logs, but omits details like whether the change applies immediately, persists across reboots, or affects existing logs. The type hint (UINT32, default OFF) is partially redundant with the schema's enum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, fitting in a single line with a clear structure: name, colon, action. It front-loads the tool name and immediately explains the effect. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration setter with one parameter and no output schema, the description covers the basic purpose. However, it lacks details on behavioral implications (e.g., persistence, immediate effect). Given the presence of many similar sibling tools, slightly more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds the default value (OFF) which is helpful but not critical. The parameter's meaning is adequately conveyed by the schema and name. No deeper semantics are added.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to exclude attitude data from logs. The resource (blackbox_disable_attitude) and verb (set) are explicit. While it doesn't explicitly differentiate from other set_blackbox_disable_* tools, the name and content make the intended setting obvious.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other blackbox_disable settings or alternatives. The description merely explains the function without context on selection criteria or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It mentions the default 'OFF' but does not describe side effects, permissions, or any state changes beyond the basic set operation. The description adds little beyond what the schema already indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short sentences that efficiently convey the core purpose and a key parameter detail. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description covers the basic purpose and parameter. However, it lacks usage guidance and behavioral context, which are needed for full completeness, especially given no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the default value and type qualifier ('[UINT32, default: OFF]') beyond the schema's enum and description. With 100% schema coverage, baseline is 3; the additional context is minimal but adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets 'blackbox_disable_debug' to exclude debug fields. The verb 'Set' and resource are specific. While there is a sibling 'get_blackbox_disable_debug', the tool name itself implies a setter, so differentiation is implicit but not explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool or alternatives. The description does not mention prerequisites, context, or contrast with similar tools. It simply states the action without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the basic action (set to exclude unfiltered gyro data) but omits behavioral traits such as whether changes persist, require reboot, or affect flight performance. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an appended type/default hint. It is concise and front-loaded, with no redundant information. The structure could be slightly improved by integrating the default more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean setter with full schema coverage and no output schema, the description covers the basic purpose. However, it lacks broader context such as the effect on blackbox logging or relation to other blackbox disable settings. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds the purpose ('exclude unfiltered gyro data') and default value ('OFF'). While the schema already enumerates values, the description provides context but could clarify the effect of each state. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a parameter to exclude unfiltered gyro data from blackbox logging. It uses a specific verb+resource pattern and the name helps differentiate from sibling setters like set_blackbox_disable_gyro, though no explicit comparison is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, no prerequisites, conditions, or limitations. The description only states what it does, leaving the agent to infer usage context 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions logging exclusion and log size reduction but contradicts the schema by claiming '[UINT32]' when the parameter is a string enum. No disclosure of persistence, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short but includes redundant repetition of the tool name. It could be more efficient by removing 'Set blackbox_disable_pids:' and directly stating the effect. Not overly long, but not optimally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle setting, the description omits critical context: the effect of ON vs OFF values, whether the setting persists, and return behavior. Given many sibling tools, this level of detail is insufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds a default value 'OFF' (useful) while incorrectly stating the type as '[UINT32]' (misleading). The schema already defines the parameter with an enum, so the description adds minimal value and introduces confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool excludes PID data from logs and reduces log size, using specific verb 'Set' and resource 'blackbox_disable_pids'. It distinguishes from sibling tools by explicitly mentioning 'PID data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_blackbox_disable_acc, etc.). It simply states what it does without context or conditions for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects, such as whether the change is immediate or requires reboot, whether it can be set while armed, or how it interacts with other crash settings. Minimal behavioral context beyond the value options.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with the action. It uses a compact format to list options and default. However, the use of brackets and abbreviations slightly hinders readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description is fairly complete but lacks context on when to use each option and behavioral implications. Given many related crash settings, it does not fully stand alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 param). The description adds meaning by listing allowed string values (BEEP, DISARM) and default (OFF), which goes beyond the schema's generic 'UINT8' description. However, it does not map these strings to numeric values or clarify if other numeric inputs are valid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets crash_recovery and explains the allowed values BEEP and DISARM and the default OFF. It differentiates from sibling tools like get_crash_recovery by being the setter, but does not explicitly distinguish from other set_* tools. However, the purpose is specific and clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives, when to choose BEEP vs DISARM, or any prerequisites. The description lacks explicit when/when-not recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behaviors. It mentions the data type (UINT8) and default (PT1), but does not state whether the change is immediate, requires reboot, or affects flight dynamics. This is insufficient for a setter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with no unnecessary words. It is front-loaded with the tool name and purpose. However, it sacrifices content for brevity, missing critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks allowed values or a range for the filter type (e.g., PT1, PT2, Biquad). Since there is no output schema, the agent cannot know valid inputs. This leaves the tool incomplete for autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single parameter described as 'Value for dterm_lpf2_type (UINT8)'. The description redundantly mentions UINT8 but adds the default value PT1. This is a marginal improvement, baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the type for D-term LPF2, which is a specific filter type. It distinguishes itself from siblings by naming the exact parameter being set, avoiding confusion with other set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like set_dterm_lpf1_type or other filter setters. The agent is left to infer context from the sibling list without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits but only gives the type and default value. It does not indicate whether the setting takes effect immediately, requires a save or reboot, or has any side effects on other settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence to convey the purpose, type, and default. It is front-loaded and easily scanned. However, it could be slightly more structured with separate sentences for different aspects.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description omits important context such as units, accepted range (though schematically defined), whether the setting requires a reboot, and its effect on flight dynamics. This leaves the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the parameter description already stating 'Value for dterm_notch_cutoff (UINT16)'. The description redundantly includes the type and default, adding little new meaning. A 3 is appropriate as the description confirms but does not enrich beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets dterm_notch_cutoff and explains it as 'Static D-term notch bandwidth'. The verb 'Set' matches the tool's function and distinguishes it from getter counterparts. However, it does not explicitly differentiate from other dterm-related setters like set_dterm_notch_hz, but the parameter name is unique enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to adjust notch bandwidth versus notch frequency or other filter parameters. No mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should compensate but only states the default (AUTO) and data type. It does not disclose side effects, persistence, or whether a reboot is needed, leaving the agent with insufficient behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at one line plus a bracket note. However, it lacks structural elements like separate lines for type and default, which could improve readability without adding length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple parameter set and lack of output schema, the description is adequate but has gaps. It does not cover valid values or usage context, leaving the agent to infer from the parameter name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description adds little beyond the schema. It mentions the default 'AUTO' but does not explain possible values or the meaning of AUTO, which is minimal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the UTC time standard on UBlox modules, using a specific verb and resource. The purpose is unambiguous, but it does not explicitly differentiate from the get_gps_ublox_utc_standard sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, whether it requires a reboot, or how it fits into the broader configuration context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description only states that it enables pull-up resistors. It does not disclose side effects, persistence across reboots, or other behavioral traits beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—a single sentence with a parenthetical note—and front-loads the action. It contains no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description is reasonably complete: it states the purpose, a prerequisite, and the parameter type. However, it lacks explicit explanation of valid parameter values (e.g., range or options) which would help an agent use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'value' parameter. The description adds the data type ('UINT8') and default value ('OFF'), which provides additional context, though the schema's type is 'string'. The added default is useful but does not specify allowed numeric values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('i2c1_pullup'), and the effect ('Enable internal pull-up resistors on I2C bus 1'). It distinguishes from sibling tools like set_i2c2_pullup by specifying the exact bus. However, it does not explicitly compare with other similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires: USE_I2C_DEVICE_1') indicating when compilation requires this feature, but provides no guidance on when to use this tool versus alternatives (e.g., when not to set pullups, or alternative configuration methods).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the function and provides a hint on type and default ('[UINT8, default: 80]'). There is no disclosure of side effects (e.g., persistence, need to save/reboot, validation beyond schema bounds). With no annotations, the description fails to inform about behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) and includes essential info (type and default). It could be improved by adding behavioral notes, but for a simple setter, it is efficient with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the schema's coverage, the description is minimally adequate. However, it lacks information on persistence, save/reboot requirements, and the relationship to other PID settings. For a tuning parameter, this context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter with a description, but the description adds the default value (80), which is not in the schema. This additional info aids the agent in choosing appropriate values, making the description valuable beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set i_yaw: Yaw I gain' clearly states the action and the resource (i_yaw, which is the yaw axis integral gain). However, it does not differentiate this from other set_* tools for PID gains (e.g., set_i_pitch) beyond the parameter name, so purpose clarity is good but not exceptional.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_i_yaw or other set_* tools. The description lacks any context for usage, leaving the agent without direction on selecting this tool over similar ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only mentions the configuration type and default value, but omits important aspects like persistence (if changes survive reboot), side effects, or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences that front-load the purpose and include a notable default value presentation. It could benefit from a more structured format but is efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema or annotations, the description should thoroughly explain the value encoding, effect of different values, and whether it is persistent. It fails to do so, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a brief description 'Value for pinio_config (UINT8)'. The tool description adds context (active-high/low, open-drain, default format) but does not explain the encoding of the UINT8 value, leaving ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets PINIO output configuration and mentions specific aspects like active-high/low and open-drain. However, it does not explicitly distinguish it from the sibling get_pinio_config, though the name implies the setter role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, nor any prerequisites or scenarios where it should be avoided. The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions setting the value and default, without disclosing any behavioral impact (e.g., changes to flight dynamics, persistence, or required disarming).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line) and front-loads the key information. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context on what pitch_expo does or how it affects flight behavior. The range inconsistency (UINT8 vs schema's large integer range) further reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so description adds minimal value. It does provide the default value (0) not in schema, but the description's mention of UINT8 contradicts the schema's integer range (which allows negative values), causing confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the pitch expo parameter, distinguishing it from other set_* tools that set different parameters. However, it could be improved by explaining what 'pitch expo' means (e.g., exponential rate for pitch control).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_roll_expo or set_yaw_expo. The description does not specify context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states that the setting applies globally in QUICK rates mode and defaults to OFF, but does not disclose whether changes are persistent, require a save, or affect other settings. The lack of side-effect disclosure is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at two sentences. It front-loads the tool name and core action. While it could be more structured (e.g., separate sections), it wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about the QUICK rates mode (e.g., how to enable it, what happens if not active), the meaning of 'expo,' and the relation to get_quickrates_rc_expo. For a simple parameter-setting tool, this missing context reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the single parameter as a UINT8. The description adds the default value (OFF) and reaffirms the type, which is helpful but not extensive. With 100% schema coverage, baseline 3 is appropriate, and the added default provides marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets quickrates_rc_expo and explains its effect (applies expo globally in QUICK rates mode). It mentions the data type and default, making the purpose specific. However, it does not distinguish from the many other set_* tools beyond the name, but the specificity of the resource (quickrates_rc_expo) is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites (e.g., being in QUICK rates mode) or when not to use it. Among hundreds of set_ tools, no usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only states the tool sets a setting with a default of OFF. It does not disclose side effects, required permissions, or whether a reboot is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, consisting of two sentences that convey the purpose and default. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description explains the effect and default but lacks clarity on value format and range. It does not describe the return value or confirmation behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description 'Value for report_cell_voltage (UINT8)'. The description adds default ('OFF') and hints at the expected type, but there is ambiguity between the schema type (string) and the description (UINT8).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a configuration that makes telemetry report per-cell voltage instead of pack voltage. It distinguishes from the sibling 'get_report_cell_voltage' but not explicitly from other similar 'set_' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not specify prerequisites, contexts, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the default value and type, but does not clarify side effects (e.g., persistence, reset behavior), validation, or error conditions for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and includes the purpose, requirement, and parameter details in a compact form. It is front-loaded and contains no filler, though the format could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setter with one parameter and no output schema, the description provides enough basic information (purpose, default, requirement). However, it lacks explanation of the SPA feature or broader context, leaving the agent to guess the role of this setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description of 'Value for spa_pitch_center (UINT16)'. The description adds value by stating the default (0) and the dependency (USE_WING), but does not further clarify the parameter's unit or range constraints beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the 'Setpoint centre value for pitch SPA'. The verb+resource pair is specific and distinguishes from sibling tools like set_spa_pitch_mode or set_spa_pitch_width, which set different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (USE_WING), but gives no guidance on when to use this tool versus alternatives like get_spa_pitch_center or other set_ tools. The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It indicates the tool sets a configuration parameter and notes the required feature, but does not disclose whether changes are persistent, require a reboot or rearm, or take effect immediately. The behavioral impact is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence states the purpose, and the second adds the requirement and type/default info. It is front-loaded and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given it is a simple setter with one parameter and no output schema, the description could provide more context such as units, typical values, or persistence behavior. It mentions 'pitch offset correction' but does not explain the effect of different values, limiting completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds context that the value is a 'pitch offset correction' and states the default is 0, which is beyond the schema's minimal description. However, it does not specify units, allowed range (beyond being an INT16), or how the value relates to other parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the tpa_speed_pitch_offset parameter, a pitch offset correction for speed TPA on wing/fixed-wing trim. It is specific enough to distinguish from other set_* tools, though it does not explicitly differentiate from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires: USE_WING', which gives a condition for use. However, it provides no guidance on when to use this tool compared to alternatives like set_tpa_breakpoint or other speed TPA settings, nor does it explain when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only notes a type hint '[UINT8, default: ON]' but fails to disclose critical behaviors such as whether the change is immediate, persistent across reboots, or requires a reboot. The type hint also contradicts the schema (string vs UINT8).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded, stating purpose directly. However, it could be more structured with separate lines for type and default, and the inconsistency with the schema reduces clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description still lacks completeness. It fails to explain persistence, immediacy, or interaction with related settings (e.g., 'set_use_cbat_alerts'). The type inconsistency further undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema coverage is 100% (parameter has a description), the description adds a default value but contradicts the schema by specifying 'UINT8' while the schema declares a string type. Valid values (e.g., 0/1 or ON/OFF) are not clarified, limiting parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'use_vbat_alerts', and the purpose 'Enable voltage-based OSD/beeper warnings'. This uniquely identifies the tool's function among siblings like 'set_use_cbat_alerts' and 'get_use_vbat_alerts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., current-based alerts). It does not mention prerequisites, side effects, or context for invocation, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose side effects, whether a reboot is needed, or if there are any constraints. The behavior is underspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very brief: one sentence plus bracket info. No wasted words, though it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with no annotations or output schema, the description should at least explain the effect on the system. It does not clarify that this is a configuration parameter or mention validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds default=10 but contradicts the schema's allowed range (UINT8 vs huge max/min). Schema coverage is 100%, so baseline is 3, but the contradiction reduces clarity and reliability.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the voltage divider ratio numerator, with explicit verb 'Set' and resource 'vbat_divider'. It is distinct from sibling tools like get_vbat_divider.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It lacks context such as prerequisites or conditions under which this setting should be modified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not reveal side effects, safety implications, or behavior beyond the basic reversal. The mention of INT8 contradicts the string type in the schema, adding confusion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and includes some redundancy ('Set yaw_control_reversed:'). Could be more structured by clarifying the expected value format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is mostly adequate but missing explicit allowed values and handling of the type mismatch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds a type annotation ('INT8') that conflicts with the schema's string type. It does not explain the allowed values (e.g., ON/OFF) or acceptable formats, reducing clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reverses the yaw stick direction. It distinguishes from sibling tools like set_yaw_deadband and the corresponding get_yaw_control_reversed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No context on prerequisites or recommended scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only mentions the default value and type (UINT8) but fails to disclose whether changes persist, require a reboot, or affect flight behavior immediately. This is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with key info front-loaded. However, it sacrifices context for brevity. It could be slightly more structured (e.g., explaining the parameter's impact) without losing efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is minimally adequate. It covers the action and parameter type/default. However, it lacks any explanation of the effect or prerequisites, which would be helpful for an agent. Not a significant gap, but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter already has a description). The description adds the default value (0) and repeats the type, but does not provide significant additional semantic meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the yaw_expo parameter, using a specific verb and resource. However, it does not differentiate from similar setters like set_roll_expo or explain what yaw expo is, which would help agents select the correct tool among many similar sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives is provided. With numerous sibling setters (e.g., set_pitch_expo, set_roll_expo) and a getter (get_yaw_expo), the description should indicate context or prerequisites for setting yaw expo.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool sets a rate limit but does not mention whether changes take effect immediately, require a reboot, are persistent, or affect other parameters. For a simple setter, this is minimal; missing important behavioral context like side effects or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two brief statements. It front-loads the purpose and includes essential details (type, default). While there is no fluff, it could be slightly more structured (e.g., separate lines for type and default), but overall it respects the 'every sentence earns its place' principle.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema, no nested objects), the description is adequate for a setter but incomplete. It lacks usage context, behavioral details, and does not explain the parameter's unit or valid range beyond schema constraints. A more complete description would include the unit (degrees per second?) and effect on flight behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the parameter description already specifies it is an integer for yaw_rate_limit. The description adds the default value (1998) and reiterates the type (UINT16), which provides marginal added value. Per guidelines, baseline is 3 when schema coverage is high, and no additional semantic richness beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a 'Hard cap on yaw rate' and specifies the data type (UINT16) and default value (1998). It distinguishes the tool from many other set_* siblings, though it does not explicitly differentiate from similar rate limit setters (e.g., set_roll_rate_limit), which would be helpful but the naming convention already implies the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not explain the effect of changing this value, prerequisites (e.g., connected flight controller), or contrast with other set_* tools like set_yaw_rate_limit or set_roll_rate_limit. The agent receives no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only notes the action (set) and provides data type/default, but lacks information on side effects, persistence, required privileges, or whether changes require a reboot. No annotations are present to fill the gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it omits essential behavioral details. Conciseness at the cost of completeness reduces overall utility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the presence of many similar siblings, the description is insufficient. It does not explain the tool's role in flight controller configuration or its effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the data type (UINT8) and default value (67) beyond the schema's generic 'Value for yaw_srate (UINT8)' description. The schema's min/max range is unrealistic, so the description's type hint is more accurate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set yaw_srate: Yaw super rate,' indicating the tool sets a specific rate parameter. However, it does not differentiate from other set_ siblings like set_roll_srate or set_pitch_srate, leaving ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as get_yaw_srate for reading or other set_ tools for different axes. The agent is left without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not mention side effects (likely none), output format, or any prerequisites. A simple 'list' operation, but no details on how the list 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence with no wasted words, but it could be slightly more descriptive about what 'available CLI commands' means or the format. Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should hint at the return type or structure (e.g., a list of command names). It does not, leaving the agent uncertain about the result format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the input schema (100% coverage), so the description cannot add meaning beyond the schema. Baseline 4 is appropriate since there is nothing to describe.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear action (list) and resource (CLI commands on the flight controller), but does not distinguish from sibling tools like cli_defaults or cli_status, which could also list information.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like cli_exec, cli_dump, or other CLI tools. The description only states what it does, not the context for its usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the operation (get) and mentions 'Force' and 'AUTO-detect', but does not disclose side effects, read-only nature, or any other behavioral traits. The description adds minimal behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 16 words, conveying the essential idea. However, it includes type info in brackets that may be more appropriate for output documentation, but the brevity is still effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no annotations, and no output schema, the description is too minimal. It does not explain possible values or the meaning of the returned setting, making it incomplete for an agent to fully understand the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description mentions '[UINT8, default: AUTO]', which likely describes the output value type, not a parameter. This is acceptable as there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'acc_hardware', indicating retrieving accelerometer hardware selection. It mentions 'Force accelerometer driver or AUTO-detect', which conveys the purpose. However, it does not explain what 'acc_hardware' represents (accelerometer driver selection), slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like set_acc_hardware or calibrate_accelerometer. It only mentions the default value and type, which is insufficient for distinguishing usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the return type as INT8 with default 'DEFAULT' but does not explain possible values (e.g., enum options), what 'DEFAULT' means, or any side effects. The description is minimal and lacks detail on what the agent can expect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus a type hint), with no wasted words. It is concise but could be slightly improved by clarifying the 'Override' phrasing. Still, it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should explain the return value. It only states '[INT8, default: DEFAULT]' without mapping integer values to meanings or describing how the source affects behavior. The description leaves the agent with incomplete understanding of the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description does not need to add parameter information, and it correctly omits any.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get altitude_source' and explains its purpose for overriding altitude data source for autopilot and OSD display. It distinguishes from sibling tools like 'get_altitude' (actual altitude) and 'set_altitude_source' (setter). However, the phrase 'Override altitude data source' could be misinterpreted as setting, causing slight confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention that 'set_altitude_source' is for changing the value, or that 'get_altitude' is for actual altitude. Among siblings, there is 'get_altitude_prefer_baro' which might be related, but no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It notes the prerequisite (USE_DSHOT_TELEMETRY) and mentions the type (UINT32) and default (OFF), but does not disclose whether the operation is read-only, has side effects, or what the response format looks like. For a getter, read-only behavior is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—one sentence plus a requirement note and type/default. It is front-loaded with the key purpose. The formatting (colon, underscores) is slightly messy but does not significantly hinder readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description should explain what the tool returns. It does not explicitly say 'returns the current value of the setting'. The prerequisite and type are helpful, but the lack of return value information leaves the agent guessing about the response structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema coverage is 100%. The description adds value by specifying the type (UINT32) and default (OFF), which are not present in the schema. This exceeds the baseline expectation for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Exclude RPM telemetry data' which aligns with the tool name. It identifies the resource (blackbox_disable_rpm setting) and the action (get). However, it does not explicitly state that it returns the current value of this setting, leaving ambiguity for new users.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many sibling tools (e.g., get_blackbox_disable_gyro, get_blackbox_disable_acc). The description does not mention when-not-to-use or provide context for choosing among alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data type, range, and default value, but it is ambiguous whether this is a persistent parameter or a live real-time reading. It does not clarify what the tool returns when called outside of crash flip mode or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short (three sentences) but mixes get and set instructions in a way that may confuse. It could be more tightly focused on the get action. The formatting with brackets for the type/range is helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value's type, range, and meaning. However, it does not clarify that this is a configuration parameter (not a live reading) or relate it to the sibling set tool. The context of when this parameter is relevant (crash flip mode) is implied but could be more explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description adds value by explaining the meaning of the returned value: motor output percentage during crash flip/turtle mode, with range 0-100 and default 0. It clarifies that 0 means disabled and values >0 enable the feature, with 100 recommended.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get crashflip_motor_percent: Motor output percentage during crash flip / turtle mode.' This clearly identifies the tool's purpose as retrieving a motor output percentage related to crash flip mode. It is sufficiently distinct from the many sibling 'get_' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mixes get and set semantics: it explains when to set the value ('set >0 to enable') but does not provide guidance on when to use this get tool versus the sibling set_crashflip_motor_percent. There is no explicit 'when to use' or 'when not to use' advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not explicitly state that the tool is read-only or non-destructive. While 'get' implies reading, the description should confirm no side effects, especially given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very brief but front-loaded with the verb. However, the parenthetical format note seems out of place for a parameterless tool, and the description could be clearer without sacrificing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description provides a minimal explanation of the return value (SBAS mode) but does not elaborate on possible values or their significance. The overall completeness is adequate but not rich.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% coverage, so the baseline score is 4. The description adds a note about the value type and default ('[UINT8, default: NONE]'), which, while more about the return value, does not harm or mislead.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the SBAS (satellite correction) system setting for the region. The purpose is specific and distinct from siblings like 'get_gps_sbas_integrity' by focusing on 'mode' rather than 'integrity', and from 'set_gps_sbas_mode' by being a getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives. The description lacks context about typical usage scenarios, prerequisites, or any hint of when querying the SBAS mode is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool gets a value but does not state it is read-only or safe. The mention of default 84 could hint at expected behavior but lacks explicit safety or operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point, but lacks structure. It combines the purpose, type, and default into a single line, which is functional but not ideally formatted for an agent.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially explains the return value (type and default). However, it does not describe units, range, or any side effects, leaving some ambiguity for an agent unfamiliar with PID tuning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description adds value by indicating the returned value is a UINT8 with a default of 84, giving semantic hints about the output format and typical value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the pitch I gain. It distinguishes from sibling tools for other axes or PID components (e.g., get_i_roll, get_i_yaw, get_p_pitch). The mention of '[UINT8, default: 84]' provides type and default info, though it might be confused as a parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Among hundreds of sibling getters, the description does not help an agent decide between, e.g., get_i_pitch and get_p_pitch. No prerequisites or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool outputs a clock signal and is for advanced debugging. However, it ambiguously includes '[UINT8, default: OFF]' which is unclear whether it describes the return value or a parameter, and no annotations are provided to clarify safety or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short but the first clause repeats the tool name, and the bracketed note is ambiguous. It could be more efficiently written without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description should clearly state what is returned. The '[UINT8, default: OFF]' hint at the value but is not explicit about whether it is the output or a setting. The tool's behavior and output format are insufficiently described.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, yet the description includes '[UINT8, default: OFF]' which suggests a parameter, causing confusion. With 100% schema coverage (no params), the description adds misleading information instead of clarifying the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it outputs the MCO2 clock signal on PC9 pin, which clearly identifies the tool's purpose. The 'Advanced hardware debugging only' qualifier adds context. However, it starts with 'Get mco2_on_pc9:' which is redundant with the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies 'Advanced hardware debugging only', which provides some guidance on when to use, but does not explicitly mention when not to use or suggest alternatives (though the sibling set_tool is implied).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, safety, or side effects. A simple 'gets' implies read-only but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure and additional context. It is minimally adequate but could be improved with more front-loaded information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is minimally complete but does not specify the return type or format. It leaves ambiguity about what 'mixer type configuration' entails.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add parameter details. With zero parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the current mixer type configuration, using a specific verb and resource. However, it does not differentiate from the sibling tool 'get_mixer_type', which likely serves a similar purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'get_mixer_type' or 'set_mixer_type'. The description lacks context for proper tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description indicates a write operation ('Set') but does not disclose any behavioral traits such as persistence, required privileges, effect on flight performance, or whether the change takes effect immediately or after reboot. The minimal description fails to compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that conveys the essential information without redundancy. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides the parameter type and default, but given the tool's place in a large set of similar setters (e.g., set_gyro_notch1_cutoff, set_dterm_notch_cutoff), it lacks explanation of the notch filter hierarchy or how cutoff relates to center frequency. The tool has no output schema, so the description could have added return value info, but it does not. For a simple parameter setter, it is minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'value' parameter as an integer with a wide range. The description adds meaningful context: '[UINT16, default: 0]', clarifying the expected unsigned 16-bit integer type and default value, which is not apparent from the schema alone. Since schema coverage is 100%, this additional information is beneficial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Set gyro_notch2_cutoff: Bandwidth of gyro notch 2.' It identifies the verb and resource but is somewhat tautological, restating the tool name without explaining what 'bandwidth of gyro notch 2' means in the context of flight control filtering. Sibling tools like set_gyro_notch1_cutoff exist, but no differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. There are many similar setter tools (e.g., set_dterm_notch_cutoff, set_gyro_notch1_hz), and the description offers no criteria for selection or context about the parameter's role in the system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'Get ... Exclude battery data,' implying a read operation, but does not explicitly confirm non-destructiveness, authentication needs, or any side effects. The minimal text fails to fully inform an agent about expected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short—a single line with a type hint. It front-loads the tool name and core action. While concise, it omits some useful details (like return format), but for a simple parameterless getter, it avoids unnecessary verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and many similar siblings, the description explains 'Exclude battery data' and provides type/default info. However, it does not clarify the exact return format (e.g., 0/1 or ON/OFF), nor does it link to related settings. It is minimally complete but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds value by including '[UINT32, default: OFF]', which hints at the type and default of the returned value. This provides context beyond the empty schema, though it pertains to the output rather than input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get blackbox_disable_bat: Exclude battery data.' This directly indicates the tool retrieves the configuration setting for excluding battery data from blackbox logging. Among many similar sibling tools for different data types, this one is specific to battery, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No instructions are given on when to use this tool versus alternatives. There is no mention of prerequisites, nor any contrast with the numerous sibling getters (e.g., get_blackbox_disable_acc, etc.). The agent receives no guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It implies a read-only operation via 'Get' and gives the data type and default value. However, it does not disclose idempotency, side effects, or error conditions, which would be expected for a complete behavioral description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (two sentences) and efficient. However, the first sentence restates the tool name, which is slightly redundant. Otherwise, it is concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is minimal. It does not explain the return value format, possible values, or how 'gyrounfilt' differs from 'gyro'. Lacks context about its role in the blackbox system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (100% coverage), so baseline is 3. The description adds nothing about parameters (none exist) but does provide type and default info relevant to the return value, which is helpful but not required for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get blackbox_disable_gyrounfilt' and explains what the setting does ('Exclude unfiltered gyro data'). The verb 'Get' and resource name are clear. However, it does not differentiate from many sibling get_blackbox_disable_* tools beyond the specific parameter name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_blackbox_disable_gyro or set_blackbox_disable_gyrounfilt. No prerequisites, context, or usage scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states 'Get blackbox_disable_rssi: Exclude RSSI data', which implies a read operation but fails to explicitly confirm no side effects. It does not describe what the tool returns or any related behavioral traits like rate limits or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence to convey the tool's purpose. It is front-loaded with the tool name and includes a clear action ('Exclude RSSI data'). No unnecessary words are present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description lacks essential details: it does not state that the tool returns the current setting value. It ambiguously says 'Exclude RSSI data', which could be misinterpreted as the tool performing an action rather than retrieving a configuration. Without output schema, the description should clarify the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (empty). The description adds no parameter information beyond the schema, which is acceptable because there are no parameters to document. The mention of '[UINT32, default: OFF]' describes the setting's type and default, not parameters, but it does not hinder parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves the blackbox setting for excluding RSSI data, distinguishing it from sibling tools like get_blackbox_disable_acc or set_blackbox_disable_rssi. It explicitly mentions 'Exclude RSSI data', making the purpose specific. However, it could be more precise by indicating that it retrieves the current value of this setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as the corresponding setter tool (set_blackbox_disable_rssi). There is no mention of prerequisites, recommended use cases, or when not to use it. Without this, an agent might misuse the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It implies a read operation but does not mention side effects, authorization needs, rate limits, or any mutability. The type and default hint at configurability but lack explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a parenthetical note, making it concise and front-loaded. However, technical jargon like 'UINT8' and 'd_max_pitch' may reduce clarity for less domain-expert agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description provides adequate context (value type, default, behavior context of smooth vs fast flight). However, it does not explain what 'd_pitch' fundamentally represents, which could limit understanding for agents unfamiliar with PID terminology.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline is 4. The description adds value by specifying the returned value's type (UINT8) and default (34), which helps the agent interpret the output. No further parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'd_pitch' value, specifies it's a base D active in smooth flight and boosted on fast moves, and provides the data type and default. This distinguishes it from sibling tools by naming the pitch axis, though it assumes domain knowledge about what 'D' represents in PID control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternative get_d_* tools (e.g., get_d_roll, get_d_yaw). There is no explanation of context or prerequisites, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. It does not mention that this is a read-only operation, any required hardware, or potential side effects, leaving the agent uninformed about key behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence) and includes the name for clarity. The type and default are parenthetically appended, which is efficient. However, it could be slightly more structured to separate the purpose from parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the essential information. However, it lacks context about when this setting applies (e.g., only if a UBlox GPS module is installed) or how it relates to other GPS settings, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no properties, so schema coverage is effectively 100%. The description adds value by noting the type ('UINT8') and default ('OFF'), which provides semantic context beyond the schema's empty definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('Galileo constellation on UBlox modules') and the verb ('Get'). The name closely mirrors the purpose, though the phrase 'Enable Galileo constellation' could imply a write action, causing minor ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that to change the setting one should use the corresponding setter tool (set_gps_ublox_use_galileo), nor any prerequisites or contextual conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation ('Get'), which is standard. No annotations are provided, but the description does not contradict any expected behavior. It would benefit from explicitly stating that the tool only reads a configuration value without side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single line to convey the purpose and a hint about the data type and default. No unnecessary words, though it could be more structured with a separate line for the type/default info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter input and no output schema, the description is minimal. It does not explain what 'i_yaw' (yaw integral gain) is used for, when to retrieve it, or its impact on flight behavior. This lack of context may hinder an agent unfamiliar with PID controllers.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description includes type and default info in brackets ('[UINT8, default: 80]'), which adds vague semantic context about the stored value, but this is not parameter-related. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves the yaw I gain. The verb 'Get' and resource 'i_yaw' are specific, and it defines the parameter as 'Yaw I gain'. However, it does not differentiate from many sibling get tools for other PID parameters, relying on domain naming conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_i_pitch or set_i_yaw. The description offers no context for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that it is a read-only operation or any side effects, though the name suggests a read. The type and default value are helpful but insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, very concise. It front-loads the type and default. However, it redundantly repeats the tool name, which is unnecessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description should fully define the return value. It provides type and default but omits the valid range, unit, or further explanation of 'auto-smoothing aggressiveness'. This is adequate for a simple scalar getter but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain them. It adds value by stating the return type (UINT8) and default value (30), which aids interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'Auto-smoothing aggressiveness for throttle channel', which distinguishes it from sibling getters like 'get_rc_smoothing_auto_factor' and the corresponding setter. However, it unnecessarily repeats the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternative getters or setters. The description lacks context on its role within the RC smoothing system.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry behavioral disclosure. It only states 'Get' and describes the value range, but does not mention side effects, safety, or that it's read-only (implied but not explicit).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single sentence with inline type/range/default info, minimally verbose. Slightly repetitive of the name but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple scalar getter, the description explains the value meaning and constraints. However, it does not explicitly state the return format (though likely just the integer), and lacks output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in input schema; baseline score 4 applies. Description adds no parameter info because none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it's a getter for the number of RPM harmonics to filter per motor, with an example and default. It avoids tautology by explaining the meaning of the value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_rpm_filter_harmonics or other filter config tools). The description does not specify prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not explicitly state that this is a read-only operation or that it has no side effects. With no annotations, the description carries the full burden, and it fails to disclose the behavioral traits beyond the implied 'get' semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence plus a type/default hint. Every word earns its place, and the purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema getter, the description explains what the setting does and includes the type (UINT8) and default (OFF). However, it does not specify the possible values or what the returned value represents, leaving some ambiguity about the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so schema coverage is 100%. The description does not need to add parameter semantics, and none are provided. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Use single-wire half-duplex UART for serial RX (some CRSF implementations)', explaining what the setting does. The name itself is specific, so it distinguishes from other getters. However, it could more explicitly state that it retrieves the current setting value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention when to check this setting or what conditions warrant it. The agent is left to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only reveals the return type and default value ('[UINT8, default: 100]') but does not state that the tool is read-only, what the return value represents, or any side effects. For a get tool, the read-only nature is implied but not explicit, and the lack of output schema leaves the agent uncertain about the response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short fragments. It front-loads the purpose and adds type information in brackets. However, the structure is somewhat informal and could be slightly more organized, such as separating the type info into a dedicated field.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is minimally adequate. It tells the name, a brief identity, and the return type/default. However, it lacks context like the value range (0-255), units, or how this gain interacts with other settings. Given the domain complexity (flight controller tuning), more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline score is 4. The description adds value by indicating the return type and default value (UINT8, default 100), which helps the agent understand what to expect from the response. Since there are no input parameters, additional parameter details are not needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('simplified_d_gain') and adds a brief explanation ('D scaling slider'), which differentiates it from other similar get_ tools like get_simplified_d_max_gain. However, it does not elaborate on the exact role of the D scaling slider in the PID controller, which would further enhance clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There are many related get_ tools for PID gains (e.g., get_d_pitch, get_simplified_d_max_gain) and no criteria for selecting this one. The agent would have to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only gives type and default but fails to disclose that this is a simple read operation with no side effects, or whether it reads from the current profile. Minimal behavioral insight beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded, but it redundantly repeats the tool name. Could be slightly tighter, but still efficient with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should explain the return value more fully. It mentions UINT8 and default 100 but omits range, units, and the meaning of 'I scaling slider' in context. This is adequate but leaves gaps for an agent needing detailed PID semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0), so baseline is 4 per calibration. The description adds value by specifying the value type (UINT8) and default (100), which aids understanding beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the simplified I gain, describing it as 'I scaling slider (independent of P)' and providing type info. This differentiates it from sibling tools like get_simplified_d_gain or get_simplified_master_multiplier. However, it could be more explicit about being a read-only retrieval of a PID parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_simplified_pi_gain, get_simplified_d_gain). The description does not provide context for selection, leaving the agent to infer 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It indicates a read operation with a prerequisite, but lacks details on side effects, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and front-loaded, but includes a redundant repetition of the tool name ('Get spa_pitch_center:'). Still acceptable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Minimal information: states purpose and a prerequisite, but lacks context on return value, related settings, or when to use it among many similar getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100%, so the description need not add parameter info. It is clear and adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the setpoint centre value for pitch SPA, but does not differentiate it from siblings like get_spa_pitch_width or get_spa_pitch_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Only mentions a requirement (USE_WING) without further context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not explicitly state that this is a read-only safe operation with no side effects, though that is implied by 'Get'. There is no mention of permissions, rate limits, or response behavior. The lack of detail makes it insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 10 words, with no wasted text. It front-loads the tool name and includes key details (type, default). However, it sacrifices explanatory depth; a slightly longer description could improve clarity without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description is marginally adequate. It tells the agent what value is retrieved and its type/default, which covers the basic needs. However, without an output schema, the agent might benefit from knowing the exact range (0-255 for UINT8) or the unit of measurement. The lack of explanation for 'yaw expo' leaves a knowledge gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. According to guidelines, baseline is 4 for zero-param tools. The description adds value by noting the return type (UINT8) and default (0), which helps the agent understand the output format. No parameter documentation is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'yaw_expo', making the tool's purpose obvious. It also includes the data type (UINT8) and default value, which enhances clarity. However, it does not explain what 'yaw expo' represents (e.g., exponential rate for yaw), which would improve understanding. Compared to sibling getters, it is adequately specific but not distinguished by context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of conditions, prerequisites, or which sibling tools (e.g., set_yaw_expo) might be related. The agent is left to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read operation via 'Get', but does not explicitly state read-only, no side effects, or any other behavioral constraints. For a simple getter, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence plus a bracket note. It is not wasteful, but could be more structured (e.g., separating type/default into a sentence).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema, so the description provides the essential information (what is retrieved, type, default). However, it lacks details like units, range, or any explanation of the return value, which would make it more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description does not need to add parameter info. The type [UINT8] and default [7] are provided, which is helpful for understanding the returned value, though these are not parameter semantics per se.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the yaw rate at stick center, which is a specific verb-resource pair. It distinguishes itself from sibling get_rc_rate tools by specifying 'yaw'. However, it could be more precise about what 'yaw rate at stick center' means in context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when or when not to use this tool. It does not mention alternatives like get_roll_rc_rate or set_yaw_rc_rate, leaving the agent to infer usage 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not explicitly state that the tool is read-only or non-destructive. While 'get' implies read-only, the description should confirm no side effects. With zero annotation coverage, the description carries full burden but only mentions type/default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one line with essential info (name, brief definition, type, default). Every part is informative. Could be slightly more structured but is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the purpose and value details. However, it lacks units for the yaw super rate (e.g., degrees/sec) and does not describe what the value controls or its range. This leaves some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage). The description provides inline parameter semantics by stating the return type (UINT8) and default value (67), which adds value beyond the empty schema. This compensates for the lack of explicit parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get yaw_srate: Yaw super rate.' It identifies the specific resource (yaw super rate) and verb (get). The phrase '[UINT8, default: 67]' adds value by specifying type and default. While it doesn't explicitly differentiate from siblings like get_pitch_srate, the name and description make the yaw focus unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_roll_srate, get_pitch_srate). No context about prerequisites or typical use cases. The description is purely declarative with no usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as whether this is a persistent change, requires a reboot, or affects other settings. It only states the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence and a parenthetical note. All words are relevant and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is adequate but could mention confirmation or side effects. No output schema exists, so the agent might benefit from knowing what to expect after setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the default value 'AUTO' and hints at the parameter's purpose (force driver or auto-detect) beyond the schema's generic description. However, it does not enumerate acceptable values for the driver, which would be helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Force accelerometer driver or AUTO-detect.' It uses the specific verb 'Set' and resource 'acc_hardware', clarifying the meaning beyond the name. While it does not explicitly differentiate from other 'set_*' tools, the resource name is distinct enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to force a driver vs auto-detect, or prerequisites). The description lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It mentions 'factory calibration' and provides a default, but does not disclose whether writing requires permissions, replaces existing values, or has any side effects. Minimal behavioral insight beyond what the name implies.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that conveys the core purpose and includes a parenthetical with type/range/default. No extraneous words, though it repeats the tool name unnecessarily. Efficient but not maximally compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the parameter's meaning, type, range, and default. However, it lacks context on the calibration's significance or when to use it. Given no output schema and no annotations, the description is minimally adequate but leaves gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds the default value (0) not present in the schema, which aids understanding. Although the schema fully captures range and type, the extra default info provides marginal value beyond what's structured.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Set' and the resource 'adc_tempsensor_calibration110', and clarifies it's the ADC temperature sensor calibration value at 110°C. It adds type, range, and default info. However, it doesn't explicitly distinguish from siblings like set_adc_tempsensor_calibration30, but the name alone differentiates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as set_adc_tempsensor_calibration30 or set_adc_vrefint_calibration. No prerequisites, context, or conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It fails to mention if changes take effect immediately, require a reboot, or are persistent. There is no indication of destructive potential or required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line that efficiently conveys purpose and parameter constraints. It is front-loaded and contains no unnecessary words, though it redundantly repeats the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description lacks context about the significance of the factory calibration, persistence, or the need for a reboot. The sibling tools include a getter, but the setter description does not complete the picture.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear property description. The description adds the default value 'default: 0', which is not in the schema, providing an extra hint. This is a small but valuable addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'adc_vrefint_calibration' with additional context 'ADC internal voltage reference calibration (factory)', making it unambiguous and distinct from sibling set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It mentions 'factory' but does not explain whether it is for initial setup only or for recalibration, nor does it specify prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits such as persistence, side effects, or permission requirements. No annotations are present to compensate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the purpose and includes key constraints. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description provides the essential purpose and value constraints. However, it lacks context on when the setting takes effect or if a reboot is required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with type, min, max, and description. The description adds the default value (0) and repeats the range, providing marginal extra value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set) and the resource (align_board_pitch) as a board rotation offset in pitch. It distinguishes from sibling setters like set_align_board_roll and set_align_board_yaw by specifying pitch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool or when to avoid it. There are no suggestions about alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description fails to disclose behavioral traits such as side effects on logging or performance, and does not explain if the setting persists across reboots.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 12 words, front-loaded with the action and resource, with no unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle, the description is minimally adequate but lacks explicit explanation of the value meanings (OFF vs ON) and their impact on blackbox logging.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes the enum, but the description adds context about the default value and the UINT32 type (though the schema uses strings), providing marginal added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets blackbox_disable_gyro to exclude filtered gyro data, identifying the specific resource. However, it does not clarify what OFF or ON means in relation to exclusion, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling tools like set_blackbox_disable_acc, nor any context for using it in a blackbox configuration workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It states 'Exclude motor output data,' which reveals the effect on blackbox logs but does not disclose whether the change is immediate, persistent, or requires a reboot. It also does not mention any side effects or prerequisites, leaving significant behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, fitting the essential information into a single sentence. However, it lacks structured formatting (e.g., bullet points) and could separate the parameter details for clarity, but overall it is efficient and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with a single enum parameter, the description adequately explains the purpose (exclude motor data) and parameter format. The sibling tools provide context via naming convention. No output schema exists, so return value explanation is unnecessary. The description is sufficient for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The parameter schema is fully covered (100%) with enum of 'OFF' and 'ON' and a description. The description adds 'UINT32, default: OFF', which provides the default value and type hint beyond the schema. This is useful but not extensive; the schema already defines the valid values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set blackbox_disable_motors: Exclude motor output data.' This identifies the tool as a setter for the blackbox_disable_motors parameter and explains its effect. It is distinct from the getter sibling get_blackbox_disable_motors, but does not explicitly differentiate from other set_blackbox_disable_* tools, though the name implies the affected subsystem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, there is no mention of using get_blackbox_disable_motors to read the current value or comparing with other blackbox logging settings. The description lacks any context for usage decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool sets a configuration parameter and requires USE_SERVOS, but does not disclose side effects, whether the change is persistent, or what validation occurs. The behavioral context is minimal beyond the obvious 'set' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus technical tags), front-loads the purpose, and includes essential details (requirement, type, default). No superfluous information. Could be slightly more structured but effective for the complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the main aspects: what it sets, the prerequisite, and type/default. However, it lacks details on valid value range (beyond UINT8), whether the setting is applied immediately, or any referential context for 'AUX channels' and 'channel forwarding'. Adequate but not fully informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with basic type info. The description adds valuable context: the parameter represents the first AUX channel for servo forwarding, includes the default value (4), and specifies the requirement USE_SERVOS. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as setting the 'channel_forwarding_start' parameter, which defines the first AUX channel to forward to servo outputs. The verb 'Set' and the specific resource name make the purpose clear. However, it does not distinguish from the many other set_* tools beyond the parameter name, which is inherent given the sibling context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires: USE_SERVOS' and the default value, but it does not provide explicit guidance on when to use this tool versus alternatives like get_channel_forwarding_start or other servo-related settings. No when-not-to-use or comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must cover behavioral traits. It indicates a write operation ('Set') and provides the data type (UINT16) and default (150), but does not disclose side effects (e.g., whether changes take effect immediately, require reboot, or affect flight behavior). The schema's wide min/max range is not contextualized.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus contextual hints, which is efficient. It front-loads the main purpose. However, the 'AOS tune: 110 Hz' note may be jargon that could be clarified, but it does not significantly harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description provides the parameter's meaning, units, default, and a typical value. This is adequate but does not explain the broader filter context or what 'dterm_lpf1_dyn' relates to, which might be needed for a new user. No contradictions with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a bare description ('Value for dterm_lpf1_dyn_max_hz (UINT16)'). The tool description adds meaningful context: it is a maximum cutoff frequency at full throttle, gives a tuning example (110 Hz), and states the default (150). This helps the agent understand the parameter's role and typical values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a parameter (dterm_lpf1_dyn_max_hz) and describes it as 'Dynamic D-term LPF1 maximum cutoff (at full throttle).' This is a specific verb+resource. While it doesn't explicitly differentiate from similar sibling tools like set_dterm_lpf1_dyn_min_hz, the name and context make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, appropriate contexts, or when not to use it. The description only gives an example tuning value (110 Hz) but no decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It only restates the range and default from the schema, missing behavioral details like persistence, side effects, or need for reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with no wasted words. Two sentences front-load the purpose and add helpful details. However, some info duplicates the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set tool with one parameter, the description covers the basic purpose and parameter semantics. It lacks behavioral context and differentiation from siblings, but overall is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds 'throttle percentage' and default value, confirming the parameter's role beyond the schema's generic 'value'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the throttle percentage threshold for EZ landing activation. It is a specific verb+resource combination. However, it does not differentiate from siblings like set_ez_landing_limit or set_ez_landing_speed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, nor any context on prerequisites or recommended value ranges. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it's a write operation ('Set'), but no annotations are provided. It doesn't disclose any side effects, persistence behavior, or validation rules beyond the schema. Minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very short description, but it repeats the tool name in 'Set f_yaw:'. Could be trimmed to 'Feed forward for yaw. [UINT16, default: 120]' without losing clarity. Otherwise concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple parameter setter with one parameter. It tells the parameter type and default, but lacks context on what f_yaw affects in the flight controller (e.g., yaw rate response). Given the simplicity, it is minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds the default value of 120 and clarifies the type as UINT16, which is not fully captured in the schema (integer with no range or default). This provides useful additional meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets 'f_yaw' for yaw feedforward, distinguishing it from other set_* tools by specifying the exact parameter. However, it doesn't explain what feedforward for yaw means in the context of flight control, which might be unclear to non-experts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other set_* tools. It simply states it sets f_yaw, without any context on prerequisites, typical use cases, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description includes parameter type (UINT8) and default (OFF), which provides some transparency, but does not disclose side effects, whether a reboot is needed, or how it interacts with other GPS settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, includes purpose, type, and default. No wasted words, but could be structured more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 1 parameter, no output schema, and no annotations, the description is minimal. It does not explain valid values beyond type, or the meaning of 'ON' vs 'OFF'. Incomplete for a configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. Description adds the default value (OFF) not in schema, which helps. However, there is a type discrepancy: schema says 'string' but description says 'UINT8', which may confuse. Adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (set) and resource (gps_auto_baud), and explains it automatically detects GPS baud rate. However, it does not distinguish from sibling 'get_gps_auto_baud' or other GPS-related settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to enable auto baud detection versus manually setting baud rate. No mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only reveals that the tool sets the SBAS mode and mentions the data type and default, but does not disclose side effects, prerequisites (e.g., GPS connection), or behavior for invalid values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single succinct sentence that effectively conveys the purpose and includes key type and default information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter, but the description lacks explanation of valid values, region-specific behavior, or output. Without annotations or output schema, the description should provide more context for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds that the value is a UINT8 with a default of 'NONE', which is not explicit in the schema (schema says string, no default). This adds marginal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'gps_sbas_mode' which is the SBAS (satellite correction) system for the region. It distinguishes from the getter sibling `get_gps_sbas_mode` but does not explicitly differentiate from other GPS set tools like `set_gps_sbas_integrity`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as `set_gps_sbas_integrity` or other GPS configuration tools. The description lacks context about prerequisites or scenarios for setting SBAS mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states the default value (ROLL). It does not disclose behavioral traits like immediate effect, persistence, validation, or side effects. This is insufficient for a setter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short segments front-loading purpose and key info. Every word earns its place; no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description is minimally viable: it states purpose and default. However, it omits possible values and usage context, leaving gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds default value (ROLL) and type hint (UINT8), providing some extra context. However, it does not list possible axis values, which would be helpful given no enums in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets which axis is exposed in debug fields for gyro filter analysis, with the verb 'Set' matching the name. It implicitly distinguishes from the sibling get_gyro_filter_debug_axis. However, it does not explicitly differentiate from other set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as get_gyro_filter_debug_axis or other similar setters. No when-to-use, when-not-to-use, or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only says 'Set' and provides the parameter type and default. It does not disclose side effects such as whether a reboot is required, whether the change is immediate, or any safety implications. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the tool name, a brief explanation, and the type/default. Every word is informative and there is no redundancy or wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter, no output schema, and no annotations, the description provides the essential information (name, type, default). However, it lacks context about how this parameter interacts with other filter settings (e.g., min_hz, type) and what the practical range is. Some additional context would improve confidence in correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage but only restates the parameter name. The description adds value by specifying the type as UINT16 and the default value (500), which is not in the schema. However, it does not explain the valid range, units (Hz are implied by the name but not explicit), or what happens outside expected bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets 'gyro_lpf1_dyn_max_hz', which is the dynamic LPF1 maximum cutoff frequency at full throttle. This is a specific resource and action. However, it does not explicitly distinguish from siblings like 'set_gyro_lpf1_dyn_min_hz' or 'set_dterm_lpf1_dyn_max_hz', though the name itself is fairly distinctive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not explain the relationship between dynamic max and min, or when to adjust gyro vs dterm filters. The description is purely definitional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must disclose behavior. It explains that ACTUAL mode directly sets center sensitivity and max rate, but does not disclose side effects, other possible values, or preconditions. Lacks comprehensive behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise: one sentence plus a note in brackets, front-loaded with the core purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description is fairly complete but lacks an explicit enumeration of allowed values and does not clarify the type mismatch (string vs UINT8). Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (parameter 'value' has description). The description adds explanation of the ACTUAL value and default, but does not list other allowed values or resolve the type confusion (string vs UINT8). Meets baseline but does not excel.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets 'rates_type' for the 'Rate calculation system' and explains that ACTUAL is the most intuitive mode. This distinguishes it from get_rates_type, but could be more explicit about its effect on FC configuration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. It does not mention prerequisites, scenarios, or contrast with other set_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions 'Scales the RSSI input' but does not disclose side effects, whether the change is immediate or requires reboot, or any constraints beyond schema min/max.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences clearly stating purpose, type, and default. No superfluous words. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, description adequately states what the tool does. However, it misses details on persistence, immediate effect, and validation context. Given many similar siblings, more context on behavior would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'Value for rssi_scale (UINT8)'. Description adds context 'Scales the RSSI input' and default value, which is not in schema. This adds moderate value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Set' and resource 'rssi_scale', and explains that it scales RSSI input. It also specifies type and default. However, it does not explicitly differentiate from sibling setter tools like set_rssi_channel, but the specific resource name makes it clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No mention of prerequisites or context. Among many sibling setters, the agent must infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioural traits. It mentions disarming to prevent injury but does not state if setting is persistent, requires reboot, or impacts other settings. The default value is given but no further behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no waste. The purpose is front-loaded with a colon, and the default value is appended concisely. Ideal length for a straightforward setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the core safety function and default value, but lacks context on acceptable values, when to enable/disable, and if there are any side effects. For a safety-critical parameter, more completeness would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema coverage is 100% with one parameter described. The description adds the default value 'ON' and indicates UINT8 type, providing marginal extra context. However, there is a subtle inconsistency: schema expects a string, description suggests UINT8/numeric.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the runaway_takeoff_prevention parameter and explains its function: detecting uncommanded throttle-up on arm and disarming to prevent injury. This gives a specific purpose, distinguishing it from generic set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_runaway_takeoff_prevention) or under what conditions to set the value. The description lacks context for proper usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states the effect (enable half-duplex) but omits side effects, interactions with other settings, required permissions, or whether the change persists after reboot. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one sentence plus a bracketed note) with no wasted words. While efficient, it could benefit from a clearer separation between purpose and parameter detail. Still, it earns a 4 for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a set tool with no output schema, the description should indicate the return value or success/failure behavior. It does not mention what happens after setting (e.g., immediate effect, confirmation). Given the simplicity of the tool (single parameter), a 2 reflects the missing confirmation of expected outcome.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter 'value' is 100% (description provided in schema). The description adds type ('UINT8') and default ('OFF'), which helps but does not specify exact valid values (e.g., 0/1 or ON/OFF). Given high schema coverage, baseline is 3, and the added info justifies a 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('serialmsp_halfduplex'), and what it does ('Enable half-duplex operation on MSP serial ports'). It also specifies the value type (UINT8) and default (OFF), making the purpose unambiguous and differentiating from other set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like set_serialrx_halfduplex or the related get tool. It lacks context on prerequisites, such as whether the serial port must be in MSP mode or if other settings need adjustment, leaving the agent without selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a write operation ('Set') but fails to mention critical details like whether changes take effect immediately or after reboot, any safety implications, or dependencies. The description is minimal and lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately states the purpose, followed by type and default in brackets. No extraneous words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the description is concise, it omits important context: the actual range (UINT8 is 0-255, but the schema allows extremely large values). It also does not explain the effect of the slider on flight behavior. For a flight controller parameter, more context is needed for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description for the 'value' parameter, but the tool description adds the default value ('100') and the concept of a 'scaling slider', which enriches meaning beyond the schema. This added context is beneficial for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting the 'simplified_dterm_filter_multiplier' as a D-term filter cutoff scaling slider. The verb 'Set' and resource name are explicit, and the addition of 'scaling slider' provides context. However, it does not explicitly differentiate among many sibling 'set_simplified_*' tools, though the name itself is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no context about when this adjustment is appropriate. It simply states what it does without any usage scenario or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It mentions the type (UINT8) and default (100) but does not explain the effect of changing the gain, any side effects, or prerequisites. The behavioral impact is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence that conveys the purpose, scope, and additional info (type and default). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the number of sibling tools and no output schema, the description is too minimal. It does not cover what happens after setting, what range to expect beyond schema constraints, or how it interacts with other settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaningful context beyond the parameter's schema description: it explains the parameter is a 'P and I scaling slider (relative to master)' and specifies default 100, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a specific parameter 'simplified_pi_gain' and explains it is a 'P and I scaling slider (relative to master)', which conveys the resource and action. However, among many similar sibling tools (e.g., set_simplified_d_gain, set_simplified_i_gain), it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling setter tools for different gain parameters, the description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the data type (UINT16) and default value, but fails to disclose whether the setting persists, requires a reboot, or has immediate effects on flight behavior. The parameter schema permits values far outside UINT16 range, which could mislead the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence plus parenthetical notes. It avoids redundancy but could be better structured with separate sections for purpose, prerequisite, and defaults.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the core purpose, prerequisite, type, and default. However, it lacks context on persistence, side effects, or how this parameter interacts with other TPA settings, which would be useful for a safe agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the single parameter. The tool description adds the default value (1000) and clarifies the type and requirement, which is valuable beyond the schema. However, it does not specify the valid range or units for the coefficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the aerodynamic drag coefficient for the advanced speed TPA physics model. It distinguishes this parameter from other TPA settings through the name and mentions the 'ADVANCED' model, but does not explicitly differentiate from sibling tools like set_tpa_speed_adv_mass.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the prerequisite USE_WING but provides no guidance on when to use this tool vs alternatives like other TPA parameters. There are no 'when not to use' statements or comparisons with other set_tpa_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It only states 'Enable' implying mutation, but lacks details on persistence, side effects, or post-enable actions needed (e.g., reboot). Minimal transparency for a state-changing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no extraneous words. It directly conveys the action and includes helpful examples without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the domain (many feature names) and lack of output schema or annotation, the description is incomplete. It fails to mention how to discover valid feature names (e.g., via feature_list) or any other contextual information needed for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the 'name' parameter already has a description. The tool description adds examples (TELEMETRY, GPS, SOFTSERIAL), which aids understanding but does not explain format or valid values beyond that. Adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Enable a named feature on the flight controller' with specific examples (TELEMETRY, GPS, SOFTSERIAL). It is distinct from sibling tools like feature_disable and feature_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to enable vs disable a feature, no prerequisites, and no mention of checking current features or using feature_list. This leaves the agent without context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only restates the tool's purpose without disclosing behavioral traits (e.g., that it is a safe read operation, whether it requires a connection, or what the configuration encompasses). The description adds no value beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no unnecessary words. It is front-loaded and effectively communicates the tool's purpose in minimal space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 no annotations, the description is minimal but acceptable for a simple getter. However, it does not explain what 'AUX mode configuration' includes or the return format, which could hinder an AI agent's understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is trivially 100%. The description does not need to add parameter information. Baseline score of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Get auxiliary channel (AUX) mode configuration,' which clearly specifies the verb 'Get' and the resource 'auxiliary channel (AUX) mode configuration.' It is distinct from many sibling get_* tools as it focuses on AUX mode, but does not explicitly differentiate from similar getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other get_* tools or set_aux_config. It lacks context about prerequisites or typical scenarios for retrieving AUX mode configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits (e.g., side effects, authorization requirements, or performance impact). It only lists output fields, leaving the agent unaware of potential mutability or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that lists the output fields. It is front-loaded and contains no fluff, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description sufficiently lists the key return fields (cell count, capacity, voltage, current draw, state code). However, it omits whether these are instantaneous or averaged values, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%. The description adds no parameter information, but none is needed. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves detailed battery state and lists specific fields (cell count, capacity, voltage, current draw, state code), making the purpose unambiguous. However, it does not explicitly differentiate from the sibling 'get_battery' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_battery' or 'get_battery_continue'. No context about prerequisites or ideal scenarios is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral aspects such as read-only nature, side effects, or return format. While the tool is likely a safe read operation, the absence of explicit transparency about what it returns (e.g., current value) and lack of any behavioral hints beyond the parameter description leave the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus the range annotation. It front-loads the action ('Get feedforward_smooth_factor:') and immediately explains the parameter's meaning. Every word adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description provides the essential meaning of the parameter but stops short of explicitly stating that the tool returns the current value. The range information helps, but an agent would benefit from knowing the exact return structure (e.g., integer). The description is minimally adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the schema coverage is trivially 100%. With no parameters, the description cannot add parameter semantics, and the baseline score of 4 is appropriate. The description includes the range [UINT8, 0–95, default: 65] which provides context for the return value, effectively compensating for the lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the feedforward_smooth_factor parameter and explains its purpose ('Additional smoothing applied to the FF signal'). While it doesn't explicitly differentiate from other feedforward getters, the verb 'get' combined with parameter explanation makes the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. As a simple getter, usage is implied but not explicitly stated. No exclusions, prerequisites, or comparative advice for the many sibling getters is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the type and default but does not explicitly confirm that this is a safe read-only operation with no side effects. The agent cannot be sure if this triggers any detection process.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only one sentence plus a brief type/default note. Every word is informative, and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is adequate but not complete. It lacks information about what the tool returns (e.g., the current baud rate). While the type hint provides some context, an explicit return description would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and 100% schema coverage. The description adds value by noting the type (UINT8) and default value (OFF), which are not present in the input schema. This helps an agent understand the expected return type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the gps_auto_baud setting and explains it is for automatic GPS baud rate detection. The verb 'Get' indicates a read operation, distinguishing it from its sibling 'set_gps_auto_baud'. However, it could be more explicit about reading the current value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'set_gps_auto_baud'. No context is provided about prerequisites, typical use cases, or when it is appropriate to call this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only get operation, but since annotations are absent, it should have explicitly stated that it does not modify state. It mentions the data type (UINT8) and default (OFF), which helps, but the return representation (e.g., 0 or 1) is not clarified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences) and front-loads the purpose. The first sentence is somewhat redundant (repeating the name), but the second provides essential context. Minor redundancy prevents a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple flag getter with no output schema, the description explains the behavioral meaning and default value. It could be improved by explicitly stating the return values (e.g., 0 for OFF, 1 for ON) and mentioning related settings like horizon_delay_ms.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the input schema coverage is 100%. The description adds no parameter-level information because there are none. A baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get horizon_ignore_sticks' which clearly indicates retrieval. It then explains the effect of the setting when ON, adding context that distinguishes it from other parameters like horizon_delay_ms. However, it could more explicitly state that it returns the current value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as get_horizon_delay_ms or get_horizon_level_strength. The description focuses solely on the parameter's effect, not on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description does not disclose behavioral traits such as read-only nature, return format, or any side effects. It only provides the data type and default value, which is minimal for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that is front-loaded with the tool name. Every word contributes meaning, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description is adequate but lacks context about the meaning of 'max_aux_channels' in the broader system, such as its relationship to set_max_aux_channels or typical usage scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. The description adds value by specifying the data type (UINT8) and default value (14), which helps the agent understand the expected output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'Maximum number of AUX channels processed', which is a specific and distinct purpose. However, it does not differentiate from the sibling set_max_aux_channels or other getters beyond the name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as set_max_aux_channels or other configuration getters. Usage context is implied only by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states it's a read operation returning current values, but adds no further behavioral context such as side effects, permissions, rate limits, or whether values are instantaneous or averaged. This is minimal beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, front-loading the purpose and return value. Every word is necessary; no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is fairly complete. It explains what is returned (motor values in microseconds) and that it covers all active motors. However, it lacks details on output format or behavior when no motors are active, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the description adds value by specifying the unit (microseconds) and scope (all active outputs), which goes beyond the empty schema. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The name and description clearly state it retrieves current motor output values in microseconds and returns all active outputs. However, the sibling tool 'motor_get' likely retrieves motor values as well, and the description does not explicitly distinguish between them, leaving some ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like motor_get or motor_set. It does not specify prerequisites, limitations, or when not to use it, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a read operation ('Get') and provides return type but does not disclose any side effects, permissions, or potential risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with additional type info in brackets. Every word is meaningful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides the core purpose and return type. However, it lacks any explanation of what the value means in practice (e.g., effect of ON vs OFF), which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description adds value by specifying the return type (UINT8) and default value (ON), which are not present in the empty schema. This information helps the agent understand the expected response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves whether simplified slider controls gyro filter cutoffs, with type and default info. It distinguishes itself from siblings by its specific parameter name, but doesn't explicitly contrast with other similar getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. There are many similar get_ tools, but the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It describes the return format (UINT8, default: RPY) which adds value beyond the schema. However, it does not disclose any behavioral traits such as side effects, idempotency, or rate limits. For a simple read operation, the description is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that front-load the purpose and then explain the meaning of the return value. Every part is relevant and there is no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is fairly complete. It explains what the tool gets and the default value. However, it does not fully enumerate possible values (e.g., other axis combinations) or describe the output structure in detail. For a simple getter, it is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters in the input schema, and schema description coverage is 100% (no params to describe). The baseline for zero parameters is 4. The description adds meaning by explaining the tool's purpose and the return value format, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves which axes the simplified PID sliders control, using the verb 'get' and specifying the resource. It explains that 'RPY = all axes', but does not explicitly differentiate from sibling tools like get_pid_sliders or other get_simplified_* tools. The purpose is clear but lacks sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention when-not-to-use, prerequisites, or contrast with similar getter or setter tools. The presence of set_simplified_pids_mode implies this is for reading, but no explicit usage context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It indicates a read operation and lists a requirement ('USE_WING'), but it does not disclose preconditions, side effects, or output format beyond implying a simple return of the current value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with additional details in parentheses, conveying purpose, requirement, type, and default without unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately explains what the parameter is (setpoint width), its type, default, and a prerequisite. It does not elaborate on the return value but states it is a retrieval of a specific setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema coverage is 100%. The description adds value by specifying the data type (UINT16), default value (0), and a note that the default is 'per profile', which aids the agent in understanding the nature of the configuration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'spa_pitch_width' parameter defined as 'Setpoint width for pitch SPA attenuation ramp'. Although its purpose is clear, it does not differentiate from sibling tools like get_spa_pitch_center or get_spa_pitch_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the requirement 'USE_WING' and provides type/default info, but it offers no guidance on when to use this tool versus alternatives. No when-to-use or when-not-to-use context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It states 'Get' implying a read operation, but does not mention safety, side effects, or potential errors. The description could be more informative about the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it could be slightly expanded to include behavioral or usage details without losing brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter getter with no output schema, the description is adequate but not comprehensive. It does not describe the return format or possible values, which could help the agent interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema's parameter description 'Motor index (0-based)'. It repeats the concept of 'specific motor index' but does not provide additional syntax or format details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Get' and the resource 'current output value for a specific motor index'. It distinguishes from the sibling 'motor_set' (which sets values) and other 'get_*' tools (which retrieve different parameters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not specify context, prerequisites, or when not to use it. The short description implies usage for reading motor output values, but lacks comparative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states the parameter purpose and range but does not mention whether the change takes effect immediately, requires a reboot, is persistent, or any side effects. This is insufficient for a mutation command.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a bracketed range specification. It is concise and to the point, with no wasted words. However, it could be better structured with explicit sections for purpose, usage, and behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter and no output schema. The description explains the parameter's purpose and valid range, which is adequate for a basic setter. However, it lacks information on what the tool returns or any confirmation of success, leaving some gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description already covers the parameter's type, range, and constraints. The tool description adds context about 'board rotation offset in roll' and 'non-standard FC mounting orientations,' but this adds minimal value over the schema. With 100% schema coverage, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as setting the board rotation offset in roll for non-standard FC mounting orientations. It specifies the parameter type, range, and default. However, it does not differentiate from sibling tools like set_align_board_pitch or set_align_board_yaw, leaving purpose clear but not distinctly set apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'For non-standard FC mounting orientations,' which provides context on when to use this tool. However, it does not explicitly state when not to use it or suggest alternatives among the many sibling set_align_* tools. Usage guidance is implied but not complete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral transparency burden. It states the action (disable RPM telemetry) but does not explain what this means for logging, persistence, or side effects. The required build flag is mentioned but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (one sentence plus parenthetical requirement) and front-loads the key action. However, the mention of 'UINT32' contradicts the schema's string type, reducing clarity slightly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the schema's enum, the description covers the basic use case. However, it lacks broader context about blackbox logging or when this setting is relevant (e.g., for RPM filtering). Additional detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with enum and description, so baseline is 3. The description adds the default value 'OFF' and notes the type 'UINT32', though the schema uses a string enum. This adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'blackbox_disable_rpm', and explains its function 'Exclude RPM telemetry data'. However, it does not explicitly distinguish itself from sibling tools like set_blackbox_disable_gyro, relying on the name and brief explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes a prerequisite ('Requires: USE_DSHOT_TELEMETRY'), providing conditional context. No guidance on when to use this tool vs alternatives (e.g., other blackbox disable settings) is given, and no when-not-to-use scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the parameter range and default but fails to mention any behavioral traits such as whether the setting is applied immediately, requires a reboot, or has side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that conveys the purpose, unit, type, range, and default value. It is highly compact with no wasted words, fitting the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple setter with one parameter and no output schema, the description covers the essential parameter details. However, it omits context like whether the setting is persistent, takes effect immediately, or interacts with other settings (e.g., crash recovery enable). This is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter with range and type, but the description adds meaningful context: 'Maximum recovery correction angle (degrees)' clarifies the parameter's role and unit, and the default value '10 (per profile)' is extra information not in the schema. This justifies a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set crash_recovery_angle: Maximum recovery correction angle (degrees).' It uses a specific verb ('Set') and resource ('crash_recovery_angle'), and includes the unit and default value. However, it does not explicitly distinguish this from sibling tools like 'set_crash_recovery' or 'set_crash_recovery_rate', though the meaning is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives, when not to use it, or any prerequisites. The agent is left to infer usage from context alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the action and default, but does not explain the effect of changing d_max_yaw or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise (one line) but repeats the tool name unnecessarily; lacks structure or additional sentences that could clarify usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description should explain what d_max_yaw is and its role in PID tuning, which is absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds the default value (0) which is not in the schema, providing useful extra context for the parameter's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('d_max_yaw for yaw'), with the sibling context distinguishing it from getter and other axis setters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_d_yaw or other PID parameters; lacks context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description mentions it's a set operation but fails to disclose side effects, required permissions, or any behavioral impact beyond the trivial fact that it sets a value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise with two sentences and no unnecessary details. The prerequisite note is tucked into parentheses but front-loaded enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set operation with one parameter and no output schema, the description covers the purpose and default but omits possible enum values (beyond AUTO) and lacks details on behavior when set. The type inconsistency also reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a parameter description, but the description adds the default value 'AUTO' and clarifies the type (UINT8) and default. However, there is a type mismatch (schema: string, description: UINT8) which adds confusion rather than clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets dshot_bitbang for DSHOT bitbang implementation and explains AUTO selects automatically. However, it does not differentiate from other set_ tools beyond naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use vs alternatives, but provides a prerequisite condition (requires USE_DSHOT + USE_DSHOT_BITBANG) which helps an agent understand required firmware configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states that the tool sets a value but does not explain side effects (e.g., impact on flight behavior, need for reboot, or persistence). The note 'per profile' gives a hint of profile-specific storage, but this is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence. It front-loads the action and resource, then efficiently presents the key attributes (type, range, default). Every word serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description is mostly adequate. It explains the parameter and gives defaults. However, it lacks information about the effect of setting this value (e.g., immediate application or after reboot) and any confirmation of success. This is a minor gap given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single parameter 'value' is described). The description adds value by specifying the default (15) and the per-profile behavior, which goes beyond the schema's type and range. This helps the agent understand the typical value and storage scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'ez_landing_limit', and explains its function as 'Minimum throttle floor enforced by EZ landing (%)'. It correctly identifies the purpose and provides key details like type and range. However, it does not explicitly distinguish from sibling tools like set_ez_landing_speed or set_ez_landing_threshold, which are also EZ-related settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, context, or scenarios where adjusting this limit is appropriate. Users are left to infer usage from the parameter description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for disclosing behavior. It mentions the default value and the purpose but does not explain the effects of setting it to OFF, valid input values beyond the default, or any side-effects. This leaves significant gaps in transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (two sentences plus a bracketed note) and front-loads the purpose. It efficiently conveys the core function and a usage tip without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the main purpose and gives a usage condition. However, it fails to specify valid or expected values (e.g., 0/1 or ON/OFF), and the type mismatch undermines completeness. It meets the minimum threshold but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes one parameter with 100% coverage. The description adds a default value ('ON') and a type hint ('UINT8'), which clarifies the expected input. However, there is a contradiction: the schema says type 'string' while the description says 'UINT8', causing potential confusion about the actual value format (e.g., numeric '1' or string 'ON').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'gps_auto_config' for automatic UBlox module configuration, listing specific configurable aspects (baud rate, update rate, message types). It avoids tautology and uses a specific verb-resource pair, though it doesn't explicitly differentiate from sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage condition 'Leave ON unless you pre-configure the module with uCenter,' giving some guidance on when to disable. However, it lacks explicit alternatives or a clear when-not-to-use statement, and does not reference other tools in the sibling list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses a behavioral effect: OSD shows 'RESCUE N/A' if below this threshold. However, without annotations, it does not specify if the change is immediate, requires reboot, or has other side effects like affecting arming only. It adds some context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each adding value: purpose, behavioral effect, and range/default. No redundancy. Front-loaded with the action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with high schema coverage and no output schema, the description is mostly sufficient. It explains the meaning and a concrete outcome (OSD display). Could be enhanced by noting persistence or relation to GPS rescue configuration, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description restates the range ([UINT8, 5–50, default: 8]) already present in schema, adding the default value. It explains the parameter's impact on arming and OSD, but this overlaps with the purpose rather than adding new parameter-specific details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action ('Set') and the resource ('gps_rescue_min_sats'). It explains the meaning: minimum satellite count required to arm with GPS rescue. It distinguishes from sibling 'get' tools by being a setter, though doesn't explicitly differentiate among setter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. It mentions the OSD behavior but does not state prerequisites (e.g., GPS rescue must be configured) or contexts where this setting matters. The user must infer its purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral disclosure. It only mentions data type (UINT8) and default (OFF), but does not describe side effects, persistence, whether a reboot is required, or what happens if an invalid value is provided. For a simple setter, this is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It is not overly long, though it redundantly repeats the tool name. No unnecessary information, but could be slightly improved by removing redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple setter, and the description explains its purpose and default. However, it does not specify the expected value format (e.g., numeric string '0' or '1', or 'ON'/'OFF'), nor any constraints. With no output schema, more detail on what to expect after setting could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter described as 'Value for gps_use_3d_speed (UINT8)'). The tool description adds that the default is OFF, but does not clarify the expected format (e.g., numeric string like '1' or '0') or range. Baseline 3 is appropriate as the description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the specific resource ('gps_use_3d_speed'). It explains the purpose: use 3D speed (including vertical) for GPS speed display. This distinguishes it from unrelated set_* tools and the sibling get_gps_use_3d_speed.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks guidance on when to use this tool versus alternatives. It does not explain when 3D speed is preferable to 2D speed, nor does it mention that one might first check the current value via get_gps_use_3d_speed. No prerequisites or when-not-to-use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies enabling a setting that triggers recalibration on first arm, but it does not disclose behavioral details such as persistence across reboots, side effects, or if it overrides existing calibration. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and a type/default hint. Every part adds information without repetition. Perfectly efficient for a simple configuration parameter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description leaves gaps. It does not specify what the UINT8 values represent (e.g., 0=OFF, 1=ON) or the effect on flight behavior. Without these details, an agent may not know valid inputs or consequences.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a generic description. The description adds the default value ('OFF') and specifies the data type ('UINT8'), which adds minor value. However, it does not explain acceptable values (e.g., 0 or 1) or their meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Recalibrates gyro on first arm') and the resource ('gyro'). It differentiates from sibling 'set' tools by specifying when the recalibration occurs (after power-up on first arm). However, it doesn't explicitly distinguish from other gyro calibration tools like 'set_gyro_calib_duration'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a specific use case ('if the FC warms up and gyro drifts before the first arm'), which indicates when to use. However, it does not specify when not to use, nor does it mention alternative tools or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It states the data type (UINT8) and default (PT1) but fails to mention whether changes take effect immediately, require a reboot, persist across restarts, or interact with other filtering parameters. The impact of changing the filter type is unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys the key information efficiently. Every word adds value, following a clear pattern of name, colon, and explanation with type and default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description is minimal. It lacks explanation of when to use this specific filter type, the effect of the default, or typical values. The absence of output schema and lack of behavioral context leave the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the only parameter 'value' as a string. The description adds that it is a UINT8 with default PT1, providing some context. However, it does not enumerate valid filter types (e.g., PT1, BIQUAD) or explain the meaning of UINT8 in practice. Baseline is 3 due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the target 'gyro_lpf2_type', explaining it as the filter type for gyro LPF2 (anti-aliasing). This distinguishes it from other set tools like set_gyro_lpf1_type or set_dterm_lpf2_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as when to adjust LPF2 vs LPF1 or notch filters. There is no mention of prerequisites, order of operations, or common use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose behavioral traits such as persistence, whether a reboot is required, or side effects on flight behavior. It only states what the tool does and the default value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. Each sentence adds value—first explains purpose, second provides type and default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description covers the core purpose and default. However, it lacks clarification on value range (expected UINT16 but schema shows huge min/max), units (likely microseconds), and any behavioral context. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so baseline is 3. The description adds the default value (1050) and explicitly notes the data type (UINT16), which provides useful context beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the min_check value, which is an RC channel threshold for recognizing arm/disarm and stick commands. It includes the data type and default. However, among many set_* siblings like set_min_command, it does not differentiate its specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as set_min_command or set_mid_rc. The description does not mention prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden for behavioral disclosure. It only states that the tool sets a parameter, without mentioning side effects, persistence, valid range, or prerequisites. Minimal transparency beyond the immediate action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It front-loads the purpose and includes essential type and default info in a single, well-structured sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description provides the purpose, special value, and default. However, it omits the valid range (implied UINT8 but schema allows wider), persistence, and any side effects. Adequate but minimal for full contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the tool description adds useful semantic context: the meaning of 0 (use auto) and the default value. This goes beyond the schema's 'Value for rc_smoothing_setpoint_cutoff (UINT8)' to clarify behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the manual setpoint smoothing cutoff value, with the specific meaning of 0 for auto. It specifies data type and default. However, it does not explicitly differentiate from other rc_smoothing set tools like set_rc_smoothing_throttle_cutoff, which weakens clarity among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like set_rc_smoothing or set_rc_smoothing_throttle_cutoff. The description only explains the meaning of the value 0, but does not help an agent decide which tool to invoke.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of behavior disclosure. It mentions that 0 disables channel RSSI and notes the type INT8 with default 0, but does not explain persistence, required permissions, side effects, or valid range (schema bounds are inconsistent with INT8).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence plus a brief annotation to convey all necessary information. It is front-loaded and efficient, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is adequate. It covers the purpose and special value 0 but lacks information on valid range (INT8 vs schema bounds) and potential side effects. The absence of an output schema is acceptable for a setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema's 'Value for rssi_channel (INT8)'. It explains the special meaning of 0, specifies the INT8 type, and gives a default value, helping the agent understand the parameter's semantics fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'rssi_channel', explaining it is an AUX channel carrying RSSI signal. It distinguishes itself from other set_* tools by specifying the exact parameter, though it does not explicitly differentiate from sibling tools like set_rssi_invert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, context, or when not to use it, leaving the agent without decision-making help among many RSSI-related setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full weight. It mentions data type (UINT8) and default (30), but fails to disclose important behavioral traits such as whether the setting takes effect immediately, requires a reboot, or has side effects. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parenthetical note, front-loading the key information. No redundant words; every piece earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter without output schema or annotations, the description covers basic functionality. However, it lacks contextual completeness: no mention of persistence, reboot requirements, or link to the corresponding getter (get_rssi_src_frame_lpf_period). It is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% but minimal. The tool description adds meaningful context: the purpose of the LPF period and the default value. This goes beyond the schema description, scoring above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'rssi_src_frame_lpf_period', and explains the parameter's role as 'LPF period for frame-error-based RSSI smoothing'. This is specific and informative, though it does not explicitly differentiate from sibling setters like set_rssi_smoothing, so misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., set_rssi_smoothing or set_rssi_src_frame_errors). There is no description of typical use cases or conditions that would warrant adjusting this parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states it sets a value and gives a default. There is no mention of side effects, prerequisites, or that it writes to flight controller settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line containing purpose, data type, and default. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, this description is minimally adequate. However, it lacks behavioral details and does not explain how this setting affects flight behavior, which may be needed in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds default value and type info beyond the schema (which only says 'Value for simplified_d_gain (UINT8)'). Since schema coverage is 100%, baseline is 3, but the additional default context is valuable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the simplified_d_gain, identifies it as a D scaling slider, and provides type and default. However, it does not elaborate on what D scaling means or differentiate from similar PID-related setter tools like set_simplified_d_max_gain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., set_simplified_d_max_gain or traditional D gain settings). Among dozens of similar set_* tools, the description offers no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It mentions the parameter type (UINT8) and default value (100), but does not disclose any side effects, whether the change is persistent or requires a reboot, or what happens if an out-of-range value is supplied. For a setting that adjusts flight dynamics, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by a bracketed type/default note. It is front-loaded with the action ('Set simplified_d_max_gain') and includes essential context. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one parameter, no output schema). The description covers parameter type and default. However, it lacks any mention of persistence, immediate effects, or validation constraints. For a flight controller parameter setter, an agent might need to know if the value is saved to EEPROM automatically or requires a save command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter as 'Value for simplified_d_max_gain (UINT8)', covering 100% of parameters. The description adds the default value (100) and implies the uint8 range, which provides additional semantic meaning. This helps the agent understand typical values without consulting external docs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'simplified_d_max_gain' and explains it is a 'D_max scaling slider (dynamic damping ceiling)'. The verb 'Set' combined with the specific parameter name makes the purpose unambiguous. However, among sibling tools like 'set_d_max_gain' and 'set_simplified_d_gain', it could more explicitly differentiate when to use this simplified version versus the non-simplified one, so not a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. For example, it does not explain when to adjust the simplified D_max gain compared to the regular D_max gain or other PID-related settings. An agent would have no context for choosing this tool from the many 'set_' siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden. It states it's a set operation with a requirement, but does not disclose side effects, persistence, or safety implications. Additionally, there is a type inconsistency: the description says '[UINT8]' while the input schema specifies 'type: string' for the value parameter, which can cause misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short—one line plus a parenthetical note—with no wasted words. It conveys key information efficiently, though it could be better structured (e.g., separating requirements and defaults).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the basics but lacks context about what SPA mode is, what valid UINT8 values (e.g., ON/OFF or numbers) are, and how this setting affects yaw behavior. Sibling tools in the same domain don't clarify usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter 'value' has a description). The tool description adds the default value and type hint, but adds little beyond the schema's description. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and resource 'spa_yaw_mode', and explains it's for yaw SPA mode. The requirements and default are noted. However, it doesn't differentiate from sibling tools like set_spa_pitch_mode or set_spa_roll_mode, though the tool name already specifies the axis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'USE_WING' feature and the default value, giving some usage context. But it lacks guidance on when to choose this tool over alternatives (e.g., get_spa_yaw_mode, set_spa_yaw_center) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the prerequisite (USE_WING) and the default value (0). However, it does not describe behavioral traits such as whether the change is immediate, requires reboot, or persists across power cycles. No side effects or mutability details are given beyond 'Set'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief—one sentence with a parenthetical note. It is front-loaded with the main purpose. However, the formatting mixes information (requirement, type, default) without clear separation, making it slightly cluttered. It could be more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description covers the purpose, prerequisite, type, and default. However, it does not explain the meaning of 'S-term for yaw' or how it fits into the broader PID system, which might be needed for an agent to understand when to use it among many PID-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'value', which has a description 'Value for s_yaw (UINT8)'. The description adds the type 'UINT8' and default '0', which supplements the schema's integer type and bounds. This adds marginal value but does not provide a full semantic explanation of the parameter's role in PID tuning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set s_yaw: S-term for yaw' which identifies the specific verb and resource. It indicates that this tool modifies the S-term for yaw, a PID parameter in an FC. The title is null, but the description suffices. It distinguishes from sibling tools like set_s_pitch by specifying the axis (yaw).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires: USE_WING' which gives a condition for usage. However, it does not explicitly state when not to use this tool or provide alternatives among the many set_* siblings. The context implies use when you need to set the S-term yaw value, but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that attenuation is proportional from the breakpoint to full throttle, which is helpful, but it omits important behavioral details such as whether changes are saved persistently, if validation occurs, or what side effects might result from extreme values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences and a bracketed note. It is front-loaded with the key operation and value constraints. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter, simple mutator, the description adequately covers what the parameter means and its default. However, it fails to place the tool in the broader context of TPA configuration (e.g., how this interacts with tpa_rate, tpa_curve, etc.), which would be valuable given the large number of sibling tools. The description is functional but narrow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds significant meaning beyond the schema's 'Value for tpa_breakpoint (UINT16)' by specifying the 1000–2000 range, the role of the breakpoint in TPA, and the default value. This enriches the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting the TPA breakpoint throttle level on a 1000–2000 scale, with explanation of proportional attenuation. It is specific and distinguishes the tool from generic 'set' operations, though it does not explicitly differentiate from other TPA-related tools like set_tpa_rate or set_tpa_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other TPA configuration tools or what scenarios call for adjusting the breakpoint. The description lacks any context for selecting this tool among its many siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states the value and default but omits behavioral details: whether change applies immediately, requires reboot, or affects other settings. There is an implicit contradiction: schema allows ±9e15 integer but description says UINT8 (0-255). This is misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—one sentence plus an example and type/default. It is front-loaded with the action and meaning. However, the structure could be improved by separating the example and note for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and a single parameter with minimal schema description, the context is insufficient. It does not explain tpa's role in tuning, the scale of percentage, or consequences of extreme values. Among dozens of set_* siblings, this description leaves a newcomer guessing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds rich meaning beyond the schema's generic 'Value for tpa_rate (UINT8)'. It explains the value represents maximum attenuation percentage, gives a concrete example (65 = PIDs at 35% above breakpoint), and states default (65) and type (UINT8). This fully clarifies parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets tpa_rate, defines it as 'Maximum attenuation percentage at full throttle', and provides an example linking the value to PID percentage above breakpoint. This distinguishes it from sibling tools like set_tpa_breakpoint or set_tpa_curve_type. However, it assumes knowledge of 'tpa' acronym without explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., set_tpa_breakpoint, set_tpa_low_rate). The description does not mention prerequisites, context of use, or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It does not disclose side effects, persistence, re-arming needs, or impact on flight behavior. It only provides mode definitions and a requirement, leaving many behavioral aspects unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively short and to the point, with key information front-loaded. Every sentence adds value. However, the inclusion of technical details like [UINT8, default: BASIC] could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description explains the two mode options and a prerequisite. It does not describe the overall effect on flight or how to choose between modes, and the parameter format mismatch detracts from completeness. Adequate but with gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and describes the parameter as a UINT8 string. The description adds meaning by listing the two mode names (BASIC, ADVANCED) and explaining their underlying models. However, there is an internal inconsistency: the description says '[UINT8, default: BASIC]' but the schema type is string, and the values are given as text strings. This may confuse agents about the expected input format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool sets tpa_speed_type, explains two modes (BASIC and ADVANCED) and their meanings. It distinguishes from sibling TPA set tools by focusing specifically on speed type. However, it could be more explicit about the overall purpose of TPA speed types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a requirement (USE_WING) and implies when to use each mode (GPS vs physics model), but does not provide explicit guidance on when to choose one over the other or when to avoid using this tool. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'enable pull-up' without disclosing side effects, persistence, or impact on other settings. Missing behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with type/default in brackets. Efficient, no wasted words, but slightly terse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple setter with one parameter, but lacks behavioral context (e.g., success indication, reboot requirement). Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter fully described). Description adds default value and type hint, but does not provide new semantic insight beyond what the schema already states.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly describes the action (set), the resource (usb_msc_pin_pullup), and the effect (enable pull-up on USB MSC detect pin). Differentiated from sibling set_* tools by specific pin function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. No prerequisites, consequences, or contextual hints provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It fails to state that this is a read-only operation with no side effects, and does not mention any prerequisites or return value details beyond the inline type hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with a parenthetical note. It front-loads the purpose immediately and wastes no words. Every element serves a clear informational role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with no schema and no output schema, the description covers the core purpose, explains the parameter's meaning, and offers tuning guidance. It could mention that it returns the current value without modifications but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the input schema is fully covered. The description adds value by specifying the parameter type in the [UINT8, 2–50, default: 5] notation, which helps the agent understand the expected value but is actually about the output. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the anti_gravity_cutoff_hz parameter and explains it is an LPF cutoff for throttle derivative used by anti-gravity. The verb 'Get' is unambiguous, but it does not explicitly contrast with the sibling set_anti_gravity_cutoff_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides tuning advice ('Adjust for very large or small builds') but does not specify when to use this tool versus alternatives (e.g., the set variant). No context is given about prerequisites or when reading the value is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read operation and includes the data type and range. However, it does not disclose any side effects, prerequisites, or safety implications beyond the implied read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence plus a tuning hint and data specification. It is front-loaded with the tool's purpose. Minor structural issues (repetition of the name) do not significantly detract from readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
In the absence of an output schema and annotations, the description explains what the tool returns (the parameter value with type and range). However, it lacks details about the return format, whether a connection is required, or any further context about the parameter's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, but the description adds value by specifying the data type (UINT8), valid range (0-250), and default value (100). This provides useful semantic information beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves the anti_gravity_p_gain parameter, explains its function (boosts P-term on rapid throttle changes), and provides a tuning hint. However, it does not explicitly differentiate from the sibling 'get_anti_gravity_gain' tool, which likely retrieves the I-term gain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a tuning hint ('Reduce if punches cause P-induced oscillations') but does not provide any guidance on when to use this tool versus alternatives like get_anti_gravity_gain or set_anti_gravity_p_gain. No context about prerequisites or conditions is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates the tool is a read operation ('Get'), which implies no destructive behavior, but it does not explicitly state that it is safe, side-effect-free, or what the return value looks like. The behavioral disclosure is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence plus a parenthetical note. It front-loads the purpose and includes essential details (type, default, requirement). Every element serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless getter with no output schema, the description provides the purpose, type, default, and a prerequisite. However, it does not list all possible values (e.g., SPI, I2C) beyond the default, and it lacks details about the return format. It is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. Per guidelines, with full schema coverage the baseline is 3. The description adds marginal value by noting the default ('default: SPI') and data type ('UINT8'), but since there are no parameters, this is already implied by the schema context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the barometer bus type ('Get baro_bustype: Barometer bus type.'). The verb 'Get' indicates a read operation, and the resource is explicitly named. Among many similar 'get_*' tools, this one is distinct in targeting the bus type, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires: USE_BARO'), which provides some context, but it does not specify when to use this tool versus alternatives (e.g., 'set_baro_bustype' or other barometer-related getters). There is no guidance on when not to use it or what distinguishes it from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states this is a read operation (get) but does not describe side effects, authorization needs, or behavior when the prerequisite is unmet. Minimal transparency beyond the basic read nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one line containing the key information: purpose, type, default, and requirement. No superfluous words, front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter getter with no output schema, the description covers the key aspects: what the value represents, its default, and a prerequisite. It could optionally explain valid address range or interaction with the barometer driver, but it is sufficiently complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds value by specifying the type (UINT8) and default value (0) for the underlying setting, which is not captured in the schema. Baseline 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets the I2C address override for the barometer, with default 0 meaning auto-detect. The verb 'get' aligns with the name. Briefly distinguishes from the corresponding setter tool implicitly but not explicitly among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite (Requires: USE_BARO) but provides no guidance on when to use this tool versus alternatives like other get_* tools. No context on typical scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. The description implies a read-only operation ('Get') and notes the data type (UINT32) and default value (OFF). However, it does not explicitly state that the tool is non-destructive or safe to call repeatedly, nor does it mention any side effects. The behavioral disclosure is minimal but acceptable for a straightforward getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line, which is highly concise. It front-loads the purpose by restating the name and then adding meaning. However, the repetition of the tool name is redundant and could be removed for even greater efficiency. Overall, it is appropriately sized for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description should explain what the returned value represents. It mentions type UINT32 and default OFF, but does not clarify the range of possible values (e.g., 0=OFF, 1=ON) or whether the return is a single numeric value. This gap makes it slightly incomplete for an agent needing to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty, so there are no parameters to describe. According to the guidelines, with 0 parameters the baseline score is 4. The description adds no parameter information because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the blackbox setting for excluding accelerometer data. The verb 'Get' and resource are explicit, and the purpose is unambiguous. Although it repeats the tool name, the added explanation 'Exclude accelerometer data' clarifies the setting's meaning. Among many similar get_blackbox_disable_* siblings, the name alone provides differentiation, so the description is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as when to query this specific setting versus others or when to use the corresponding setter. For a simple getter, basic usage is implied, but there is no explicit when-to-use or when-not-to-use advice, nor any mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the dependency on USE_SERVOS and the default value, but lacks full behavioral context (e.g., what the returned value represents, or any side effects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but the repetition of the tool name in the sentence is slightly redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple getter with no parameters and no output schema, but could be more complete by specifying the format of the returned value or what channels are available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds meaning by explaining the tool returns the channel_forwarding_start value, though it could elaborate on the range or interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the first AUX channel for forwarding to servo outputs, differentiating it from other getters by naming the specific parameter. However, it does not explicitly distinguish it from sibling getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_channel_forwarding_start). The description implies reading the current setting but provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It implicitly indicates a read operation through the 'Get' verb and mentions the default value, but does not explicitly state non-destructiveness or other behavioral traits like side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence) but includes unnecessary repetition of the tool name. It could be more concise by removing 'Get dterm_lpf2_type:' and directly stating the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and no output schema. The description provides the data type and default, but it does not explicitly state that it returns the current type setting. Given low complexity, the description is minimally adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100% by default. The description does not need to add parameter meaning, and it correctly notes the data type and default value, which provides context for interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the type for D-term LPF2, distinguishing it from siblings like get_dterm_lpf1_type and get_dterm_lpf2_static_hz. It also specifies the data type (UINT8) and default value (PT1). However, it could be more explicit about what the return value represents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There are many similar getter tools for different filter parameters, and the description lacks context on use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It explains what each mode does, which adds context. However, it does not explicitly state that the tool is read-only (though the name 'get' implies it). The behavioral descriptions are useful but incomplete for a 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loads the purpose. It conveys all key information in a single sentence with mode explanations. Could be slightly more structured, but efficient overall.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a getter with no output schema and no annotations, the description should explicitly state that the return value will be one of the enumerated modes. It mentions default and type but does not clarify the return format. Adequate but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so baseline is 4. The description adds value by specifying the default value and type (UINT8), which goes beyond the schema. No additional parameter info needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the failsafe switch mode and lists the possible values. However, it does not explicitly differentiate from sibling getter tools like get_failsafe_procedure, which are also 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.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It is implied for checking the current failsafe switch mode, but no when-not-to-use or alternative tool mentions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It indicates a read operation ('get') and specifies type/default, but does not mention side effects, permissions, or return behavior beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise (one line) and includes essential details in a readable format. It could be structured slightly better by separating type/default info, but it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description provides adequate context (purpose, type, default). However, it lacks information about the possible enumerated values (if any) and does not describe the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds value by explaining the meaning of the parameter (gyro LPF2 filter type) and its default, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the gyro LPF2 filter type, specifies the data type (UINT8) and default value (PT1). However, it does not explicitly differentiate from sibling tool 'get_gyro_lpf1_type', though the resource is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_gyro_lpf1_type' or 'get_gyro_lpf2_static_hz'. The agent must infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It states that the tool includes PID data in telemetry output and notes protocol support dependency. However, it does not disclose whether this is a read-only operation, potential side effects, or system impacts. Basic behavioral disclosure but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence with a technical appendix. It efficiently conveys the core purpose and key details without redundancy. Could be slightly improved by front-loading the action, but it's clear and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description explains the tool's function and a dependency (protocol support). However, it does not describe the return format or how to interpret the result. For a simple getter, this is minimally adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters in the schema. The description adds value by specifying the expected value type (UINT8) and default (OFF), which helps the agent understand the nature of the retrieved setting without needing to infer from the name alone. This exceeds the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the pid_in_tlm setting, explaining it includes PID data in telemetry output. The verb 'get' combined with the resource 'pid_in_tlm' and the explanatory text provide a specific purpose. It distinguishes from sibling getters by focusing on PID telemetry inclusion, though it could be more unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_pid_in_tlm. The only context is 'where supported by the telemetry protocol,' which is a condition rather than a usage recommendation. Lacks explicit when-to-use or when-not-to-use advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It identifies the tool as a getter by the verb 'Get', but does not explicitly state it is read-only, safe, or non-destructive. It also lacks details on response format, error conditions, or required state (e.g., must the flight controller be connected?).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a compact bracket annotation showing the type and default. Every word serves a purpose, and it front-loads the key information: the role of the parameter and typical usage values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no annotations, the description covers the essential meaning and typical values of the parameter. It does not specify the exact return format (likely a single UINT16), but this is implied by the bracket note. The description is adequate for an agent to understand what it retrieves.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description compensates by explaining the semantics of the returned value: it clamps total yaw PID output, recommends setting to 1000 during initial tuning, and notes the default is 400. This provides meaningful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the pidsum_limit_yaw value and explains its purpose: clamping total yaw PID output. It distinguishes from the sibling 'get_pidsum_limit' by specifying 'yaw', but does not explicitly contrast with other getters or the setter 'set_pidsum_limit_yaw'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes tuning advice ('Set to 1000 during initial tuning; default 400'), which is more relevant to setting the value than reading it. It provides minimal guidance on when to use this getter versus alternatives, such as checking the current value or comparing with other PID limits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool returns a UINT8 value with a default of 7, but does not explicitly state that it is a read-only getter with no side effects. For a simple getter, this is adequate but lacks explicit side-effect information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence plus a parenthetical note. It is front-loaded with the tool's name and core purpose. However, it could be slightly more structured by separating the type/default into a clearer format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the name, type, and default. However, it does not explain the range of possible values or the meaning of the value in terms of RC stick input (e.g., units, typical range). This leaves the agent with incomplete information to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and schema description coverage is 100%. The description adds value beyond the schema by specifying the return type (UINT8) and default value (7), which is useful context for the agent. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get pitch_rc_rate' and specifies 'Pitch rate at stick center', distinguishing it from other pitch-related tools like get_pitch_rate_limit or get_pitch_srate. However, it does not elaborate on the functional role of this parameter within the flight controller, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools (e.g., get_roll_rc_rate, get_yaw_rc_rate), it would be helpful to indicate that this is a read-only parameter for reading a specific RC rate setting, and that it pairs with set_pitch_rc_rate for modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description must convey behavioral traits. It states 'Get' which implies a read-only operation, and includes the data type 'UINT8' and default 'OFF'. However, it does not explicitly confirm that no side effects occur, nor does it specify the return format or range. The description provides baseline transparency but leaves gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single sentence and a type annotation. It front-loads the tool name and purpose. However, it repeats the tool name unnecessarily (''Get quickrates_rc_expo:') which could be omitted for brevity. Overall, it is well-structured for its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should explain what the returned value represents. It mentions 'applies expo globally' and the default, but does not specify the valid range of the UINT8 (e.g., 0-100, 0-255) or how the value affects behavior. This leaves the agent with incomplete understanding of the return value's meaning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (since no parameters). The description adds meaningful information about the returned value (UINT8, default OFF), which goes beyond the empty schema. This helps the agent interpret the return, justifying a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get' as the verb and identifies the resource 'quickrates_rc_expo'. It adds context about the parameter's role in 'QUICK rates mode' and the default value. However, 'expo' is not explained, and the description does not differentiate this getter from the many other getters in the tool list. It avoids tautology but lacks full clarity for an unfamiliar agent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The presence of 'set_quickrates_rc_expo' as a sibling suggests a get/set pair, but no mention is made of when to read this parameter versus other rate-related parameters. The usage is only implied by the tool being a getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description merely states 'Get' implies a read operation, but it does not explicitly disclose whether the tool is read-only, safe, or has side effects. The default and type are given but not behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence and additional bracket information. It front-loads the key behavior and uses minimal text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is adequate: it specifies the setting name, its purpose, type, and default. However, it lacks details on return format or how the setting interacts with other systems.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. Therefore, the baseline score is 3. The description does not add parameter-specific meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the setting for enabling 6-position rate profile selection via AUX channel, using the verb 'Get' and specifying the resource. It distinguishes from the sibling 'set_rate_6pos_switch' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives like 'set_rate_6pos_switch'. It only describes the setting's purpose, not the tool's usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides moderate transparency by mentioning the data type (UINT8) and default value (ROLL), plus its appearance in blackbox during RC_SMOOTHING debug mode. However, it does not clarify that the operation is read-only or disclose potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, front-loading the core purpose and including type info in brackets. It avoids extraneous text but could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains where the parameter is used (blackbox debug) but omits possible axis values (e.g., ROLL, PITCH, YAW) or whether the return is numeric. For a simple getter, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so baseline is 4. The description adds value by noting the type and default, which exceeds the empty schema's information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the axis exposed in RC smoothing debug fields, with context about blackbox visibility. While it distinguishes the resource from others, it does not explicitly differentiate from similar debug axis tools like get_gyro_filter_debug_axis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With many sibling get_* tools, the description lacks explicit context for selection, such as prerequisites or when to prefer this over set_rc_smoothing_debug_axis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It explains the tool returns a value with unit and type, and mentions legacy interpretation. However, it does not explicitly state that this is a read-only operation or describe side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently communicates key information (unit, legacy mode, type, default). It is appropriately concise, though could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially covers return value semantics (type, unit) but does not specify the exact return structure (e.g., whether it's a raw number or wrapped in JSON). Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, but the description adds meaning by explaining the returned value's unit, data type (UINT8), and default (7). This goes beyond the schema which has no parameter properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the roll_rc_rate parameter, specifying the unit (deg/s×10) and legacy RC multiplier interpretation. It distinguishes from siblings by naming, but lacks explicit differentiation from similar get_*_rc_rate tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_roll_rc_rate or other getters. The context of flight controller parameter retrieval is implicit but not explicitly described.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the setting's type (INT8) and default (OFF), adding context beyond the empty schema. However, it does not explicitly state that the tool is read-only or disclose any side effects or behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional details in parentheses, no wasted words. It is front-loaded with the tool name and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks information about what the tool returns. As a getter with no output schema, it should explain the return value (e.g., current value of rpm_limit). It only describes the parameter itself, not the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters, baseline score is 4. The description does not need to add parameter semantics, and it appropriately mentions the type and default for the setting itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the rpm_limit setting that enables per-motor RPM limit. It is specific about what the tool does, though it could be more explicit that it reads the current value. Among many sibling get_ tools, it is distinguishable by its focus on rpm_limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (USE_RPM_LIMIT) but provides no guidance on when to use this tool vs alternatives like set_rpm_limit or get_rpm_limit_value. No when-to-use or when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It conveys the tool is a getter with a bounded value, but does not explicitly state it is read-only or describe return format. Minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with one sentence and bracketed range. It is front-loaded and contains no waste, though could be slightly more descriptive.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter getter without output schema, the description covers purpose, type, range, and default. However, it lacks an explicit statement about returning a value, leaving completeness suboptimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description does not need to add parameter info; baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'rssi_offset', indicating it retrieves the RSSI offset. The range and default provide additional context. However, it does not explicitly differentiate it from sibling setter tool set_rssi_offset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like set_rssi_offset or other getters. The description lacks context on the tool's role in reading vs modifying the offset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It indicates a read operation and states the type (UINT16) and default value (2115), but does not disclose side effects, failure conditions, or permissions needed. The minimal information leaves the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence efficiently conveys the tool's purpose, data type, and default value. No extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides the core information: what is retrieved and its type/default. It lacks context about 'channel pulse width' or the relationship to the setter tool, but remains adequate given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (no params to document). Per guidelines, this yields a baseline score of 4. The description correctly adds no param details, as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'longest channel pulse width considered valid' with the specific name 'rx_max_usec'. While it doesn't explicitly differentiate from siblings like 'get_rx_min_usec', the naming and context make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It lacks context on scenarios where retrieving this parameter is appropriate or when other tools might be needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. The description implies read-only via 'Get', but does not explicitly state no side effects, safety, or prerequisites. For a simple read operation, this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One succinct sentence with critical info. However, the tool name is repeated unnecessarily. Could integrate type info more naturally, but overall efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context about the parameter's role, range (0-255 implied by UINT8), and relation to other simplified parameters. Given no output schema, more detail would be helpful for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline is 4. The description adds type (UINT8) and default (100) which adds meaning beyond the empty schema. This extra info is helpful for an agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it retrieves the feedforward scaling slider value, with type and default. The tool name is clear, and the sibling set tool exists, so purpose is clear. However, it could be more explicit about 'getting the current value' to fully clarify.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., set_simplified_feedforward_gain) or context on required system state. The description provides no usage recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals the data type (UINT8) and default value (100), and notes it is 'relative to master', which is useful context for interpreting the value. However, it does not disclose if the read has side effects or requires specific state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with key details (type, default, relative nature) in a compact form. It is appropriately front-loaded. Slightly reduced score because it could also mention the unit or range.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value (UINT8 scaling slider). However, it does not explain what 'simplified' means in the PID context or how this value relates to other gains. For a complete understanding, the agent may need additional domain knowledge.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%, so no further semantic description is needed. The description does not add parameter meaning but this is acceptable given the absence of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves a 'P and I scaling slider (relative to master)'. The verb 'Get' and resource 'simplified_pi_gain' are clear, and it distinguishes from sibling tools like get_simplified_d_gain or get_simplified_i_gain by specifying both gains (P and I).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_simplified_pitch_pi_gain or set_simplified_pi_gain. The description does not mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must provide behavioral context. It mentions data type, default, and a requirement, but does not explicitly state that this is a read-only operation or describe any side effects. The 'Get' verb implies read-only, but this is not confirmed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded with the key purpose, but wastes one word repeating the tool name. Overall, it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential facts (purpose, type, default, requirement) for a parameterless getter. However, it does not explain the broader context of SPA or how this width is used, which may be needed for full understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter information. The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the setpoint width for yaw SPA attenuation ramp, distinguishing it from related tools like get_spa_yaw_center or get_spa_yaw_mode. However, it starts with a tautological repetition of the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite (USE_WING) but does not compare with alternatives or specify when to use this tool over other get_ tools. The guidance is limited to a required define.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description hints at a read-only operation ('Get') and specifies the type UINT8 and default value, but doesn't elaborate on side effects, latency, or other behaviors. Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one line) and front-loaded with the action and resource. Though it lacks separate lines for requirement and type, it is efficient with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter getter with no input parameters and no output schema, the description covers the essential: purpose, requirement, and value type. However, it does not mention the output format (e.g., a single numeric value), which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% vacuously. The description adds value by stating the type (UINT8) and default (0), which the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the S-term for pitch, distinguishing it from sibling tools like get_s_roll and get_s_yaw. The verb 'Get' and resource 's_pitch' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description only mentions the requirement 'USE_WING' but provides no guidance on when to use this tool versus alternatives like get_pitch_rate or get_pitch_rc_rate. No explicit context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It states that the tool excludes RC channel data from logs, but does not mention persistence, reboot requirements, or side effects like reduced debugging capability. The default value is noted, but the behavioral impact beyond the basic effect is absent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence and a brief note. It contains no fluff, and every phrase ('Set', 'Exclude RC channel data from logs') adds value. It is well front-loaded and appropriate for a simple setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, straightforward setting), the description is adequate but minimal. It does not explain that this is part of a family of blackbox disable settings, nor does it clarify the effect on logging when set to OFF vs ON. With no output schema, the description could be more complete by stating that the change is persistent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage for the single parameter is 100%, so the schema already documents the parameter type, enum values, and a basic description. The description adds context ('Exclude RC channel data from logs') that clarifies the intent of the values, but does not provide new semantic detail beyond the schema. Score is baseline 3 as per guidelines.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set blackbox_disable_rc: Exclude RC channel data from logs.' It uses a specific verb ('Set') and resource ('blackbox_disable_rc'), and the purpose is well-differentiated from siblings like 'set_blackbox_disable_acc' and 'set_blackbox_disable_gyro'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, consequences of disabling RC logging, or when it is appropriate to use. With many similar set_blackbox_disable_* siblings, explicit usage context would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions overclocking and a default of OFF, but lacks details on potential side effects, hardware risks, or required permissions. For a potentially hardware-altering tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It front-loads the core action and includes necessary context in a single sentence and parenthetical.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the essential use case. However, it lacks guidance on valid values and safety precautions for overclocking, which could be important.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, and the description adds the type ('UINT8') and default ('OFF'). However, there is a type mismatch: schema says string but description implies numeric type. This adds some confusion, but overall provides useful extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool overclocks the STM32 F7 processor. The verb 'overclock' and the specific processor name make the purpose evident, distinguishing it from other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a condition for use ('Use only if CPU load is too high and the board supports it'), but it does not explicitly state when not to use or suggest alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the value range and default, but fails to mention behavioral traits like persistence, reboot requirements, or side effects on crash detection behavior. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that front-loads the action and key details. No extraneous words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description provides the essential purpose, type, range, and default. However, it lacks behavioral context such as whether the setting persists, requires a restart, or interacts with other parameters. Given the schema covers the parameter, completeness is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing a baseline of 3. The description adds the default value and 'per profile' context, which is not in the schema. However, the schema already describes the parameter adequately, so the extra value is marginal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'crash_delay', defines it as a delay after arm before crash detection is armed, and specifies the type, range, and default. It effectively distinguishes from the sibling get_crash_delay tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives, nor does it mention prerequisites or contexts such as arming states or profile selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only indicates that this is a set operation and gives the parameter constraints. It does not disclose side effects, persistence, or validation beyond the schema, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, one line, with the key information front-loaded. Every part is necessary, no wasted words. Well-structured for a simple parameter setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward parameter setter, the description covers the parameter constraints and default. The 'per profile' note adds context. It is complete enough, though could mention if the value is applied immediately or after a reboot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with a description, and the tool description adds the default value '350 (per profile)' not present in the schema. This augments the meaning, though the range is repeated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's purpose: to set the crash_setpoint_threshold for crash detection. It includes the data type, range, and default, which clearly defines what the tool does. However, it does not differentiate from other crash-related set tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not specify when to use this tool versus other crash settings or any prerequisites. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states the action and options, but does not disclose behavioral traits like whether a reboot is needed, if the change is persistent, or any immediate effects on readings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (two sentences) and front-loaded with the key action. It could be better structured (e.g., bullet points), but it covers the essential information without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers the purpose and values. However, it lacks usage guidelines and behavioral transparency, making it minimally viable but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema for the 'value' parameter is minimally described ('Value for current_meter (UINT8)'). The description adds significant meaning by explaining that 'ADC' means onboard shunt and 'ESC' means ESC telemetry current, and provides the default value. This enriches the parameter semantics beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the current_meter (current sensor source) and lists two options (ADC, ESC). The verb 'set' and resource 'current_meter' are specific. However, it does not explicitly distinguish from siblings like set_adc_device or set_battery_meter, but the purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what ADC and ESC mean and provides a default, giving some context. However, it does not explicitly state when to use this tool vs alternatives such as set_battery_meter, or provide prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions UINT8 and default value, which adds some behavioral info, but it contradicts the schema's allowed range (schema allows negative and very large numbers, while description says UINT8, which is 0-255). No annotations are provided to compensate for the lack of behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short line with no unnecessary words. It would benefit from better structure (e.g., separating name and details), but it is highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tuning parameter in a flight controller, the description lacks context about the role of d_max_pitch, how it affects behavior, or any warnings. It covers only the basic purpose and type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a description for the value parameter. The tool description adds the default value (46), which is useful but does not significantly extend the schema's explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the d_max_pitch parameter for pitch. It specifies the data type (UINT8) and default value (46), which distinguishes it from sibling tools like set_d_max_roll or set_d_max_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: call this tool to set the d_max_pitch value. However, it provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any prerequisites or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present. The description only states what the parameter is and its range, but it does not disclose behavioral traits like whether a reboot is needed, effect on flight performance, or safety considerations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the parameter's purpose, range, and default. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter of a single parameter, the description adequately explains the parameter's meaning and allowed values. Missing behavioral context is minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the parameter. The tool description adds meaningful context by explaining the unit (motor units) and role (above static idle), going beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'dyn_idle_max_increase', explaining it as the maximum throttle increase above static idle. While it distinguishes this parameter from others, it does not differentiate it from many similar set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_dyn_idle_p_gain). No prerequisites or typical scenarios are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses that it sets a gain and suggests a reduction for oscillation, but omits behavioral traits such as whether changes take effect immediately, require saving, or have side effects on other parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a bracket annotation. It front-loads the purpose and uses no unnecessary words, making it efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one input and no output schema, the description covers the basic purpose and a tuning hint. However, it lacks context about how it fits into the broader dynamic idle system (e.g., relationship to I and D gains) or operational notes (e.g., apply while disarmed).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single integer parameter with min/max and description). The description repeats the same range and default in brackets, adding no new semantic information beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the P gain of the dynamic idle RPM controller, which is a specific and distinct resource among many sibling set_* tools. The verb 'Set' is explicit and the resource is well-defined.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only guidance is 'Reduce if idle causes oscillation,' which is a vague tuning hint. There is no explicit statement about when to use this tool versus alternatives like set_dyn_idle_i_gain, or any context about prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states the action without detailing side effects, persistence, reboot requirements, or effects on other settings. The type mismatch (string vs UINT8) reduces clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, but lacks structure (e.g., no sections). Every sentence adds value, but some details (behavior, type) could be better organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is insufficient. It omits important behavioral context like persistence, side effects, and prerequisites, leaving the agent under-informed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter with a basic description; the tool description adds purpose ('Enable Galileo constellation') and default value ('OFF'), providing additional semantic context despite the type discrepancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets the 'gps_ublox_use_galileo' parameter to enable the Galileo constellation on UBlox modules. Distinct from sibling 'get_gps_ublox_use_galileo' and other GPS set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool, prerequisites, or when not to use it. Does not differentiate from other GPS constellation enabling tools or discuss alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly indicates that the switch is not automatically saved (must call cli_save). However, it omits crucial behavioral traits such as whether the tool requires a connected flight controller, whether it can be called while armed, or the impact on the PID controller during flight. Partial transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences, no redundant information, front-loaded with the primary action. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the flight controller context and many sibling tools, the description is minimal. It does not explain what PID profiles are, how many exist, or the relationship with similar tools like set_rate_profile. However, it does cover the essential action and persistence requirement, making it minimally adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good parameter description (type, range, 0-based note). The description only repeats '0-indexed' without adding any new meaning, such as what the index represents (profile number) or typical values. The description adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Switch' and the resource 'active PID profile', and clarifies the indexing is 0-based. This clearly identifies the tool's action, though it could be more specific about what a PID profile is. Still, it distinguishes from other set tools like set_rate_profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a sequential instruction to call cli_save afterwards, which implies that the change is not automatically persisted. However, it does not explain when to use this tool versus alternatives like copy_pid_profile or set_rate_profile, nor does it mention any prerequisites or contexts (e.g., whether flight controller must be disarmed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds the default value (67) and type (UINT8), which informs the valid input range beyond the schema's lax constraints. However, it does not disclose whether the setting is live or requires a reboot, or any other behavioral implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—a single line with a colon and brackets. It efficiently conveys the action, parameter type, and default. It could benefit from slightly more structure but remains appropriate for a simple setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output), the description is mostly complete with the default and type information. However, it omits an explanation of what 'pitch super rate' means and does not mention the valid range enforcement, which is important given the schema's wide bounds.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter 'value' as 'Value for pitch_srate (UINT8),' achieving 100% coverage. The description adds the default value '67,' which the schema lacks, providing additional semantic value beyond the structured definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set pitch_srate: Pitch super rate,' which identifies the action and the specific parameter being set. The tool name and description together make the purpose evident, distinguishing it from sibling tools like set_roll_srate. However, no elaboration on what 'pitch super rate' means is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as checking get_pitch_srate first or understanding the effect on flight modes. There is no mention of prerequisites, side effects, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions type UINT8 and default OFF, but fails to clarify valid values (e.g., 0/1 or 0-5) or the effect of enabling the switch. The term 'Enable' is ambiguous given the 6-position context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with a parenthetical note about type and default. Every part is relevant, though it could be slightly more structured for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description should be complete. It lacks specification of valid parameter values and how the AUX channel maps to the 6-position selection, leaving critical gaps for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description adds context (enable via AUX channel, default OFF) but does not resolve ambiguity about valid values for the 'value' parameter, creating potential confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set/Enable) and resource (rate_6pos_switch) with a specific purpose: enabling 6-position rate profile selection via an AUX channel. It distinguishes itself from sibling getter get_rate_6pos_switch and other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (enable via AUX channel) but does not explicitly state when to use this tool versus alternatives like set_rate_profile or other switch-related settings. No exclusions or conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides value constraints ('UINT16, 0–500, default: 25') but does not disclose behavior such as persistence, immediate effect, or side effects. The range and default add some transparency, but behavioral context is lacking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a bracket with type, range, and default. It is very concise and front-loads the purpose. However, the structure could be improved by placing the constraint info more naturally.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the basic purpose and value constraints. It does not explain what 'scheduler relaxation time' means or when to adjust it, which would be helpful for an agent unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter described). The description adds the default value (25) beyond the schema, which enhances understanding. The type and range are already in the schema, so the description provides marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'scheduler_relax_osd', with a brief explanation 'Scheduler relaxation time for OSD task'. It distinguishes from many sibling 'set_' tools by naming the specific parameter, though it does not explicitly differentiate from the similar 'set_scheduler_relax_rx'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or when not to use it. The description only states what the tool does without any contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the type (UINT8) and default (0), but fails to explain side effects (e.g., persistence, immediate impact), validation, or the discrepancy between the stated UINT8 range and the schema's huge min/max values. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short (one sentence plus notes) and front-loaded with the action. It includes the requirement, type, and default efficiently, but could benefit from slight restructuring for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers purpose, type, default, and a prerequisite. However, it lacks explanation of the parameter's role (S-term), expected side effects, and output. The large range mismatch between description and schema undermines completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'value' is described in the schema as 'Value for s_pitch (UINT8)'. The description adds the default value (0) and the prerequisite requirement, providing useful constraints beyond the schema. However, the schema's min/max are not UINT8 compliant, which is misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and the resource (s_pitch) with context 'S-term for pitch', distinguishing it from sibling setters like set_s_roll and set_s_yaw. It's not a tautology, but could be more explicit about the meaning of 'S-term'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite requirement ('Requires: USE_WING'), which provides some context for when the tool can be used. However, it does not offer guidance on when to adjust s_pitch versus other parameters, nor does it mention alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states it limits maximum throttle output and describes the two modes, but does not disclose side effects, prerequisites, or operational boundaries beyond that minimal info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences that front-load the purpose and efficiently explain the value options. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the core purpose and value semantics. However, it lacks usage guidance or examples, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful context to the parameter by explaining the effect of each value (SCALE, CLIP, OFF) and the type UINT8. The schema only provides a generic description; the description enriches it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the throttle limit type and explains the two modes (SCALE, CLIP) and default OFF. It uses a specific verb+resource, but does not explicitly differentiate from sibling tools like get_throttle_limit_type or other set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use SCALE vs CLIP or when not to use this tool. No alternatives or context for selection are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description should disclose behavioral traits. It only states the set operation and parameter info, but lacks details on persistence, side effects, or whether a reboot is required. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with parameter name, meaning, range, and default. Front-loaded with the verb 'Set'. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description adequately explains the parameter's role and constraints. It lacks information on output or side effects, but given the tool's simplicity and the presence of a getter sibling, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the schema by explaining the parameter's meaning (percentage of vbat_sag_compensation) and providing the default value. Schema coverage is 100%, so the description enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a specific parameter (vbat_cutoff_percent) and defines it as a percentage of vbat_sag_compensation for critically low voltage. It distinguishes from siblings by naming a related parameter but does not explicitly differentiate from other set_vbat_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_vbat_sag_compensation or get_vbat_cutoff_percent. No prerequisites or context provided for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action and parameter info, with no mention of side effects, permissions, or scope of change.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one line) and front-loaded with the purpose. Every word adds value, with no wasted space.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter set tool, the description is minimally complete but lacks any surrounding context (e.g., relation to other vbat parameters, system impact). It meets the bare minimum.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the default value and UINT8 type hint beyond the schema, which already has parameter description. With 100% schema coverage, baseline is 3, and the added info marginally improves understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the specific resource 'vbat_multiplier', and explains it as 'Voltage divider ratio multiplier', which distinguishes it from the many other set_ tools 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.
Usage Guidelines2/5
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. No mention of prerequisites, context, or exclusions. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action without mentioning side effects (e.g., persistence, error handling) or prerequisites like connection state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no unnecessary words, effectively communicating the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (one parameter, no output) and the presence of feature_list as a sibling, the description is mostly complete. It lacks detail on exact name matching but is sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; the parameter 'name' already has a description. The description adds no additional meaning, examples, or valid values, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a verb ('Disable') and resource ('a named feature on the flight controller'), distinguishing it from sibling tools like feature_enable and feature_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as needing to list features first or checking prerequisites. The description only states the function.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the burden. It implies a read operation and hints at the value type ('[UINT32, default: OFF]'), but does not explicitly state no side effects or how the returned value is structured. For a simple getter, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise: two short sentences plus a type annotation. It front-loads the action and resource, with no wasted words. Every part serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic purpose and value type, but lacks details on whether the UINT32 is a boolean flag or bitmask, and does not mention that this is a read-only configuration parameter. For a zero-parameter tool with no output schema, it is minimally complete but leaves some ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters with 100% schema coverage. The description adds context by stating the returned value type (UINT32) and default (OFF), which helps an agent understand what the tool returns. This exceeds the baseline expectation for a no-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the 'blackbox_disable_pids' setting and explains its purpose (exclude PID data from logs, reduce log size). It differentiates from siblings through the specific parameter name but does not explicitly contrast with other get_blackbox_disable_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., other get_blackbox_disable_* tools or set_blackbox_disable_pids). The description only explains what the tool does, not the context for its use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It minimally notes the default value but does not describe side effects, safety (read-only), output type, or other relevant behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a type/default annotation. It is extremely concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a getter with no output schema, the description should indicate what the return value is (e.g., current setting value). It only mentions the default, not the return format or that it returns the current value. Incomplete for an agent to understand the full response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is 100%. The description does not need to add param info. It correctly omits parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the setting that excludes RC channel data from logs. The verb 'Get' matches the tool name, and it distinguishes from siblings like get_blackbox_disable_acc by specifying 'RC channel data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs the setter (set_blackbox_disable_rc) or other similar getters. It does not mention that this is a read-only operation or provide context for selecting this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only states 'Get... Exclude setpoint data.' It does not disclose any behavioral traits such as whether the operation is safe, what side effects exist, or the format of the return value beyond type hinting. Minimal additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single line with essential information. However, the phrase 'Exclude setpoint data' could be clearer as it describes the setting's effect rather than the tool's action, but overall it is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description partially compensates by mentioning type and default, but it lacks details on the meaning of the return value (e.g., whether it's a boolean or flag). Among many similar siblings, it does not provide enough context to fully understand the tool's role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so description coverage is trivial. The description adds meaning by specifying the return type ([UINT32]) and default value (OFF), which is useful information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the setting for excluding setpoint data from blackbox logging, using a specific verb ('Get') and resource ('blackbox_disable_setpoint'). It distinguishes from siblings like get_blackbox_disable_acc by its unique suffix and explicit purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., set_blackbox_disable_setpoint). It does not explain that this is a read-only retrieval, nor does it mention any prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It fails to state that the tool is read-only, safe, or idempotent. A simple getter may be assumed safe, but explicit statement would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus type/default) and front-loads the core purpose. However, it could be more structured by separating the purpose from technical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description is minimally complete: it states what is retrieved, the context (idle throttle), type, and default. Missing is the broader tuning context or relation to sibling parameters like min/max.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (empty input schema, 100% coverage), so no parameter explanation is needed. The description adds value by explaining the retrieved parameter's type and default, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the dynamic D-term LPF1 minimum cutoff at idle throttle, with specific values like AOS tune 80 Hz and default 75. The purpose is unambiguous and distinct from siblings like get_dterm_lpf1_dyn_max_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus related getters (e.g., get_dterm_lpf1_dyn_max_hz) or setter counterparts. The description does not help an agent select among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data type, valid range, and default value, indicating a non-destructive read operation. However, it does not describe any side effects, permissions, or stability implications, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: 14 words covering purpose, resource, type, range, and default. Front-loaded with the action 'Get'. Every word earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter getter with no parameters and no output schema, the description provides the essential information. However, it lacks any context on how the I gain fits into the dynamic idle system or when to query it, which could be helpful given the many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (schema description coverage 100%), so no parameter documentation is needed. The description adds value by specifying the return value's type, range, and default, which is helpful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the I gain of the dynamic idle RPM controller (verb+resource). It does not explicitly differentiate from many sibling get_* tools, but the naming pattern is consistent and the resource is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The description implies it is for reading a parameter, but does not mention when-not to use or provide comparisons with similar tools like get_dyn_idle_p_gain or set_dyn_idle_i_gain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It explains the tool overrides auto-detection and gives value semantics, but lacks broader behavioral context (persistence, permissions, side effects on other settings). Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus range/default notation. Every word adds value. No redundancy. Front-loaded with action and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple parameter getter: explains value meaning and range. However, does not explicitly state that it returns the current setting value, nor mention any related configuration (e.g., set_force_battery_cell_count). Output schema absent, so description could clarify return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, baseline 4. Description adds meaning by explaining that the returned value represents forced cell count override (0 = auto-detect), which is valuable beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the forced battery cell count override, explains special value 0 meaning auto-detect, and specifies range [0-24] with default. It distinguishes from the sibling setter by naming convention, but does not explicitly compare to similar get tools like get_vbat_max_cell_voltage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Minimal guidance: explains 0 means auto-detect, implying use this to read override. No explicit when-to-use or when-not-to-use compared to alternatives (e.g., get_vbat_max_cell_voltage or get_battery). Sibling setter exists but not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral details. It lists output fields but fails to disclose important traits such as whether the tool returns a snapshot vs. streaming, if it blocks until a fix is obtained, or what happens if GPS is unavailable. The read-only nature is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence) and front-loaded with the purpose. It efficiently lists fields with units, though adding structure (e.g., bullet points) could improve scanability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately lists the returned data fields. However, it lacks context on output format or behavior (e.g., real-time vs. cached), which would be useful given the large number of sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description is not required to add parameter semantics. Schema coverage is 100%, achieving the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves GPS data and enumerates specific fields (fix status, satellite count, lat/lon, altitude, ground speed) with units. It distinguishes itself from sibling get_gps_* tools (which are configuration parameters) by focusing on live data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for obtaining current GPS readings, but it does not explicitly state when to use this tool versus alternatives like get_altitude or other GPS-related tools. No guidance on prerequisites (e.g., GPS must be connected) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not explicitly state that this is a read-only operation or discuss any behavioral traits such as side effects or prerequisites. It is implied but not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence plus bracket notation. It includes essential information without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description provides the type and default but lacks a full list of possible values or an explanation of how the returned value maps to dynamic models. It is adequate for a simple getter with no parameters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters present, so baseline is 4. The description adds value by specifying the return type (UINT8) and default value (AIRBORNE_4G), which aids interpretation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves the UBlox dynamic model used during flight, specifically mentioning AIRBORNE_4G for high-dynamics FPV. This distinguishes it from sibling tools as a getter for a specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool over other get_ tools. The description does not indicate context for use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for transparency. It indicates the tool is a getter (read-only) and notes the data type (UINT8) and default (OFF). However, it fails to explain what the returned values represent (e.g., 0=OFF, 1=ON) or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a bracketed note. It front-loads the action and includes all essential information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description is adequate but could be improved by specifying the return format (e.g., integer value) or mentioning that it returns the current setting. Given the lack of output schema, some additional context would help.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add parameter details. Schema coverage is 100%, and the description appropriately mentions the data type and default value, providing sufficient context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'gps_use_3d_speed', with a brief explanation that it retrieves whether 3D speed is used. It distinguishes from the sibling 'set_gps_use_3d_speed' tool, but does not differentiate from other similar getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention that this is a read-only operation or suggest checking this before setting, nor does it list any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates the return type (UINT8) and default value (ROLL), which adds some transparency, but does not disclose any potential errors or side effects. For a simple getter, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence names the resource, and the second adds type and default. It is well-structured and front-loaded without fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description provides the essential information (purpose, return type, default). However, it does not explain what 'debug fields' are or how this axis affects gyro filter analysis, which could help an agent differentiate among many similar getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%, so the baseline is 3. The description adds the return type and default value, which is useful for understanding the output but not for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the axis exposed in debug fields for gyro filter analysis. It uses a specific verb ('Get') and resource ('gyro_filter_debug_axis'), and distinguishes from siblings like set_gyro_filter_debug_axis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus the many other getter siblings (e.g., get_gyro_offset_yaw). The description does not provide context for appropriate usage conditions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description correctly implies it is a read-only operation with no side effects. It does not disclose any additional behavioral traits such as data format or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, with two sentences and a type/default note. It is front-loaded with the purpose and efficiently conveys all necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description covers the core meaning but lacks details such as the exact data type representation (e.g., whether it returns a number or string) and any related configuration context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100%. The description adds value by explaining the meaning of the returned values and the default, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the hardware low-pass filter mode for the gyro chip and explains the meaning of possible values. It distinguishes itself from the set counterpart but does not explicitly differentiate from other gyro-related getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other gyro filter getters (e.g., get_gyro_lpf1_static_hz). There is no mention of context or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description should disclose behavioral traits. It only states the purpose and default value, not whether the tool is read-only, requires specific permissions, or any side effects. The name implies a getter, but no explicit reassurance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the key purpose and a brief explanation of the value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description explains what the retrieved value represents and its default. However, it could mention the return type or range to be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0). Baseline is 4. The description adds the default value and meaning of PT1, which provides some extra context beyond the schema, but is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the gyro_lpf1_type, explains what the filter type means (PT1 = first-order, least delay), and distinguishes it from other gyro-related get tools by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs alternatives like get_gyro_lpf1_static_hz or get_gyro_lpf1_dyn_*. The agent must infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It indicates a read operation ('Get') and specifies the data type [UINT8] and default value, but does not disclose return format, side effects, or whether this is a simple configuration read vs. a computed value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a parenthetical type annotation. Every word adds value with no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no input/output schema, the description is minimal. It explains the tool's purpose and value characteristics but omits return structure, units, or relation to other configuration tools. Adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters; schema coverage is trivially 100%. The description adds marginal value by noting the data type and default, which may hint at the return value format. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'simplified_d_max_gain' with a brief explanation 'D_max scaling slider (dynamic damping ceiling)'. It distinguishes from sibling 'get_d_max_gain' by naming the simplified variant, but does not explicitly differentiate usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_d_max_gain' or related set tools. The description does not mention exclusions, prerequisites, or context for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data type (UINT8) and default value (ON), which is helpful. However, it does not explicitly state that the operation is read-only, approximate permissions, or any side effects. The lack of contradiction with annotations (none present) keeps the score at a mid-level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded: it states the tool name, purpose, type, and default in a single sentence. Every word earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no input parameters and no output schema, the description is fairly complete for a simple getter. However, it lacks context about how this parameter fits into the broader simplified PID system or its relationship with sibling tools like set_simplified_dterm_filter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100%. The description adds value by specifying the type and default, which goes beyond the empty schema. Baseline for 0-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the 'simplified_dterm_filter' parameter and explains that it controls whether a simplified slider controls D-term filter cutoffs. The verb 'Get' and the resource are explicit, but there is no differentiation from many sibling getter tools with similar naming patterns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description does not mention related tools (e.g., set_simplified_dterm_filter for setting, or other filter getters), leaving the agent to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It discloses the parameter type (UINT8) and default (OFF), but lacks details on side effects, persistence, or error behavior if the sensor does not support high-range mode. Some useful info but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. First sentence clearly states purpose, second adds parameter info. Efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter set tool, the description covers purpose and default, but lacks explanation of what high-range mode means, what range of values are valid, and any behavioral notes. Given no output schema and no annotations, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides parameter info but description adds the default value 'OFF' which is not in the schema. It also confirms the type as UINT8. With 100% schema coverage, the description adds meaningful default, enhancing semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Enable' and resource 'high-range accelerometer mode' with a condition 'for sensors that support it'. It is distinct from siblings like get_acc_high_range (read) and calibrate_accelerometer (different action).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, no conditions for use or when not to use. The description does not help the agent decide between set_acc_high_range and other set_ tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a mutation ('Set') but does not disclose side effects, prerequisites (e.g., arming state), or whether the change is persistent. The range and default are helpful but insufficient for 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with essential additional details in brackets. It is concise and front-loaded, but the structure could be improved by separating the range info into a bullet or clearer format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description adequately explains purpose and range. However, it does not mention the corresponding getter (get_acc_trim_roll) or how this fits into the calibration workflow, which could be useful context given the large sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description repeats the type, range, and default already in the schema property description. It adds no new meaning beyond what the schema provides, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'acc_trim_roll', and its purpose 'roll trim for level calibration'. This distinguishes it from siblings like set_acc_trim_pitch (pitch trim) and get_acc_trim_roll (read).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context (level calibration) but does not explicitly state when to use this tool versus alternatives like calibrate_accelerometer or set_acc_trim_pitch. No exclusions or when-not-to-use guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the effect on flight behavior but does not mention if the change is persistent, requires reboot, can be set while armed, or any safety implications. Incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with added details in brackets. It is front-loaded with the tool name and key information. Very concise, but could be slightly restructured for better readability (e.g., separating the default).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers purpose, effect, range, and default. However, it lacks usage guidance and transparency about side effects, making it adequate but not complete for safe autonomous use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (parameter 'value' documented). The description adds the default value (50) and explains the behavioral effect of higher values, providing useful context beyond the schema. However, it does not elaborate on format or units beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'angle_p_gain' and defines it as 'P gain for angle mode self-leveling'. It includes the effect ('Higher = stronger return to level') and provides data type, range, and default. This distinguishes it from many sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other PID tuning tools. It does not mention prerequisites, when not to adjust this parameter, or how it interacts with other settings. The agent has no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should cover behavioral traits. It only lists values and default, omitting potential side effects, required disarm state, or impact on existing logging. The description is incomplete for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional details in brackets. It is concise and front-loaded, though the parameter info is somewhat jammed together.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the essential values and default. However, it omits prerequisites (e.g., status of flight controller) and potential consequences, which would be helpful for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes 'value' as UINT8, but the description adds the acceptable string values (NORMAL, ALWAYS, MOTOR_TEST) and default. This adds meaningful context beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states it sets the blackbox mode and enumerates the three possible values (NORMAL, ALWAYS, MOTOR_TEST) with clear explanations. This distinguishes it from get_blackbox_mode and other set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or prerequisites. The agent is left to infer from context that one would set the mode before or after configuring other blackbox settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description mentions the data type ('INT8') and default value ('OFF'), and explains the behavior. However, it does not disclose whether changes are persistent, require restart, or have side effects. With no annotations, the description carries the burden but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a short bracketed note. All information is front-loaded and no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without annotations or output schema, the description covers the basic purpose, type, and default. However, it does not specify allowed values (e.g., 0=OFF, 1=ON) or behavior details, which would be helpful for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameter generically ('Value for crashflip_auto_rearm (INT8)'). The description adds 'default: OFF', which clarifies expected values and gives context beyond the schema. Schema coverage is 100%, so the description compensates with additional detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets the 'crashflip_auto_rearm' parameter and explains its purpose ('Automatically re-arm after a successful crash flip recovery'). This differentiates it from other set_* tools that modify different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, prerequisites, or conditions where it should be avoided. It only states what it does, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the data type (UINT16) and default value (125), but omits side effects (e.g., requires reboot, write to flash, affects flight behavior).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical note, concise and front-loaded. Every word contributes information, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple setter with 100% schema coverage, the description provides essential info but lacks details on persistence (volatile vs saved), when the value takes effect, or if any constraints beyond schema apply. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'Feed forward for pitch' beyond the schema's 'Value for f_pitch (UINT16)', explaining the parameter's purpose. Since schema coverage is 100%, baseline is 3, and this adds meaningful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the feed forward value for pitch ('Feed forward for pitch'), distinguishing it from other set_* tools. The verb 'Set' is explicit, and the resource 'f_pitch' is identified. However, it could more clearly differentiate from the 'get_f_pitch' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_f_pitch' or whether there are prerequisites (e.g., motor stopped, disarmed). The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It states that the tool sets a value and mentions the default, but it does not explain whether the change is persistent, takes effect immediately, or requires a save command. The description is adequate for a simple setter but lacks depth on side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a single sentence with a bracketed note on type and default. It is front-loaded and to the point. However, the phrase 'Pitch I gain' is somewhat jargon-heavy and could be slightly clarified for broader understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the core information: what is set, the data type, and the default. It is reasonably complete for domain experts but lacks explanation of the PID context and usage, which could aid agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the 'value' parameter, achieving 100% coverage. The tool description adds the default value of 84 and clarifies the parameter as 'Pitch I gain', providing useful context beyond the schema. This justifies a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the i_pitch parameter, which is the Pitch I gain. It includes the data type (UINT8) and default value, making the action unambiguous. However, it does not explicitly distinguish this tool from other PID-related setters like set_d_pitch or set_p_pitch, although 'i_pitch' and 'Pitch I gain' inherently point to the integral component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of the PID controller structure, when adjusting I gain is appropriate, or how it relates to other gains. The agent must infer usage from domain knowledge alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It explains the basic function (setting axes for I-term relaxation) but lacks details on persistence, side effects, or whether changes take effect immediately or require a reboot. The mention of 'UINT8' in the description may also conflict with the schema's 'string' type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one self-contained sentence followed by brief clarifications. It is front-loaded with the primary action and resource, and every part serves a purpose without superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides adequate context but lacks some completeness. It does not mention default value implications or how this setting interacts with other I-term relaxation parameters. For a more complex context, additional guidance would be needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant value beyond the schema. It interprets the single parameter 'value' by explaining the meaningful options ('RP' and 'RPY') and their effects on axes. This helps an agent generate correct parameter values beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'iterm_relax', explaining that it controls which axes have I-term relaxation (anti-windup) active. It provides specific meanings for values like 'RP' (roll and pitch) and 'RPY' (includes yaw). While it doesn't explicitly differentiate from sibling tools like set_iterm_relax_type, the purpose is clear and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., set_iterm_relax_type or set_iterm_relax_cutoff). Usage context is implied by the function (setting axes for anti-windup), but no when-not-to-use or prerequisite conditions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It only lists value meanings but does not state that this is a persistent configuration write, potential side effects, or if a reboot is required. The agent lacks information to understand the operation's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, packing the value explanations into a single dense sentence. It is front-loaded with the core purpose. No unnecessary words, though it could be slightly restructured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the value semantics adequately. However, it omits whether the tool returns a success/failure response or if it triggers any side effects, which would be helpful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a generic description ('Value for mixer_type (UINT8)'). The description adds substantial meaning by explaining each possible value (LEGACY, LINEAR, DYNAMIC, EZLANDING) and indicating the default, significantly aiding agent understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's purpose: setting the mixer_type, which controls the motor mixer output mode. It lists the four possible values with brief explanations, making the function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Among many set_ siblings, the description does not distinguish when mixer_type should be changed or provide context for selecting among the options beyond their definitions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description provides range and default for the parameter, but no annotations exist to cover safety or destructiveness. It fails to disclose whether the change is persistent, requires a save/reboot, or if it has side effects on other settings. As a write operation, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence with all essential information (purpose, type, range, default). No wasted words; highly efficient for a simple parameter setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward setter with one parameter and no output schema, the description covers the core purpose, constraints, and default. It lacks mention of persistence or effect timing, but given the tool's simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the same range and description as the tool description. The description adds only the default value (0) beyond the schema, offering minimal additional semantic value. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets the RSSI offset with specific verb 'Set' and resource 'rssi_offset'. Specifies the action as 'Offsets the RSSI reading', distinguishing it from siblings like set_rssi_channel or set_rssi_scale which have different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives or any prerequisites. The description only states what the tool does without context such as typical scenarios or conditions where adjusting RSSI offset is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the parameter type and default. It does not disclose side effects, persistence, or whether a reboot is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line includes the tool's purpose, type, and default. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a set command with no output schema, the description lacks context about persistence, reboot requirements, or relationship to other simplified PID settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the parameter fully (100% coverage). Description adds the default value (100), which is not in the schema, adding useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the simplified_feedforward_gain as a feedforward scaling slider, distinguishing it from sibling tools like set_simplified_d_gain or get_simplified_feedforward_gain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Among many similar 'set_simplified_*' tools, the description does not explain context or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that the tool sets a value (a mutation), but does not mention side effects, persistence, or any other runtime behavior. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with supplementary details in parentheses. Every element serves a purpose; no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool, the description covers the core function and a key prerequisite. However, it does not specify valid values for the parameter (e.g., 'ON', 'OFF', etc.) nor describe the return value. It is adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter with a description that reads 'Value for spa_pitch_mode (UINT8)'. The tool description adds extra info: default value ('OFF (per profile)') and data type, which aids understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'spa_pitch_mode' for pitch SPA mode. It is distinct from the corresponding get tool and other set tools via the specific parameter name. However, it lacks explicit differentiation from other set tools beyond naming.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes a requirement: 'Requires: USE_WING', providing a precondition for using the tool. No guidance on when not to use it or alternatives is given, leaving room for improvement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose important behavioral aspects such as whether the change is immediate, persists across reboots, or requires a restart. The description only states what the tool does, not the implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, two sentences plus a bracketed spec. It front-loads the key information and has no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema), the description covers the essential purpose and parameter semantics. However, it lacks behavioral context about persistence and side effects, which would be valuable for a setting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the only parameter. The tool description adds meaning by explaining the physical significance ('External crystal frequency in MHz') and the special auto-detect behavior (0), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the external crystal frequency in MHz, specifying the resource and unit. It adds context about non-standard clock speeds, but does not explicitly differentiate from other set_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Required for some non-standard clock speeds' and 'Set to 0 for auto-detect', giving limited usage guidance. However, no alternatives or when-not-to-use conditions are provided, and the tool is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether the change is immediate, persistent, requires reboot, or how invalid inputs are handled. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence plus metadata in parentheses. It front-loads the purpose and includes type, default, and requirement in a well-organized manner with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration parameter with one input and no output schema, the description covers purpose, requirement, type, default, and unit. However, it lacks behavioral details (e.g., side effects, validation) that would be helpful given the absence of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description is minimal ('Value for tpa_speed_adv_thrust (UINT16)'), but the tool description adds the unit (g), default value (2000), and context (advanced model). This significantly enhances parameter understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'tpa_speed_adv_thrust', defining it as 'Maximum thrust (g) for ADVANCED speed TPA physics model.' It distinguishes from siblings by specifying 'ADVANCED' and the unit, though it lacks explicit differentiation from similar advanced parameters like tpa_speed_adv_drag_k.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite (_Requires: USE_WING_) and specifies the data type and default, but does not provide when-not-to-use guidance or compare to alternative tools like basic TPA settings or other advanced parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks details on behavioral traits such as persistence, immediate effect, side effects, or required permissions. Only states the basic function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus parenthetical type/default info. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks details on value range (0-255?) and whether setting is boolean-like. No mention of when changes take effect or if reboot required. Inadequate given no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds helpful context beyond schema: indicates data type (UINT8) and default value (OFF). Schema only describes 'value' as a string; description clarifies expected numeric type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets 'use_cbat_alerts' to enable capacity-based OSD/beeper warnings. Distinct from sibling tools like 'set_cbat_alert_percent' and 'set_use_vbat_alerts'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not specify conditions or prerequisites for setting this parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the value range and default, and explains the behavioral impact of higher values. However, it does not mention if the operation has any side effects or is purely read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one line explaining functionality plus a brief range specification. Every word is necessary and no redundancy exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter getter, the description is sufficiently complete. It explains what the value represents and its effect. However, given the extensive sibling list, a note about this being specific to angle mode self-leveling would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description adds value by explaining the meaning of the retrieved value and its range, which is beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the P gain for angle mode self-leveling and explains the effect of higher values. It is specific and informative, but does not explicitly differentiate from sibling get_angle_* tools, so it falls short of the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lacks any guidance on when to use this tool versus alternatives. It does not mention use cases, prerequisites, or when not to use it, leaving the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It only states what the tool does, not whether it requires a connection, is read-only, or has any side effects. A simple getter is implied, but more detail would help.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, complete sentence of 13 words with no extraneous information. It is front-loaded and every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description should specify the return structure. It lists the three angles but not how they are packaged (e.g., object with fields). For a zero-parameter tool, it is mostly adequate but lacks format detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%. Per rubric, baseline for 0 params is 4. The description does not add parameter info, which is acceptable since there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'attitude', and specifies the returned values (roll, pitch, yaw in degrees). It distinguishes this tool from siblings like get_altitude or get_battery by naming the exact attitude components.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 such as get_status or get_raw_imu. It does not mention context like flight mode or preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It reveals the return type (UINT8), default (ADC), and possible values, which is adequate for a simple read-only tool. However, it does not explicitly state that no side effects occur or describe the exact output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point. It includes necessary abbreviations and default value efficiently. Could be slightly more structured, but overall it is concise without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, read-only) and no output schema, the description sufficiently indicates that it retrieves the battery voltage source and explains the options. It is complete enough for an agent to understand the tool's purpose and expected return.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters; the schema coverage is trivially 100%. The description adds no parameter information beyond the schema because none exist. Baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description clearly state it retrieves the battery voltage reading source. It explains the two possible sources (ADC and ESC), making it distinct from the many other get_* tools and the set_battery_meter sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. While a sibling set_battery_meter exists, there is no mention of when to use get vs set, or any other usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should clarify behavioral traits. It only provides the parameter range and default, omitting whether the operation is read-only, requires permissions, or triggers side effects. The name implies reading but no explicit statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise phrases conveying essential information: what the parameter is and its technical constraints. No redundant words, front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the basic parameter details but does not explain how crash_time relates to other crash settings or recovery triggers. With many crash siblings, more context (e.g., typical usage or interaction) would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters exist, so the schema coverage is 100%. The description adds value by explaining the output parameter's data type (UINT16), range (100-5000), and default (500 per profile), which is not present in the output schema (none exists).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'crash_time' parameter, defines its purpose as the minimum crash duration before recovery triggers, and provides data type and range. It distinguishes itself from sibling tools like 'set_crash_time' and other 'get_crash_*' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other crash-related getters (e.g., get_crash_delay, get_crash_dthreshold). The description lacks context about usage scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation ('Get') and includes technical context about the parameter's behavior. However, with no annotations, it could explicitly state that the tool is safe and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence that packs meaning. No redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description explains the parameter's role and defaults. It could mention that the output is a single numeric value, but it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add much. It includes the type (UINT8) and default value (30), which compensates for lacking parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'd_roll' parameter (D gain for roll axis) and explains its function in flight. However, it does not explicitly distinguish from sibling getters for other axes or parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus other getters (e.g., get_p_roll, get_d_pitch). No alternative tools or scenarios are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not explicitly state it's read-only or mention side effects/permissions. The name 'get_' implies no mutation, but the description could be more transparent about behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise – one sentence plus a parenthetical note. Front-loaded with tool name and explanation. Every word adds value, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a parameterless getter, description explains the setting's meaning and default. Lacks explicit mention of read-only nature and cross-references to sibling tools, but largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description's inclusion of default value and type [UINT8, default: 0] adds semantic value beyond the empty schema. Schema coverage is 100% vacuously, but description enhances understanding of the returned value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the Yaw D gain setting, a specific resource. Gives context on why it's usually left at 0, but doesn't explicitly differentiate from other D gain tools (e.g., get_d_pitch). Still, the description is clear and informative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies when not to use (keep at 0) but doesn't explicitly state when to use or mention alternatives like set_d_yaw. Provides context but lacks direct usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden of disclosing behavior. The name 'Get' implies a read-only operation, and the description does not contradict this. It adds the data type and range [UINT8, 0–200, default: 0], which is useful, but it does not explicitly state the tool is safe or idempotent. The description is minimally adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded. It contains three short sentences and a bracketed specification, with no filler or redundant information. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides sufficient context: it explains what dynamic idle is, that setting a non-zero value enables it, the targeting by prop size, and the value's range. Minor omission: it does not explicitly state that the tool returns the current value, but this is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% and the baseline is 3. The description adds value beyond the schema by documenting the parameter's data type, range, and default value (UINT8, 0–200, default: 0). This helps the agent understand the nature of the retrieved value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads the 'Minimum motor RPM maintained by dynamic idle.' It uses the verb 'Get' and identifies the specific parameter. However, it does not explicitly differentiate from other getter tools among the many siblings, relying on the parameter name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description briefly mentions that setting this value non-zero enables dynamic idle and that it is targeted by prop size, but it provides no guidance on when to use this getter versus alternatives (e.g., set_dyn_idle_min_rpm). There is no explicit 'when to use' or 'when not to use' information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose behavioral traits such as read-only nature, side effects, or authentication needs. It only describes the parameter value itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with inline type annotation; no fluff. All information is front-loaded and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter retrieval tool with no output schema, the description covers the value's meaning, type, range, and default. Slightly incomplete due to lack of behavioral context, but acceptable for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters; baseline is 4. Description adds value by specifying the return type (UINT8), range (0-250), and default (50 per profile), which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the rate of throttle reduction during EZ landing and provides the value's type, range, and default. It distinguishes from siblings like get_ez_landing_limit and get_ez_landing_threshold by naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_ez_landing_speed. No context about prerequisites or invocation conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the return type and default value and the requirement, but does not mention any side effects, failure modes, or interaction with the setter. Adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parenthetical note, efficiently conveying purpose, requirement, type, and default. No redundancy or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is fairly complete: it specifies the purpose, requirement, type, and default. It could mention the expected return format or units, but it's largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. According to guidelines, baseline score for 0 parameters is 4. The description adds the compile-time requirement and default value, which adds context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the SPI bus number for onboard flash used for blackbox storage, specifies a compile-time requirement, type, and default. However, it does not differentiate from sibling getters, but within the context of many getters, this is acceptable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the compile-time flag requirement but provides no guidance on when to use this tool versus the sibling setter or other tools. There is no explicit condition or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains what the setting does (abort conditions), its data type (UINT8), and default value (RESCUE_SANITY_FS_ONLY). This adds significant context beyond the empty input schema. It does not mention that it is a read-only operation, but that is implicit from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and informative, using a single sentence with a colon and listing conditions. No wasted words, but could be better structured with bullet points for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description adequately explains the tool's purpose and behavior. However, it does not list the possible enum values or explain what RESCUE_SANITY_FS_ONLY means in context. Slightly more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema_description_coverage is 100%. The description does not need to explain parameters. Baseline score of 4 for zero parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the GPS rescue sanity checks configuration and explains its purpose (aborts rescue in certain conditions). It distinguishes from siblings by focusing on sanity checks. However, it does not explicitly state that it is a 'getter' function, but the naming convention implies it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. The description suggests it is a recommended setting but does not compare to set_gps_rescue_sanity_checks or other tools. No when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description is the sole source of behavioral information. It notes the type (UINT8) and default (OFF), but does not explain the effect of changing the value or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise but somewhat redundant: 'Get gps_sbas_integrity' repeats the tool name. The type and default are useful but could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter read with no parameters or output schema, the description provides basic purpose and type info. However, it does not specify the return format (e.g., ON/OFF or numeric values).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the baseline score is 4. The description adds no additional parameter meaning, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool is used to get the gps_sbas_integrity parameter, which controls whether SBAS integrity data is required. It distinguishes itself from sibling tools like get_gps_sbas_mode and set_gps_sbas_integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description indicates the tool is a getter for a parameter, it does not explicitly state when to use it versus alternatives, nor does it provide guidance on context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the data type and default, indicating a read-only operation with no side effects. However, it does not mention permissions, rate limits, or potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence followed by a bracketed type/default. It is front-loaded, with no superfluous words. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description adequately explains what the tool returns (the max_check value). It could mention broader context like its role in arming configuration, but it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (no parameters), so schema coverage is 100%. Per guidelines, 0 parameters earns a baseline of 4. The description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets the max_check RC channel threshold value for arm/disarm and stick commands. It specifies the type (UINT16) and default value. However, it does not explicitly differentiate from the sibling 'get_min_check' or other related getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like 'get_min_check' or similar getters. It implies a general retrieval use case but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description is the sole source. It indicates a read operation, but does not explicitly state it is read-only or side-effect-free. The data type and default are helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and informative, though it redundantly repeats the tool name. Key details (data type, default, protocol context) are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description covers the purpose and data type. However, it does not explicitly describe the return format (e.g., single UINT16 value).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so no parameter documentation is needed. The description does not add parameter info, but that is acceptable given the schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the maximum PWM value sent to ESCs, with protocol context and default. Despite many sibling getters, the naming and description make its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to read the max throttle PWM value, but provides no guidance on when to use this tool vs. alternatives like set_max_throttle or other getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only implies read-only and gives type/default, but lacks disclosure of any side effects or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with name and key info (type, default). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple getter with no parameters and no output schema. Provides type and default value, sufficient for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. Baseline of 4 applies; description adds no param info but also doesn't need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a 'hard cap on pitch rate' with specific verb 'Get' and resource. It is distinct among many 'get_' siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Does not mention context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description must provide behavioral insight. It warns of oscillations if value is too high, which is useful. However, it does not explicitly state that this is a safe read-only operation (though implied by 'get'). The UINT8 and default are mentioned. Overall 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short sentences with no filler. The behavioral warning is relevant and efficiently stated. The type/default is appended as a bracketed note. Excellent structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately covers purpose, value range, and tuning implication. It does not explicitly state 'returns current value' but that's clear from 'Get p_roll'. Could be considered nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is trivially 100%. The description adds context about the value's type (UINT8) and default (45), which helps the agent understand the returned data. This meets baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Purpose is clearly stated as retrieving the Roll P gain, a proportional term reacting to angle error. The description differentiates from other gains (I, D) and from the set counterpart. It also provides a behavioral note about high values causing oscillations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_d_roll or set_p_roll. The description implies tuning context but does not state when to read vs set or compare to other gains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only mentions the default value and that ACTUAL sets center sens and max rate directly. It does not disclose any behavioral traits such as whether the operation is idempotent, requires specific permissions, or has side effects. For a simple getter, this is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two terse sentences. It front-loads the purpose ('Get rates_type') and adds meaningful context about the ACTUAL mode. Every word serves a purpose; no wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (no params, no output schema), the description mostly explains the tool. However, it omits enumeration of other possible rates_type values beyond ACTUAL, which would help an agent understand the full set of possible return values. It mentions the default but not the full domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so schema description coverage is 100%. According to guidelines, 0 parameters baseline is 4. The description does not add parameter information nor does it need to.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get rates_type: Rate calculation system.' and explains what ACTUAL means, making the tool's purpose immediately understandable. It distinguishes from sibling tools like set_rates_type by conveying it is a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., set_rates_type). While the naming convention implies a getter, the description fails to state that this is for reading the current configuration, leaving usage context implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only states what data is returned. No disclosure of frequency, real-time nature, side effects, or blocking behavior. Bare minimum for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single 13-word sentence front-loads the purpose and lists data types with units. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple parameterless tool, but lacks details on output format (e.g., single snapshot vs. stream) and whether all three sensors are returned together. No output schema to compensate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (0 params, 100% coverage). Baseline of 4 applies as description does not need to explain parameters. It correctly omits parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get' and resource 'raw IMU sensor data' with specific measurement types (accelerometer, gyroscope, magnetometer) and units (G, °/s). Distinguishes from sibling tools like 'get_attitude' or 'get_acc_calibration'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention scenarios (e.g., debugging, calibration) or prerequisites. Sibling tools like calibrate accelerometer/magnetometer exist but no comparison provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral context by specifying the value type (UINT16), default (1998), and its application ('applied after the rates curve'). However, it does not disclose whether connectivity is required, if the value is cached, or any side effects. The implied read-only nature is evident from the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. Every word adds value: the name, the definition, units, data type, and default. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a clear sibling context, the description sufficiently explains what the tool does and what the returned value means. It could mention that the value is read-only or that it comes from the current configuration, but this is minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100% and the baseline is 4. The description adds meaning by explaining the parameter's role and constraints, which is helpful but not essential here.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'roll_rate_limit' parameter and explains what it represents: a hard cap on roll rate in deg/s applied after the rates curve. The name among many sibling 'get_' tools is self-explanatory, though no explicit differentiation is provided.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives (e.g., set_roll_rate_limit or other getters). It does not specify prerequisites or context for retrieval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the safety behavior (detects and disarms) and provides the return type and default. However, it does not explicitly state that the tool is non-destructive or idempotent, nor does it mention any side effects or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a parenthetical type annotation. It immediately states the tool's purpose and key behavior, with no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the essential aspects: what the feature does and the return type. It is adequate for the agent to understand the tool's role, though it could benefit from noting that the output is the current value of the setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters and schema coverage is 100%. The description adds value by specifying the return type as '[UINT8, default: ON]', which is not present in the schema. This helps the agent understand the output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the 'runaway_takeoff_prevention' setting and explains the feature's purpose: detecting uncommanded throttle-up on arm to prevent injury. This distinguishes it from sibling tools like 'set_runaway_takeoff_prevention' and other getters, though no explicit differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool vs. alternatives. For instance, there is no mention that this is a read operation and that 'set_runaway_takeoff_prevention' should be used to modify the setting. The description only explains the feature, not usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds value by specifying the value type (UINT16), range (0–500), and default (25), but does not explicitly state it is a read-only operation, though 'Get' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise and well-structured: one sentence plus bracket info. Every part is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with no parameters and no output schema, the description adequately covers purpose, value type, range, and default. Could add more context on when to adjust this value, but sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in schema. Description adds meaning with value type and constraints, which is helpful. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Get scheduler_relax_rx' and explains it controls how much other tasks can run during RX processing. However, it does not explicitly distinguish from sibling 'get_scheduler_relax_osd' or 'set_scheduler_relax_rx'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_scheduler_relax_osd or the set counterpart. The description lacks context on appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the meaning of the value, its type (UINT16), default (0), and that it's per profile. However, it does not disclose any side effects, error conditions, or whether it is safe to call (though as a getter it is presumably safe).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus type/default info. It is front-loaded with the purpose and includes requirement and default. No extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description covers purpose, requirement, data type, default, and per-profile scope. It is adequate but could mention that it reads a configuration value from the flight controller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage). The description adds value by specifying the data type and default, which are not in the schema. Per the rules, baseline is 4 for 0 params, and the description meets this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the setpoint centre value for roll attenuation. It distinguishes from sibling tools like get_spa_roll_mode or set_spa_roll_center. However, it begins by repeating the tool name rather than using a more explicit verb like 'retrieves'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires: USE_WING' but provides no guidance on when to use this tool versus alternatives (e.g., get_spa_roll_mode, get_spa_roll_width). No context is given about typical use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially covers behavioral traits. 'Get' implies a read-only operation, but it does not explicitly state safety (e.g., no side effects). It adds the data type and default, which gives some behavioral context. However, it lacks details on whether the operation blocks, requires specific state, or has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two lines, with no wasted words. It starts with the purpose, then defines possible values, and ends with type and default. Every sentence adds value, and it is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters, no output schema, and no annotations, the description provides adequate context: it explains the returned value, its type, and the meaning of each enum. It does not discuss return state (e.g., JSON or raw) or error conditions, but for a simple getter of a single setting, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (100% coverage), so there are no parameters to document. The description adds value by explaining the return value semantics: UINT8 with possible values SCALE, CLIP, and a default of OFF. This helps the agent understand what the output means, compensating for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the throttle limit type and explains the meaning of possible values (SCALE, CLIP, default OFF). While it repeats the tool name, it adds context about the purpose and distinguishes this from other getters by specifying the resource and its semantics. However, it does not explicitly differentiate from sibling tools like get_throttle_limit_percent, but the distinct resource is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_throttle_limit_percent, set_throttle_limit_type). It does not mention prerequisites, such as needing to be connected to a flight controller, or typical scenarios (e.g., checking current mode before setting it).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not explicitly state that the tool is read-only or safe, though that is implied by the 'get' prefix. The description adds minimal behavioral information beyond the name and prerequisite.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and well-structured: a short title-colon-purpose, a prerequisite in parentheses, and type/default. Every sentence adds value and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description covers the essential aspects: purpose, prerequisite, and output type. It is almost complete, though it could be slightly improved by explicitly stating the tool returns the current value or that it is a read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameters to document. However, it provides valuable information about the return value: datatype INT16 and default 0. This goes beyond what the empty input schema offers and helps the agent understand the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as returning the pitch offset correction for speed TPA for wing/fixed-wing trim. It adds context beyond the tool name, such as the requirement for USE_WING, which helps differentiate it from other parameters. However, it does not explicitly state 'get' or 'retrieve', relying on the tool name, but the colon-separated format makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The only usage guidance is the prerequisite 'Requires: USE_WING', which is useful but does not provide any when-to-use or when-not-to-use instructions. There is no mention of alternatives or exclusions, which is a significant gap given the large number of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool retrieves a value but does not confirm it is read-only, lacks side effects, or describe output format beyond a type hint. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a type note, concise and front-loaded. Slightly more structure could improve readability, but it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description provides the return type, default, and primary use case (brushed motors). It is complete enough for an agent to understand the tool's value, though it could include the context of when the setting is relevant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds value by noting the return type (UINT8) and default (OFF), compensating for lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('use_unsynced_pwm'), and explains that it relates to sending motor PWM unsynchronised to the PID loop, primarily for brushed motors. This distinguishes it from sibling setters like 'set_use_unsynced_pwm'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It hints at motor type ('brushed motors') but no explicit when-to-use or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool smooths acc readings for attitude estimation, but does not disclose side effects like need for reboot, persistence, or safety mid-flight. Basic behavioral info is provided, but significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines the tool and its purpose, second provides parameter details. No wasted words, front-loaded with key info. Easily scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers basic function, range, and default. However, it lacks usage guidance and behavioral transparency. Given low complexity, it is minimally complete but with notable gaps in those areas.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the default value (25) not present in schema, and restates range/type. Purpose of parameter (cutoff frequency) is already clear from tool name and schema. Marginal added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the accelerometer low-pass filter cutoff, explains its effect (smooths acc readings for attitude estimation), and provides range and default. It distinguishes from siblings like set_acc_hardware or set_acc_calibration by focusing on the specific lpf_hz parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it adjusts accelerometer smoothing, but does not mention prerequisites, scenarios (e.g., tuning for noisy sensors), or exclusions. Among many set_* siblings, usage context is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the value range and default but does not explain the behavioral effect of setting this calibration value, such as whether it is persistent, requires a reboot, or impacts sensor readings. With no annotations, this leaves a significant gap in understanding the tool's impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with appended range/default info, concise and to the point with no unnecessary words. It is efficiently structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool and no output schema, the description covers the basic purpose and parameter constraints. However, it lacks details on persistent storage, reboot requirements, or safety implications, making it only moderately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides 100% coverage with min/max and description. The tool description adds the default value '0' and type 'UINT16', which adds some meaning beyond the schema. However, it largely repeats schema information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the ADC temperature sensor calibration value at 30°C, specifically for factory calibration. It distinguishes from siblings like set_adc_tempsensor_calibration110 by including the temperature point, and from other set_ tools by naming the specific calibration parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for factory calibration but does not explicitly state when to use this tool versus alternatives like set_adc_tempsensor_calibration110 or set_adc_vrefint_calibration. No guidance on prerequisites or context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It indicates a mutation (override) and notes the data type and default, but does not disclose persistence, immediate effect, or safety considerations. The description adds some context but is not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief with one functional sentence and a technical note, no redundancy, and front-loaded with the tool's purpose. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description provides the core effect but lacks information on return values, side effects, or when the change applies. Moderately complete for its scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds the data type (INT8) and default (DEFAULT), which is not in the schema description. However, it does not list valid values, enums, or format constraints. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'altitude data source', specifies the effect on 'autopilot and OSD altitude display', and distinguishes it from numerous sibling set_ tools by focusing on this specific parameter. The technical note adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_altitude_source or other set_ tools. Conditions, prerequisites, or contexts for overriding the altitude source are not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description indicates a write operation but does not disclose any side effects, prerequisites (e.g., connectivity), or persistence behavior (immediate vs. after reboot). Minimal disclosure beyond the action itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that conveys the essential purpose and constraint. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is mostly adequate but lacks information on what happens after setting (e.g., immediate effect, reboot required, return value). No output schema exists to clarify return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the default value (80) and the UINT8 type, which slightly enriches the parameter context beyond the schema's description, but does not fundamentally change the understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the specific resource ('angle_feedforward_smoothing_ms') with a concise explanation of its purpose ('Smoothing applied to angle feedforward signal'). It differentiates itself from the corresponding getter tool among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use or not use this tool. The nature of a setter is implied, and the existence of a getter sibling suggests usage pattern, but no direct alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a set operation that excludes altitude data. However, it does not disclose whether changes persist across reboots, require permissions, or have side effects on other blackbox settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise at 11 words, but it sacrifices clarity by not explaining the meaning of 'ON' vs 'OFF'. It could be more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean setting with no output schema, the description is minimally adequate. It lacks explanation of the effect when set to ON (presumably enables exclusion) and does not hint at any related parameters or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an enum of 'OFF' and 'ON'. The description adds 'default: OFF' but describes the parameter as 'UINT32' while the schema defines it as a string, creating a slight mismatch. No additional meaning beyond the schema is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Set' and clearly identifies the resource 'blackbox_disable_alt' with the outcome 'Exclude altitude data.' It distinguishes from sibling tools like set_blackbox_disable_acc by specifying 'altitude data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The context is implied: use this to exclude altitude data from blackbox logs. No alternatives are mentioned, but the tool's purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates a mutation ('Set') and mentions the data type and default, but fails to disclose whether the change persists across reboots, requires a reboot, or what side effects occur. The description is too brief to adequately inform the agent of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one short sentence plus a type hint. It is front-loaded with the purpose and contains no redundant information. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description covers the essential purpose. However, it lacks details on the exact effect of ON vs OFF, persistence, and any reboot requirement. For a complete picture, more context would be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a full enum description. The description adds valuable context: 'Exclude battery data' explains the parameter's effect, and '[UINT32, default: OFF]' provides the data type and default value, which is not in the schema. This adds meaningful information beyond the structured schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the blackbox_disable_bat parameter to exclude battery data from blackbox logging. The verb 'Set' and resource 'blackbox_disable_bat' are unambiguous, and the purpose is easily distinguishable from sibling tools like get_blackbox_disable_bat or other set_blackbox_disable_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention prerequisites, consequences, or contrast with the get counterpart. For a parameter-setting tool, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states 'Exclude GPS data' and gives default and type, but lacks details on persistence, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the verb and effect. Every word earns its place; no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one enum parameter, the description is sufficient to understand its role, but could mention the associated getter or clarify that USE_GPS is a prerequisite.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an enum. The description adds that setting to ON excludes GPS data and mentions default OFF, providing some meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'blackbox_disable_gps', specifying the effect 'Exclude GPS data'. Among many sibling set_blackbox_disable_* tools, it uniquely identifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a requirement 'USE_GPS', providing some context for when the tool can be used, but does not explicitly guide when to use it versus siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states the purpose and valid range, omitting critical details such as side effects, required permissions, or whether changes take effect immediately or require reboot. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with the range and default in brackets. It is front-loaded with the verb and resource, and every word adds value. No wasted or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with no output schema, the description covers the basic purpose and constraints. However, it lacks context on how this parameter fits into crash recovery overall, and the 'per profile' aspect is only mentioned in passing. Given the large number of sibling tools, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the only parameter is fully described with type, min, max, and description). The description adds the default value '100 (per profile)', which is not in the schema, providing marginal additional value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Set' and the resource 'crash_recovery_rate', with a clear explanation of what it controls ('rate at which the FC tries to recover from a crash'). It distinguishes from sibling tools like set_crash_recovery and set_crash_recovery_angle by focusing on the rate parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (setting a specific parameter) but provides no guidance on when to use this tool vs alternatives like set_crash_recovery or set_crash_recovery_angle. It does not state prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the FORCE option behavior and default state (OFF), but does not mention side effects, whether changes take effect immediately, or any safety implications. Some behavioral context is added beyond the schema, but gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief with two sentences plus a parenthetical note. It is front-loaded with the key purpose and includes essential details without unnecessary words. Could be slightly more structured, but it is concise and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers purpose, parameter semantics, and requirements. It does not explain return values or post-setting behavior, but for a configuration tool this is adequate. Missing some context like immediate effect persistence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'value' parameter has 100% schema coverage. The description adds meaning by explaining the UINT8 type, default OFF, and the special FORCE value that enables EDT when bidir is off. This provides useful context beyond the parameter's schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'dshot_edt', and explains its purpose as 'Extended DSHOT Telemetry — provides additional ESC data beyond RPM.' However, it does not explicitly distinguish this from its sibling 'get_dshot_edt' or other set tools, though the function is self-evident.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes requirements (`USE_DSHOT` + `USE_DSHOT_TELEMETRY`) and mentions the special FORCE value. It does not explicitly state when to use this tool versus alternatives, but the context of setting a configuration parameter is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions 'dynamic' and 'at idle throttle' but does not disclose effects on flight behavior, whether changes take effect immediately, or any side effects. The type and default are noted but partially redundant with schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a bracket note. It front-loads the parameter name and purpose, then adds value with context and defaults. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tuning parameter in a flight controller, the description provides the basic purpose, default, and a tuning hint. However, it lacks explanation of effect on flight, valid range (although schema has huge min/max, not practical), and interaction with other filters. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (one integer 'value'), but the description adds meaningful context: the value is a minimum cutoff frequency in Hz, relevant at idle throttle, with a tuning suggestion (AOS: 80 Hz) and default (75). This significantly aids interpretation beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and the specific parameter (dterm_lpf1_dyn_min_hz), with additional context that it's a dynamic D-term LPF1 minimum cutoff at idle throttle. It also provides a tuning recommendation and default value, making it highly distinguishable from sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool or when to avoid it. Among many similar set_dterm_lpf1_* siblings, the description does not differentiate usage scenarios or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only indicates it is a setter. It does not disclose side effects (e.g., flight dynamics impact), validation rules, or whether a reboot is required. The mismatch between the schema type (string) and the described type (UINT8) is confusing and undermines transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with inline details. It front-loads the action and provides the critical option comparison in a compact form. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the main purpose and available options. However, it lacks clarity on input format (string vs uint8) and does not mention any constraints or the existence of a corresponding getter. It is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema parameter description provides a basic label, but the tool description adds meaning by explaining the two options (BIQUAD/PT1) and the default. However, it does not explicitly list accepted string values, and the type mismatch (string vs UINT8) creates ambiguity. Schema coverage is 100%, baseline 3, and the description adds marginal value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: setting the type for D-term LPF1. It distinguishes from siblings by naming the specific parameter and explaining the two options (BIQUAD vs PT1) with their characteristics. It also includes the default value and data type hint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description identifies when to use the tool (to change the filter type) but does not explicitly guide on when to choose BIQUAD vs PT1 beyond the brief traits. No alternatives or exclusions are mentioned, but the tool's purpose is clear enough for a straightforward setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data type, range, and default value, but it does not mention any side effects, persistence behavior (e.g., immediate effect, need for reboot), or permission requirements. Since no annotations are provided, the description carries the full burden of transparency, and it fails to cover essential behavioral aspects for a mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with a bracketed specification. It front-loads the core action and resource, and every word adds value. There is no redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description covers the parameter semantics well. However, it lacks broader context: no return value indication, no hints about when to apply or what effects occur. With no output schema, the description should at least hint at success/failure behavior. Still, it meets the minimum for a basic tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds a default value ('default: 50') that is not present in the input schema's property description. It also clarifies the data type and range, which are already in the schema, so the added value is moderate but positive. Given 100% schema coverage, the baseline is 3, and the default value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the D gain of the dynamic idle RPM controller. It uses a specific verb ('Set'), names the parameter ('dyn_idle_d_gain'), and specifies its role ('D gain of the dynamic idle RPM controller'). This distinguishes it from sibling tools like set_dyn_idle_i_gain and set_dyn_idle_p_gain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It does not explain the context (e.g., tuning the derivative component of idle RPM control) or when not to use it. The agent must rely on the tool name to infer its purpose, which is insufficient for effective selection among many similar set_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only states the action and type. It does not disclose behavioral traits such as whether the change is immediate, persistent, or has any side effects. The description adds minimal value beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with embedded type, range, and default in brackets. Every word is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
As a simple setter with a well-defined parameter, the description is minimally adequate. However, it lacks context on the effect of the setting, any prerequisites, or confirmation of success. For a tool with no output schema, this additional context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already provides full coverage (100%) for the single parameter 'value' with description, type, and range. The description adds a default value ('default: 50') not present in the schema, which is useful for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and resource 'dyn_idle_i_gain', and explains its role as the 'I gain of the dynamic idle RPM controller'. It effectively distinguishes from sibling tools like set_dyn_idle_d_gain and set_dyn_idle_p_gain by specifying the gain type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 or any conditions. As a simple setter among many similar parameters, the lack of usage context leaves the agent uninformed about selection rationale.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the parameter type, range, and default value, but omits side effects (e.g., whether changes require a reboot) and prerequisites (e.g., must be connected to flight controller). Basic transparency is present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one clear sentence and a brief bracket notation. Every word is relevant and front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the parameter's meaning and constraints. However, it lacks any context about when or how to use it (e.g., after connecting to the FC, or if changes persist). Adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing baseline of 3. Description adds default value and repeats range, adding minimal extra meaning beyond the schema. Provides some additional context but not critical since schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the FPV camera tilt angle for tilt-compensated yaw mixing. It specifies the exact resource and action, and it is distinct from sibling tools like get_fpv_mix_degrees.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites, when not to use it, or scenarios where get_fpv_mix_degrees might be more appropriate. The usage is only implied by the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description gives the parameter range and default but fails to mention side effects like persistence, reboot requirements, or whether the change takes effect immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and includes the essential information in one sentence plus a bracket. The redundant repetition of the tool name is minor waste, but overall it is concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description covers the value range and context. However, it lacks information about how the setting is applied (e.g., immediate effect, requires save) which would be useful for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a proper description. The tool description adds context ('Descent rate when approaching home') that goes beyond the schema's technical specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the descendent rate during GPS rescue approach, but it starts with the tool name repeated, which is slightly redundant. It provides the type, range, and default, making the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs siblings. It implicitly suggests use during GPS rescue configuration, but does not mention alternatives like ascend rate or descent distance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects, required permissions, whether the change persists immediately or requires a reboot. It only states the default value and the meaning of PT1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a parenthetical. It front-loads the purpose and provides necessary details without waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the parameter meaning and default. However, it lacks behavioral context such as persistence or side effects, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single string parameter. The description adds semantic value by explaining what PT1 stands for and that it is the default, which is not present in the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the filter type for gyro LPF1, specifies PT1 as first-order with least delay, and mentions the data type and default value. It is easily distinguishable from sibling tools like set_gyro_lpf1_static_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It only defines PT1 but does not mention other possible values or conditions for choosing this filter type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool sets a parameter but omits behavioral traits such as persistence, side effects, or whether it requires a reboot. The type and default are given but not behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with a colon separator plus a note on effect and default. Every word earns its place. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a single parameter setter and no output schema, the description covers the essential aspects (purpose, effect, type, default). However, it lacks guidance on usage context and potential side effects, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: it explains that the parameter is the LPF period for displayed current, its effect on OSD smoothness, and its type and default. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: it sets the LPF period for the displayed current reading. The effect ('Higher = smoother OSD current display') is explained. It is differentiated from sibling tools like get_ibat_lpf_period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention when to increase or decrease the value, nor does it reference any prerequisites or related settings. The default value hint is provided but not the usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions rotation behavior and effect, but fails to clarify the actual parameter type (UINT8 vs string in schema), valid range, or side effects like need for reboot. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence followed by a contextual note and type/default hint. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description covers purpose and a use case. However, it misses important context about parameter values (range, format) and how it interacts with other I-term settings. The lack of output schema is noted but not compensated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds no additional meaning about the parameter beyond the schema's 'Value for iterm_rotation (UINT8)'. It does not explain what values are valid or how to format them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Rotates I-term vector with the aircraft during yaw to reduce cross-axis coupling.' This distinguishes it from other I-term-related tools like set_iterm_relax or set_iterm_windup. The note about 3D flying further clarifies its specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Primarily useful for 3D flying,' giving a hint about when to use. However, it does not explicitly state when not to use or contrast with alternatives like set_iterm_relax. More explicit guidance would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It mentions the default ('default: OFF') and the parameter type ('UINT8'), but does not disclose side effects, persistence, valid value range, or what happens on invalid input. Behavior is partially described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single line to convey the purpose, target audience, and parameter hint. It is front-loaded and every part adds value. No fluff or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple set command with one parameter and no output schema, the description adequately covers purpose and parameter default/type. However, missing information such as valid values, whether the parameter affects runtime or is persistent, and error states leaves gaps. Annotations are absent, so the description should be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter description, so baseline is 3. The description adds 'default: OFF' and notes the type ('UINT8'), which provides marginal extra context. However, it does not explain how to encode the value (e.g., 'ON'/'OFF' or numeric), and the schema declares the type as string while description says UINT8, causing potential confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Output MCO2 clock signal on PC9 pin (STM32 specific)'. It uses a specific verb ('Output') and resource ('MCO2 clock signal on PC9 pin'), and adds context ('Advanced hardware debugging only'), which distinguishes it from the sibling 'get_mco2_on_pc9' and other tool families.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates the tool is for 'Advanced hardware debugging only', which sets a context for use. However, it does not explicitly state when not to use it, nor mention alternatives like 'get_mco2_on_pc9' for reading the current state. The guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the core behavior (keeps PIDs active at idle) and notes default state, but lacks details on side effects, safety implications, or return value. With no annotations, more depth would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a bracket note. All information is front-loaded and necessary with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description is largely sufficient. It explains the function, dependency, and default. Missing explicit value range but acceptable given the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already documents the single parameter with a string type and description. The description adds value by specifying the data type (UINT8) and default (ON), which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the pid_at_min_throttle parameter, explaining it keeps PIDs active at idle and is required for airmode. However, it does not explicitly differentiate from other set_ tools among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates the setting is required for airmode and normally left ON, providing context for when to use it. Does not mention when to avoid it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It only mentions the value type and default, but does not disclose any side effects, persistence behavior, or prerequisites for setting this parameter (e.g., requiring a connected flight controller).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of one sentence plus a bracketed note. It is front-loaded with the essential purpose and type information, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple integer setter with one parameter and no output schema, the description is adequate. However, it could be improved by explicitly stating the allowed range (UINT8 implies 0-255) or any side effects. It meets the minimum viable standard.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds 'Pitch rate at stick center' and 'default: 7' beyond the schema description which only says 'Value for pitch_rc_rate (UINT8)'. This provides meaningful context for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'pitch_rc_rate' and specifies it is 'Pitch rate at stick center'. This verb+resource formulation is specific and distinguishes it from siblings like set_roll_rc_rate and set_yaw_rc_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives (e.g., set_roll_rc_rate), nor does it mention any prerequisites or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description mentions default value and type but does not disclose side effects (e.g., immediate effect, persistence, reboot required). Minimal behavioral guidance beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise; two lines with purpose, context, and default value. Front-loaded, no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter setter, but lacks context about effect timing (immediate/after reboot) and validation beyond schema. Could mention UINT8 range explicitly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds default value (47) and explanation of what 'p_pitch' means beyond the schema's parameter description. Schema coverage is 100% but default is extra.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets the pitch P gain, and adds context that pitch typically needs higher P than roll, distinguishing it from related tools like set_p_roll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives (e.g., set_i_pitch, set_d_pitch). Only a tuning hint, but no when-not or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It indicates this is a setter (mutation), mentions the default value (0), and that 0 enables auto mode. However, it does not describe any side effects, persistence behavior, or required permissions. As a simple parameter setter, the disclosure is minimal but not contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence but includes a redundant repetition of the tool name ('Set rc_smoothing_throttle_cutoff:'). It then provides the key information concisely. It could be more efficient by removing the re-statement, but it remains short and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description covers the essential semantics: it sets a throttle smoothing cutoff, with zero meaning auto. However, it lacks explanation of what the parameter does in practice or valid ranges beyond zero. It is adequate but not richly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameter with type integer and a brief label, but the description adds significant meaning: '0 = use auto' and the default value. This clarifies the special semantics of zero as a mode selector, which is not apparent from the schema alone. Schema coverage is 100%, but the description enhances understanding beyond the label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool sets the rc_smoothing_throttle_cutoff parameter, which is a manual throttle smoothing cutoff. It explicitly contrasts with '0 = use auto', distinguishing it from the automatic mode. Among siblings, it is one of many set_* tools, but the specific parameter name and description make its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint that a value of 0 means 'use auto', but does not explicitly explain when to use this tool versus alternatives like set_rc_smoothing or when a non-zero value is appropriate. It lacks explicit usage context or prerequisites, though the default value and auto mode hint are useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It discloses the data type (UINT16), valid range (0–1000), default value (10), and the prerequisite. However, it does not explain whether the change takes effect immediately, requires a reboot, or has side effects (e.g., can cause oscillations). For a simple parameter setter, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences and a parenthetical. Front-loaded with the action ('Set rpm_limit_i'). Every part earns its place: the purpose, the prerequisite, and the technical constraints (UINT16, range, default). No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers the essential context: what the parameter does, its type and limits, default, and a required feature flag. It does not explain the effect of changing the gain or how it interacts with other RPM limiter settings, but for a parameter setter in a configuration tool set, this is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter: value). The description adds meaning beyond the schema by explaining that the value is the I gain for the RPM limiter controller and specifying the default value (10). The schema only repeats the type and range. This clarifies the parameter's role and initial value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets the I gain for the RPM limiter controller, using a specific verb ('Set') and resource ('rpm_limit_i'). However, it does not distinguish this from sibling tools like set_rpm_limit_p or set_rpm_limit_d, which set other gain components for the same controller.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite (USE_RPM_LIMIT must be enabled) but provides no guidance on when to use this tool versus alternatives (e.g., other RPM limiter gains or the base set_rpm_limit). No context on typical scenarios or preferences.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool sets a value and gives the default, but does not disclose side effects (e.g., whether it affects arming, requires reboot, or has any constraints beyond the schema's integer range).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional info in brackets. It is extremely concise and front-loaded with the action and resource, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description adequately covers the parameter meaning and default. However, it lacks usage context, such as when to modify this setting relative to get_rx_max_usec or set_rx_min_usec. Overall, it is minimally viable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (only one param), so baseline is 3. The description adds meaning beyond the schema by explaining that the value is the 'longest channel pulse width considered valid' and providing the default (2115), which helps the agent understand the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set rx_max_usec: Longest channel pulse width considered valid.' It identifies the tool's action (set), the resource (rx_max_usec), and its meaning. This distinguishes it from siblings like set_rx_min_usec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of prerequisites, common scenarios, or typical values, which is especially lacking given the large number of sibling set_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It fails to mention whether changing the rate takes effect immediately, requires a reboot, or affects ongoing serial communication. The description is purely technical without operational context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence and a bracket note. It is front-loaded with the action and resource, and every word is informative without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema), the description is mostly complete. However, it lacks behavioral context such as whether the setting is applied dynamically or requires a restart, which would help the agent understand side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description repeats the range from the schema but adds the default value (100) which is absent from the schema, providing slight additional value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' on the resource 'serial_update_rate_hz' and explains it controls the rate of MSP/CLI serial output processing. This distinguishes it from the get_serial_update_rate_hz sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a valid range and default value, implying when to use the tool (to change the rate). However, it does not explicitly state when not to use it or mention alternatives like the getter or other rate-setting tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries full burden. It only states the action ('Set') without disclosing side effects, required permissions, or consequences of changing this value. The agent cannot anticipate whether this is a safe or destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one compact sentence plus a parenthetical note. It is front-loaded with the action and parameter name, followed by the semantic explanation and metadata. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers the parameter's meaning. However, it does not specify valid value format (e.g., numeric 0/1 vs. string 'ON'/'OFF') or mention any constraints. The '[UINT8, default: ON]' is ambiguous since UINT8 suggests numeric but default is given as 'ON'. This reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the schema says 'Value for simplified_dterm_filter (UINT8)'), but the description adds explanatory context: 'Whether simplified slider controls D-term filter cutoffs.' This clarifies the purpose of the parameter beyond the generic schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set simplified_dterm_filter') and explains what the parameter controls ('Whether simplified slider controls D-term filter cutoffs'). It includes metadata (UINT8, default: ON). Among the many sibling set_* tools, this one is uniquely identified by its specific parameter name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_simplified_d_gain or set_simplified_dterm_filter_multiplier. There is no context about prerequisites, typical workflow, or conditions under which this setting should be changed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It mentions type (UINT8) and default (100), and indicates it's an additional multiplier for pitch. However, it does not disclose immediate effects, whether a reboot is needed, or side effects on other parameters. Missing behavioral traits beyond what's minimally implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise (one sentence plus type/default note) and front-loaded with purpose. No wasted words, but could be better structured (e.g., separate behavioral effects). Still efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description is mostly complete: explains the parameter's role (additional PI multiplier for pitch, relative compensation). Lacks mention of its place in simplified PID tuning, but adequate for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (single parameter with basic description). The description adds significant context: 'Additional P and I multiplier for pitch only (relative compensation for pitch inertia)' and '[UINT8, default: 100]', enhancing understanding beyond the schema's generic 'Value for simplified_pitch_pi_gain (UINT8)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the 'simplified_pitch_pi_gain' and specifies it's an additional P and I multiplier for pitch only, relative compensation for pitch inertia. This distinctively identifies the resource and action among siblings like 'set_simplified_pi_gain' and 'set_simplified_pitch_d_gain'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., 'set_simplified_pi_gain' for general PI gain). No prerequisites, context, or conditions provided. The description implies it's for pitch-specific tuning but does not elaborate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility for behavioral disclosure. It states the data type and default value but does not describe side effects, persistence, or limits of operation (e.g., what happens if an out-of-range value is set). The prerequisite is noted but not elaborated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loading the purpose and following with essential notes in parentheses. No superfluous words; every sentence adds necessary context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description covers the key points: what it sets, the data type, default, and prerequisite. It could be more complete by hinting at effective ranges or consequences, but it is adequate for typical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a minimal description, but the tool description adds value by specifying the data type (UINT16), default value (0), and that it is per profile. This provides crucial context beyond the schema's generic range, guiding the agent to supply an appropriate unsigned 16-bit integer.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the 'setpoint width for pitch SPA attenuation ramp', specifying the exact parameter and its role. While it is distinguishable from siblings like set_spa_pitch_center, it does not explicitly differentiate itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires: USE_WING'), which provides important context for when the tool is applicable. However, it lacks guidance on when to use this tool versus alternatives (e.g., other SPA-related setters).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description mentions it's an INT8 with default 20 and its effect, but fails to disclose whether setting requires reboot, is persistent, or what happens on out-of-range values. The schema's min/max are unrealistically large, and the description does not clarify the actual permissible range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a technical note in brackets. Every word adds value, front-loading the action and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter without output schema, the description covers the purpose and effect adequately. Missing details like persistence or range enforcement are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by noting the type 'INT8' and default '20', which are not in the schema. This helps the agent know typical values, though the schema's range is misleading.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'tpa_low_rate' for D-term attenuation at minimum throttle to reduce shaking. It specifies the verb 'Set' and resource, but does not differentiate from similar TPA-related siblings like set_tpa_rate or set_tpa_breakpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when 'reducing D-term shaking during throttle chops' but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned despite many TPA-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It does not disclose whether changes are persistent, require a reboot, or affect other settings. It only provides the default value and unit interpretation, missing critical behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single informative sentence and a default note. Every piece of text adds value with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with a single integer param and no output schema, the description covers purpose, default, and unit. However, it lacks details on persistence, side effects, and usage context, which are relevant for a configuration tool. It is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a generic description for the parameter, but the description adds the default value (410) and unit interpretation (4.10V), clarifying the expected format. This goes beyond the schema by explaining the meaning of the integer value in volts.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'vbat_full_cell_voltage', defining it as the 'Full cell voltage for capacity display'. This distinguishes it from sibling set_* tools that target other parameters. The purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like set_vbat_max_cell_voltage or set_vbat_min_cell_voltage. The description does not mention context, prerequisites, or exclusions, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions reversing PID output sign but does not disclose persistence (if saved), need for reboot, or side effects. This is insufficient for a setting tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Concise and front-loaded. Could include more detail without being verbose, but structure is good.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set tool with one parameter, the description covers purpose and use case. However, it lacks behavioral details (persistence, reboot) and doesn't clarify parameter values. Output schema is absent, so no return info needed. Adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage but the parameter description is vague ('Value for yaw_motors_reversed (INT8)'). The tool description hints at accepted values via '[INT8, default: OFF]' but does not specify exact values (e.g., 0/1, ON/OFF). Adds minimal clarity beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Reverse yaw PID output sign' and provides a specific use case 'Use when motor spin direction is swapped from normal'. This distinguishes it from the getter sibling (get_yaw_motors_reversed) and other set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use it (when motor spin direction is swapped). However, it does not mention when not to use or provide alternatives. The context is clear but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavior. It only mentions the type (UINT8) and default value, but does not disclose side effects, persistence, or whether this affects the running configuration or saved settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise, single sentence with all essential information front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description is adequate. However, it could explain the concept of 'yaw rate at stick center' and how it relates to overall yaw responsiveness, especially for users unfamiliar with flight controller tuning.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds the default value and the context 'at stick center', which provides meaningful additional information beyond the schema's basic description of the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set'), the resource ('yaw_rc_rate'), and the specific meaning ('Yaw rate at stick center'). It distinguishes from sibling tools like set_yaw_srate and set_yaw_rate_limit by focusing on stick center rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_yaw_srate or set_yaw_rate_limit. No prerequisites or conditions for use are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation but does not explicitly state that it has no side effects. Since no annotations are present, the description carries the burden, but it provides minimal behavioral context beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, though the first sentence repeats the tool name. It efficiently communicates the core purpose and data type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose and data type but lacks detail on possible return values (e.g., whether it returns 0/1 or other values). For a simple getter with no output schema, more context on the expected value range would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100%, so the description does not need to add parameter semantics. The baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that it gets the acc_high_range setting, which enables high-range accelerometer mode for supported sensors. This distinguishes it from the setter sibling 'set_acc_high_range' and other accelerometer-related getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description does not differentiate from other getters or explain prerequisites, such as checking sensor support before reading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description only provides data type and range. It does not disclose any behavioral traits such as read-only nature, side effects, or preconditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one line with no wasted words. Purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description provides the essential info (type, range, default). Could explicitly state units (degrees) but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds meaning by specifying the return type (INT16) and range (-180–360) with default 0, which helps interpret the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the board rotation offset in pitch, distinguishing it from siblings like get_align_board_roll and get_align_board_yaw by specifying the axis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when pitch alignment info is needed). No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds value by specifying the unit (tenths of degrees), default value, and requirement, but does not disclose side effects, idempotency, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, containing only relevant information in a single sentence plus parenthetical notes. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the value's meaning, unit, default, requirement, and usage purpose. It could explicitly mention that it returns the current value, but the name implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description adds no parameter-specific information, which is acceptable. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the pitch trim offset in tenths of degrees for angle mode. It distinguishes from the related setter sibling via naming but does not explicitly compare or contrast with other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage context ('adjust the level hover point without reflying') and mentions a prerequisite (USE_WING), but does not specify when to use vs. alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states that the tool reads analog data, which implies a safe read operation, but it does not mention any potential side effects, permissions, or constraints. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that contains all necessary information without any filler. Every word earns its place, making it highly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no complexity, the description adequately conveys the tool's purpose and output. However, it could be slightly more complete by indicating the return format (e.g., object or array), but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema gives no information. The description adds value by specifying the exact analog data fields returned, which helps the agent understand what to expect. Baseline for zero parameters is 4, and the description meets it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves battery analog data and lists the specific measurements (voltage, mAh drawn, RSSI, current). This clearly distinguishes it from other battery-related getters like get_bat_capacity or get_battery_state, which retrieve different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. With many sibling tools for battery parameters (e.g., get_battery_continue, get_battery_meter, get_battery_state), the lack of contextual advice makes it harder for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by noting the data type (UINT32) and default (OFF). However, it does not explain what the returned value means (e.g., 0 includes debug, 1 excludes) or any side effects. It adds some insight beyond the empty schema but lacks full disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, front-loading the tool name and a brief explanation. Every phrase earns its place, though a clearer structure (e.g., separating explanation from type info) could improve readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should indicate what the return value represents. It mentions 'exclude debug fields' but not the format (e.g., boolean 0/1). For a simple getter among many similar siblings, this is a gap but not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description adds meaning by clarifying the tool's purpose and the setting it accesses. The schema provides no information, making the description essential.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a setting to 'exclude debug fields' from blackbox logging, which is a specific, distinct function among sibling tools like get_blackbox_disable_acc. It uses a verb 'Get' and a resource 'blackbox_disable_debug'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to exclude debug fields, or what the corresponding setter does). The agent receives no context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It discloses the setting type (UINT32) and default (OFF), which adds some value beyond the name. However, it does not describe the return value format (e.g., what values indicate include/exclude) or any side effects, leaving behavioral details incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, fitting the core purpose and key details (type, default, requirement) into a single sentence. It is front-loaded with the purpose. However, it could benefit from slight restructuring to separate the requirement and type info more clearly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should explain the return value semantics. It tells the type and default but not what the numeric values represent (e.g., 0=include, 1=exclude). This omission reduces completeness for an agent needing to interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is nothing to describe. Per the baseline rule for 0 parameters, a score of 4 is appropriate. The description does not need to add parameter info as there are none.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a setting to exclude GPS data from blackbox logs. It specifies the resource (blackbox_disable_gps) and action (get), distinguishing it from sibling tools that handle other data types like accelerometer or altitude.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (USE_GPS) but does not provide guidance on when to use this tool versus other get_blackbox_disable_* tools. No alternative tools or exclusion criteria are mentioned, leaving the agent to infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the return type (UINT8), range (0–100), and default value (10), which are useful for agent understanding. However, it does not explicitly state that the operation is read-only or has no side effects, though that may be inferred.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose, type, range, and default. It is front-loaded with the tool name and immediately provides the essential detail. There is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter getter with no parameters, the description adequately covers the needed information: what it returns (the alert threshold), the data type, the allowed range, and the default. No output schema is present, but the return value description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description does not need to add parameter information. It correctly omits param details, earning a baseline score of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool retrieves: 'Remaining capacity percentage to trigger a battery alert.' It adds context beyond the tool name 'cbat_alert_percent' by explaining the meaning of the value. However, it does not differentiate itself from other sibling 'get_' tools that also retrieve battery-related parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. There is no mention of context, prerequisites, or comparison to sibling tools like get_battery or get_use_cbat_alerts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It correctly implies a read operation but does not explicitly state that calling it is safe and has no side effects. The description adds some context (range, units) but lacks explicit behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of one sentence plus an inline specification. It front-loads the tool name. However, it repeats the tool name unnecessarily, and the inline spec could be integrated more naturally. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description does not explicitly state what is returned (presumably the current value). It provides range and default but could be more complete by indicating that the tool returns the current setting. For a simple getter, it is adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. The description adds meaningful context by explaining the meaning of the parameter value (rotation rate limit), units, range, and default. Since there are zero parameters, baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it retrieves the crashflip_rate parameter, which is a rotation rate limit during crash flip mode. It specifies units (degrees/s), valid range (0-250), and default value (0). This is specific and distinguishes it from other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as the related set_crashflip_rate tool. The description does not mention any prerequisites or typical usage context (e.g., getting before setting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavior beyond 'get'. It implies a read-only, safe operation but does not specify return format, range of indices, or potential side effects. It is adequate for a simple getter but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the action and target immediately. No unnecessary words or phrases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema, no annotations), the description is sufficiently complete. It states exactly what is retrieved. However, it could hint at the numerical nature or range of indices for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description adds no additional parameter meaning beyond the schema. Baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get') and the exact resource ('currently active PID profile index and rate profile index'). It distinguishes itself from sibling tools by focusing on the active profile indices, not individual settings or other values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like set_pid_profile or set_rate_profile. It does not clarify that this is the read-only counterpart for querying current profile indices, nor does it mention any prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. It discloses requirements (USE_DSHOT + USE_DSHOT_BITBANG) and type/default (UINT8, AUTO), providing useful context for availability and expected value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with one explanatory sentence and a separate note for requirements/type. No wasted words, though structure could be slightly improved.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides sufficient context: meaning, requirements, and value type. It is complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by specifying the setting's type and default, which helps the agent interpret the return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the dshot_bitbang setting, explains it as a DSHOT bitbang implementation, and notes the AUTO default. The specific naming distinguishes it from other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description only states what it does, not when it should be invoked or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavior. It notes compile-time requirements (USE_DSHOT + USE_DSHOT_BITBANG) and the return type. However, it does not explain what happens if requirements are unmet or describe any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence with a parenthetical requirement). It slightly redundantly repeats the tool name but is otherwise efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides the type and default but lacks broader context about when this timer value matters or how it relates to other settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds value by stating the output type and default, which helps interpret the returned value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the timer used for bitbang DSHOT, specifying the data type (UINT8) and default value (AUTO). It is distinct from sibling getters like 'get_dshot_bitbang' and the corresponding setter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With numerous sibling getters, the description does not help the agent decide to call this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses the data type (UINT8), valid range (0-90), and default (0), but does not disclose whether the operation is read-only, requires a connection, or has any side effects. For a simple parameter getter, this is minimal but acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very concise (one line) and includes essential information. However, it could be structured with clearer sections (e.g., value range) but is adequate for its simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is minimal. It covers the value semantics but lacks details on return format, prerequisites, or potential errors. For a zero-parameter tool, it is sufficient but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds type and range info beyond the empty schema, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves the FPV camera tilt angle for tilt-compensated yaw mixing, using a specific verb ('Get') and resource ('fpv_mix_degrees'). It distinguishes itself from numerous sibling 'get_*' tools by specifying the exact parameter and its context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is a parameter read, but does not state prerequisites or scenarios where this tool is preferred over other 'get_*' tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the transparency burden. It states it 'gets' a value but does not explicitly confirm it is read-only, nor does it disclose any side effects, permissions, or rate limits. The minimal description leaves behavioral traits unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two clauses) and front-loaded with the key information. Every word adds value: tool name, purpose, data type, and default value. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter retrieval tool with no parameters, the description is mostly complete. It explains the value type and default. However, it lacks context about return format or how the value is used, but given the tool's simplicity, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4 per instructions. The description adds value by specifying the output type (UINT16) and default (120), which aids interpretation of the result, even though no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the feed forward value for yaw (f_yaw). It uses specific verb 'Get' and resource 'f_yaw', which is distinct from siblings like get_f_roll or get_f_pitch. The inclusion of data type and default further clarifies the purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like get_f_roll, get_f_pitch, or set_f_yaw. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data type, range, default, and requirement, but does not mention if it is read-only, side effects, or board state dependencies. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise, front-loaded with key details. However, it does not explain the meaning of 'virtual current sensor voltage offset,' which might be unclear to some agents.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers type, range, default, and prerequisite. It is fairly complete, though return format is implied but not explicit.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (schema coverage 100%), but description adds value by specifying the value range and default, going beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets a specific parameter (virtual current sensor voltage offset) and includes range and requirement. However, among many sibling get_* tools, it does not differentiate itself (e.g., from get_ibata_offset or get_ibatv_scale).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a prerequisite (USE_VIRTUAL_CURRENT_METER) but no guidance on when to use this tool vs alternatives. No exclusions or context for selection among similar getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a read operation (Get) and specifies the type (UINT8), range (0–30), and default (5). However, it does not explicitly state that it is a read-only, non-destructive operation, though that is implied. The added context is helpful but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that includes the parameter name, its purpose, and the value constraints (type, range, default). It is concise and front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is complete. It conveys what the tool retrieves, why it exists, and the constraints on the returned value. No additional information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is trivially 100%. The description adds value by providing the range and default value, which are not present in the schema. This extra information helps the agent understand the expected output without needing to refer to other sources.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'pwr_on_arm_grace' setting and explains its purpose: it's a grace period after power-on that blocks arming to prevent arming before receiver binds. While it uses a specific verb and resource, it does not explicitly differentiate from the many other 'get_' sibling tools, but the explanation of the parameter's role makes the purpose clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as the sibling 'set_pwr_on_arm_grace'. It does not mention that to modify this setting, one should use the corresponding setter, nor does it explain typical scenarios for retrieving the grace period.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by specifying the data type (UINT8) and default (0), plus the meaning of 0. However, it does not mention any side effects or prerequisites, though for a simple read this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler, front-loaded with the verb and resource, and every part adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description fully covers what it does, the meaning of the value, and the format. No missing information given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, but the description explains the semantics of the returned value (manual cutoff, 0=auto), compensating for the lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'Manual throttle smoothing cutoff' value and explains that 0 means use auto. It distinguishes from sibling get_rc_smoothing_* tools by naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_rc_smoothing or set_rc_smoothing_throttle_cutoff. The description implies it is for reading the throttle cutoff, but lacks explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the requirement of USE_WING and the default value, which are helpful. However, it does not mention any other behavioral traits such as safety or side effects; since it is a getter, the implied read-only nature is acceptable but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three key pieces of information: purpose, requirement, and type/default. It is front-loaded and contains no extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the main aspects: what it retrieves, a prerequisite, and default value. It does not explain what the mode values represent or enumerate possible values, but for a basic configuration read, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters in the schema. The description adds value by specifying the type (UINT8) and default value (OFF per profile), which are not in the schema. This is sufficient for a parameterless getter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly indicates it's a getter for 'spa_pitch_mode' and specifies it relates to pitch. Among siblings like get_spa_roll_mode and get_spa_yaw_mode, it is distinct. However, the meaning of 'SPA mode' is not explained, which slightly reduces clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a requirement 'Requires: USE_WING', which provides context for when this tool is relevant. However, there is no explicit guidance on when to use this versus alternatives (e.g., get_spa_pitch_center) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It adds value by specifying the parameter type, range, and default, but does not explicitly state that it is a read-only operation or mention any side effects. The note on 'used by throttle_boost' provides some context, but behavioral transparency is moderate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—one sentence plus a bracketed specification. No wasted words. However, it could be slightly more structured with explicit labels for range and default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description provides the essential information about what is retrieved and its constraints. It does not explain the return format or how the value is used in a broader context, which would be helpful for a comprehensive understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description must provide all semantic meaning. It does so by explaining the parameter's purpose, type (UINT8), range (5–50), and default (15). Since schema coverage is 100% (no params), baseline is 3, but the description goes beyond by adding full context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'throttle_boost_cutoff' parameter, explains it as 'LPF cutoff for throttle derivative used by throttle_boost', and provides type, range, and default. This distinguishes it from hundreds of sibling get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among many get_* tools, there is no differentiation, leaving the agent to infer that it is for retrieving a specific parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose any behavioral traits beyond the fact that it retrieves a value. With no annotations, the agent cannot infer safety, side effects, or whether this is read-only (though implied by 'get'). It lacks details on error conditions or output format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded. It conveys the essential information in a single line with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides adequate context (type, default, purpose). However, it could be improved by explaining the return value format or range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds value by specifying the type (UINT8) and default value (10), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the vbat_divider, identifies it as a voltage divider ratio numerator, and specifies the type (UINT8) and default (10). This distinguishes it from related sibling tools like get_vbat_multiplier.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus other get_vbat_* tools. There is no mention of context, prerequisites, or exclusions, making it difficult for an agent to decide between siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behavioral traits (getter, triggers alarm, scaling, default) but with no annotations provided, the burden is partially met. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the tool's purpose, scaling, default, and data type. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description sufficiently explains the value's meaning, effect, and default. Complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the input schema, so baseline score of 4 applies. The description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the minimum cell voltage setting and explains its role (triggers battery-critical alarm) and scaling. However, it does not explicitly differentiate from sibling tools like get_vbat_warning_cell_voltage, leaving room for ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not indicate when to use this tool versus alternatives (e.g., set_vbat_min_cell_voltage for setting).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action and constraints (range, default). It does not disclose side effects, persistence, validation, or whether changes take effect immediately or require a reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line with no filler. Every piece (action, resource, prerequisite, type, range, default) is essential and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is fairly complete: it explains the purpose, value constraints, and a prerequisite. It lacks behavioral details but suffices for a basic parameter setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with 100% coverage (type, min, max, description). The description adds context (SPI bus number for barometer) and default value, but these add only marginal value over the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the SPI bus number for the barometer, using a specific verb (Set) and resource (baro_spi_device). It is distinct from sibling barometer-related set tools like set_baro_i2c_device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (Requires: USE_BARO), which helps decide when to use it, but gives no guidance on when to choose this tool over alternatives or what context is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions the type (UINT8) and default (OFF), but does not explain what values are valid (e.g., 0/1), whether this is a runtime or persistent setting, or any side effects like requiring a reboot. This is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with purpose upfront and supplementary info in parentheses. It avoids unnecessary words. A slight improvement would be to separate the type/default info more clearly, but overall it is well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter tool with no output schema and many similar siblings, the description is adequate but lacks critical details like valid value range, confirmation of effect, and whether it requires a reboot. The mention of 'hot-swap builds' adds context, but completeness is average.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, but the description adds context: the type and default. However, it does not clarify allowed values beyond 'UINT8' and 'default: OFF', leaving ambiguity (e.g., what numeric values correspond to OFF/ON?). The schema says type string but description says UINT8, which could cause confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'battery_continue', then explains the purpose: controlling logging/flying behavior after battery disconnect/reconnect for hot-swap builds. This distinguishes it from other set_* tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly mentions a prerequisite (USE_BATTERY_CONTINUE) and the use case (hot-swap builds), providing good guidance on when to use the tool. However, it does not describe when not to use it or compare with alternatives like get_battery_continue.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. While it mentions the default value and possible options, it does not disclose other behavioral traits such as whether the setting persists after reboot, if any validation occurs, or if there are side effects (e.g., impacting other measurements). The information is minimal for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (three short sentences plus a type/default note). It front-loads the purpose, then explains the two possible values, and ends with technical details. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter set tool, the description covers the purpose, allowed values, and default. It does not explain return values or confirmation, which is acceptable given no output schema. It could mention if setting requires reboot, but overall it sufficiently equips an agent to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the parameter as 'Value for battery_meter (UINT8)', which is generic. The description adds meaningful semantics by specifying the two allowed values ('ADC' and 'ESC') and the default. This goes beyond the schema and helps the agent understand valid inputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose with a specific verb ('Set') and resource ('battery_meter'), clearly indicating it is for setting the source of battery voltage reading. It distinguishes itself from siblings like set_current_meter by focusing on battery_meter and mentioning the two possible values (ADC and ESC).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., when to choose ADC vs ESC). It also does not mention when not to use it or any prerequisites. The sibling list contains many set_* tools, but no direct alternative context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only states the action without disclosing persistence, side effects, or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with an example, perfectly concise and front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description and schema together provide adequate context, though some behavioral details are missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description includes an example that matches the schema's example, adding no new meaning beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and the resource (RC channel map order), with an example that distinguishes it from the sibling get_channel_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided, but the purpose is self-evident as a setter for channel map configuration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It lacks details on side effects, persistence, immediate effect, or impact on system performance. It only states it 'controls scheduler behaviour', which is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with purpose stated upfront and extra information (requirement, range) appended. It is efficient but slightly cluttered by the inline range: could benefit from clearer separation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no annotations), the description covers the essentials: purpose, range, default, and requirement. However, it lacks explanation of what 'late tasks' are or when to modify this setting, making it adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a minimal description. The tool description adds meaningful context: the parameter is a 'CPU late task limit in permille', the range and default are provided, and the required compilation flag is noted. This adds value beyond the schema's repetition of the name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets cpu_late_limit_permille, a CPU late task limit in permille, and explains it controls scheduler behaviour when tasks are running late. This is a specific verb-resource pair that distinguishes it from its getter sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a required compilation flag (USE_LATE_TASK_STATISTICS) and the parameter range/default, but does not provide explicit guidance on when to use this tool versus alternatives or under what conditions to adjust the limit. Usage is implied but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only repeats the parameter's range and default from the schema. Missing details on persistence, required reboot, or any interaction with other crash detection parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that packs all essential information: purpose, parameter meaning, data type, range, and default. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the parameter meaning, range, and default adequately. However it could mention if changes take effect immediately or require a reboot to complete contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds semantic value: it explains the parameter's role (gyro rate threshold for crash detection), provides the unit (deg/s), and states the default value (400 per profile), which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets crash_gthreshold, the gyro rate threshold for crash detection. The description includes the unit (deg/s) and range, distinguishing it from numerous sibling set_ tools by specifying the exact parameter and its meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_crash_dthreshold or set_crash_delay. No context on prerequisites, such as whether the craft must be disarmed, or when this setting should be adjusted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must convey behavioral traits. It states the parameter and range but does not disclose side effects, whether changes require reboot, or constraints like dependency on crash recovery being enabled. Minimal behavioral insight beyond the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with additional info in brackets. It front-loads the action and key attributes. There is no unnecessary text, and every piece of information earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description covers the essential aspects: what it sets, units, range, and default. However, it lacks any broader context about crash recovery or when this parameter matters. Still adequate given the simplicity and presence of sibling tools for crash settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the single parameter. The description adds value beyond the schema by specifying units (deg/s), range (0–1000), and default value (200 per profile). This extra context helps the agent understand the parameter semantics more fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Set crash_limit_yaw' and explains its purpose: 'Yaw rate limit during crash recovery (deg/s).' It also includes units, range, and default value, making it clear what the tool does. Distinguishes from siblings by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Among many set_ tools, there is no mention of prerequisites, related settings, or whether to use the getter first. The description lacks context for optimal tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the effect (allows baud rate negotiation) and default value, but does not mention whether the change is immediate or requires a reboot, what happens if set incorrectly, or any side effects. For a flight controller parameter, such details are critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one sentence stating purpose, one sentence with usage context, and a bracketed type/default. No wasted words. Essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers purpose and usage scenario. However, it lacks explicit mention of acceptable values (0/1) and whether a reboot is needed. Given the context of many similar set_* tools, this is adequate but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides a generic description for the 'value' parameter. The description adds useful context: it clarifies the type (UINT8) and the default (OFF), which guides the agent on acceptable input format. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets 'crsf_use_negotiated_baud' to allow CRSF to negotiate baud rate. The verb 'Set' and resource name are explicit. However, it does not differentiate from other set_* tools beyond the parameter name, which is already clear from the tool name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a specific usage context: 'Enable when using faster CRSF rates (e.g. ELRS negotiated speed).' This tells the agent when to use this tool. It does not mention when not to use it or alternatives, but for a simple setter this is acceptable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral transparency. It mentions that the tool 'exposes internal signals in blackbox debug fields' but does not disclose side effects, persistence, or whether a reboot is required. Critical traits like immediacy of effect or potential impact on system behavior are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, containing a single, well-structured sentence that packs essential information. The enumeration of modes with brief parenthetical explanations is efficient. However, a bulleted list could improve readability slightly, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and annotations, the description should cover return behavior, persistence, and side effects. It explains the tool's action and parameter options but omits whether changes take effect immediately or require a reboot, leaving the agent with incomplete information for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes 'value' as a string with a generic description. The tool's description compensates by listing and explaining each key mode (e.g., 'FFT_FREQ (filter frequency analysis)'), adding significant semantic meaning beyond the schema alone. This helps an agent select appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set debug_mode: Select which internal signals are exposed in blackbox debug fields.' It identifies the specific resource (debug_mode) and the action (set), which distinguishes it from sibling tools like get_debug_mode and other set_* tools. The enumeration of key modes adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as get_debug_mode for reading or other set_* tools for different parameters. While the context implies use when changing debug mode, there is no guidance on prerequisites, frequency, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but only reveals that the tool sets a UINT8 value with a default. It does not disclose behavioral traits such as whether the change is persistent, requires a reboot, or has immediate side effects, leaving important behavior unclear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by bracketed extra info. It front-loads the purpose and includes essential details (type, default) without any superfluous words, earning every character.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no annotations or output schema, the description covers the essential purpose and parameter details. It could be improved by mentioning valid UBlox model values, but given the low complexity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the input schema by explaining that the parameter is the 'UBlox dynamic model used while acquiring fix' and noting the default value 'STATIONARY'. The schema merely labels it as 'Value for gps_ublox_acquire_model (UINT8)', so the description provides valuable context beyond the schema itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the UBlox dynamic model used while acquiring fix, distinguishing it from related siblings like set_gps_ublox_flight_model. It specifies the parameter type and default value, leaving no ambiguity about the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives (e.g., set_gps_ublox_flight_model) or any prerequisites. It only states what the tool does, leaving the agent to infer usage context without explicit when-to-use or when-not-to-use information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only says 'Set' without explaining whether this triggers recalibration, requires reboot, or is persistent. Minimal information beyond the set action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief and front-loaded, with essential details in one sentence plus a bracketed summary. It is efficient but could benefit from better structure (e.g., separate sentences for steps, range, and default).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter, the description covers the core aspects: purpose, units, range, and effect of value. However, it lacks details on persistence, immediate action, or interaction with other settings, which might be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers the value's type and range, but the description adds crucial context: unit (0.1s steps), mapping example, effect on accuracy, and default (125). This significantly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set gyro_calib_duration', specifying the verb and resource. It explains units (0.1s steps) and gives an example (125 = 12.5s), making it unambiguous. It distinguishes from siblings by naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It mentions 'Longer = more accurate offset measurement', hinting at when to use larger values, but does not explicitly state when to use shorter durations or alternatives like set_gyro_calib_noise_limit. No trade-offs or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It only states that the tool sets a parameter, but does not disclose side effects, persistence, or whether changes take effect immediately. The agent is left guessing about the impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose, the parameter's role, and its constraints. No redundant or extraneous information is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is largely complete. It explains the parameter's function and valid range. However, it lacks information about post-set behavior or any required system state (e.g., connection status), which would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already defines the parameter with 100% coverage, but the description adds significant semantic value by explaining the parameter's purpose ('maximum attitude angle before horizon mode enforces leveling') and providing range constraints ([UINT8, 10–250, default: 135]). This goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the 'horizon_limit_degrees' parameter, which is the maximum attitude angle before horizon mode enforces leveling. It distinguishes this from sibling getter tools (e.g., get_horizon_limit_degrees) and other setter tools by specifying the exact resource and its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention that to read the current value one should use get_horizon_limit_degrees, nor does it explain any prerequisites or context for setting this parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the operation (enable) and requirement (USE_I2C_DEVICE_2), but does not disclose side effects, whether it is destructive, permission requirements, or how it interacts with other settings. For a write operation, more context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single clear sentence plus parenthetical notes. Every piece of information is relevant and there is no redundancy or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setting tool with one parameter and no output schema, the description covers the core purpose, requirement, and data type. It lacks only deeper behavioral details, which are less critical for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds a bit of context (UINT8, default OFF) beyond the schema's 'Value for i2c2_pullup (UINT8)', but does not provide detailed semantics like valid range or format. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool's action: 'Enable internal pull-up resistors on I2C bus 2'. It specifies the target bus (I2C bus 2), distinguishing it from siblings for other buses. The requirement and data type are also noted, leaving no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to enable pull-ups on I2C bus 2, but does not explicitly state when not to use it or suggest alternatives. Sibling tools (set_i2c1_pullup, set_i2c3_pullup) exist, but no comparative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It identifies the tool as a setter (write operation), but fails to mention side effects, persistence, authorization requirements, or whether the change takes effect immediately or after reboot. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus bracketed metadata. It is front-loaded with the key action and resource, and every word serves a purpose. No unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a simple single-parameter setter and the schema fully defines the parameter, the description is fairly complete. However, it could mention that this is a flight controller parameter and that changes may be saved to flash, but the basic information is sufficient for a straightforward write command.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying units (millivolts) and default value, which are not in the schema description. This helps the agent understand the parameter's meaning beyond the raw constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'ibata_offset', and its meaning as 'ADC current sensor offset in millivolts'. It also provides range and default values, making the purpose unambiguous and distinct from other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives, nor are there any prerequisites, exclusions, or context about when setting this offset is appropriate. The description merely states what it does, leaving the agent without usage decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must disclose behavioral traits. It only states the setting action and the type/default, but omits side effects, persistence, whether changes take effect immediately or require reboot, or valid range despite mentioning UINT8.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no unnecessary words. The key information is front-loaded ('Set max_aux_channels') followed by the meaning and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the purpose, type, and default. It lacks explicit range validation but is otherwise sufficient. The absence of an output schema is acceptable for a setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is high (parameter has a description), but the description adds the default value (14) and the UINT8 type hint, which provides extra context beyond the schema. It could be improved by explicitly stating the valid range (0-255).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('max_aux_channels'), and explains what it controls ('Maximum number of AUX channels processed'). This is unambiguous and distinguishes it from its getter sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, such as the corresponding getter tool or other setter tools. There are no prerequisites, context, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only mentions the effect ('expose in ... debug fields') and a debug mode condition. It omits behavioral traits like persistence, validation, side effects, or whether changes require a reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two lines with no redundant words. The structure is straightforward: first line identifies the tool, second line provides purpose and type/default info. No wasted content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration tool with one parameter, the description misses critical details: the full set of valid axis values (e.g., ROLL, PITCH, YAW) and what happens on invalid input. Without an output schema, the description should be more self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by stating the default ('ROLL') and the debug mode context. However, it does not list all valid axis values, which would further clarify the parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'rc_smoothing_debug_axis', with specific context ('Which axis to expose in the RC smoothing debug fields'). It distinctively describes a configuration action, differentiating it from its 'get' sibling and other set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the context (set debug axis for RC smoothing), but there is no explicit guidance on when to use this tool versus alternatives, prerequisites, or conditions. The description does not exclude any scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states the purpose and default but does not mention side effects (e.g., if the change persists, requires reboot, or affects flight behavior). The description implies a write operation but lacks detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single noun phrase with parenthetical details. Every word is functional and front-loaded with the key information. No redundancy or unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers purpose, type, and default. It does not mention persistence or scope (e.g., per profile), but the 'ACTUAL system' hint suggests it affects the running system. Overall, sufficient but could add a note about when changes take effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by defining 'roll_srate' and specifying the default value (67) and data type (UINT8). The schema only labels it as 'Value for roll_srate', so the description adds significant context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'roll_srate', and explains what the parameter controls: 'Roll super rate — max rate at full stick deflection (ACTUAL system)'. This distinguishes it from sibling tools like set_pitch_srate or set_yaw_srate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention preconditions, recommended scenarios, or when not to use it. For a field-specific setter, this is a significant gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the parameter type, range, and default, but does not mention behavioral aspects like whether changes persist immediately or require a save/reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, covering purpose, prerequisite, data type, range, and default in a single line. No superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is nearly complete for a simple single-parameter setter, including the required feature flag and value constraints. It does not specify persistence behavior, but overall it provides sufficient context for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the parameter. The tool description adds the default value of 25, which is not in the schema, providing marginal extra value. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set rpm_limit_p: P gain for RPM limiter controller', identifying the verb and resource. While it implicitly differentiates from sibling tools like set_rpm_limit_i or set_rpm_limit_d by specifying 'P gain', it does not explicitly contrast with them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a prerequisite ('Requires: USE_RPM_LIMIT') indicating when the tool is applicable. However, it lacks explicit guidance on when not to use it or alternatives, such as suggesting set_rpm_limit_i for integral gain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. States basic function and default, but fails to disclose behavioral traits like persistence, reboot requirements, side effects on other settings, or safety implications. Lacks depth expected for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus note, 16 words. Front-loaded with action, zero wasted content. Extremely concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple (1 param, no output schema). Description covers purpose and parameter details adequately. Minor gap: missing valid values or range for the parameter. Otherwise complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. Description adds default 'OFF' and type UINT8, but schema already indicates type string with UINT8. Does not enhance meaning beyond schema, e.g., valid range or common values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'set' and resource 'serialrx_halfduplex', explains it enables single-wire half-duplex UART for serial RX, and gives context (some CRSF implementations). It effectively distinguishes from sibling tools like set_serialmsp_halfduplex and set_esc_sensor_halfduplex by specifying the exact purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage context via 'some CRSF implementations', but no explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or conditions for using this tool over other half-duplex settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the type (UINT8) and default (ON), and the behavioral effect (controls whether simplified slider governs gyro filter cutoffs). However, it omits side effects, whether changes persist, or if any special permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that includes the action, setting name, its function, type, and default. No extraneous information, and key details are at the beginning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description adequately explains the setting's role and default. It could be improved by specifying allowable values for the UINT8 (likely 0/1 or ON/OFF). However, it is largely complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter 'value' as a string and provides a description. The tool description adds the default value (ON) and hints at the boolean nature via 'Whether', but does not clarify valid string representations (e.g., 'ON'/'OFF', '1'/'0'). Since schema coverage is 100%, the description offers moderate added value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and the resource (simplified_gyro_filter), and explains its purpose: controlling whether simplified slider governs gyro filter cutoffs. It distinguishes itself from sibling get_simplified_gyro_filter and other set_simplified_* tools by specifying this exact setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like the getter or other set_* tools. It does not mention prerequisites, common scenarios, or situations where this tool should be avoided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description partially compensates by explaining the effect of raising the value (reduces filtering) and the baseline (100 = static). However, it does not disclose potential side effects, dependencies, or what 'faster' implies for flight behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no unnecessary words. It efficiently conveys purpose, behavior, and defaults in a single sentence. Information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema or annotations, the description provides adequate but minimal context. It explains the parameter's effect but does not cover prerequisites, safety considerations, or interaction with other settings. Given the complexity of the domain, more context would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides minimal parameter description; the description adds meaningful context: the value is a scaling slider, with 100 as baseline and raising reducing filtering. It also states the default (100). This adds value beyond the schema's UINT8 label.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose as 'Gyro filter cutoff scaling slider', which is a specific verb-resource pairing. It distinguishes from siblings like set_simplified_gyro_filter by focusing on the multiplier aspect. However, it does not explicitly differentiate from all similar set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides directional guidance ('100 = current static values. Raise to reduce gyro filtering (faster)') but lacks explicit when-to-use, when-not-to-use, or alternatives. Among many simplified_* siblings, no comparison is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states it 'sets' the value, without disclosing whether the change applies immediately, requires reboot, or how it affects the throttle response curve. This lacks detail for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no redundant information. Every word is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description is minimally complete. It clearly defines the action and parameter format. However, it does not mention relationship to get_thr_mid or other throttle settings, which slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds a default value of 50 and format '[UINT8, 0–100]', but these are already implied by the schema's min/max and description. No additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set thr_mid: Throttle curve mid-point — sets the thrust at 50% stick.' This is a specific verb+resource combination that distinguishes it from sibling tools like set_thr_expo or set_thr_hover.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description implies usage for adjusting the throttle curve midpoint, but does not discuss prerequisites, effects on flight behavior, or alternatives among the many set_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It adds the default value (30) and data type (UINT8), and notes the compile-time requirement. However, it does not disclose side effects, persistence, range bounds, or whether the change takes effect immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that conveys all essential information without extraneous words. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter mutation tool with no annotations or output schema, the description covers the purpose and parameter semantics but omits details like effective range (0-100 implied), behavior on invalid input, and clear differentiation from many sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes the parameter as 'Value for tpa_curve_stall_throttle (UINT8)', but the description adds meaningful context: it is a throttle percentage for stall detection. This significantly improves understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the throttle percentage below which the craft is considered stalled, specifically for wing/fixed-wing TPA. It distinguishes this from other TPA-related tools by specifying the stall threshold purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it is for wing/fixed-wing TPA and requires the USE_ADVANCED_TPA compile option, giving some context. However, it does not explicitly state when to use this tool versus alternative TPA curve tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It explains the parameter unit and default but fails to disclose behavioral traits such as persistence, immediacy of effect, or side effects. For a setter tool, such information is critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with additional details in brackets. Efficient but could be more structured (e.g., separate lines for unit, default, prerequisite). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers parameter meaning and a prerequisite, but does not explain the broader context of TPA speed models or how this value interacts with other settings. For a simple parameter setter among many similar tools, additional guidance would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond schema: explains that value is craft mass in g×0.1, specifies default (1000), and ties it to the advanced speed TPA model. Schema description merely says 'Value for tpa_speed_adv_mass (UINT16)' – description enriches it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set tpa_speed_adv_mass' and specifies it is craft mass (g×0.1) for the ADVANCED speed TPA physics model. Distinguishes from siblings like get_tpa_speed_adv_mass and other TPA-related tools by specifying the model variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite (Requires: USE_WING) but does not provide explicit guidance on when to use this tool versus other TPA settings or alternative models. With many sibling TPA tools, more context on selection criteria would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions calibration and a default value but fails to disclose potential effects, persistence, or prerequisites for this mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one short sentence plus inline notes) and front-loads the key information. However, it lacks structure, mixing purpose, instruction, and type info in a single line.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the calibration goal and default value but omits prerequisites, persistence, and any side effects. It is adequate for a simple parameter setter but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description is minimal ('Value for vbat_scale (UINT8)'). The tool description adds crucial context: the calibration process ('adjust until reported voltage matches a multimeter') and the default value (110), which aids correct parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets vbat_scale for voltage divider calibration, with a specific goal (adjust until multimeter matches). This distinguishes it from numerous sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for calibration but does not specify when to use versus alternatives like set_vbat_divider or set_vbat_multiplier. No explicit exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action ('Set') and defaults, but does not mention whether changes take effect immediately, require reboot, persist across power cycles, or any side effects. Critical behavioral transparency is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a short sentence containing all essential facts: action, parameter purpose, scaling, default. It is front-loaded with the tool name and purpose. Minor redundancy with the bracketed default repetition, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description covers the parameter semantics and default. However, it lacks behavioral details such as persistence, effect timing, or interaction with related settings like get_vbat_warning_cell_voltage. This is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the parameter minimally ('Value for vbat_warning_cell_voltage (UINT16)'). The description adds meaning: scaling factor (×0.01V), default value example (350 = 3.50V), and data type hint. This enriches the agent's understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a warning threshold voltage per cell, explains the scaling factor (×0.01V) and default value (350 = 3.50V). It unambiguously identifies the resource and action, distinguishing it from the corresponding getter tool in siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when to avoid it. It implies usage for adjusting the warning voltage but provides no context for prerequisites, alternatives, or typical scenarios. This is adequate for a straightforward parameter setter but lacks guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions connection via USB/serial but fails to disclose important behaviors: whether the connection is persistent, if it disconnects other sessions, timeout behavior, error states, or required permissions (e.g., serial device access). This is insufficient for a connection-oriented tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no filler. Every sentence adds value—the first defines the action, the second provides a prerequisite step. It is well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (connection tool), the description covers the basic action and a prerequisite but lacks information about return values (e.g., connection handle, status), expected side effects (e.g., if a previous connection is terminated), and error handling. With no output schema, more context on what to expect after connecting would be beneficial.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameters with decent descriptions (port with examples, baud_rate with default). The description does not add any additional meaning beyond what's in the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Connect'), the resource ('Betaflight flight controller'), and the medium ('over USB/serial'). It is specific and distinguishable from siblings like disconnect_flight_controller and reconnect_flight_controller, and it also mentions a prerequisite tool (list_serial_ports).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises to use list_serial_ports first to find the correct port, providing clear contextual guidance. However, it does not specify when not to use this tool or mention alternatives, such as reconnect_flight_controller if already connected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose side effects (e.g., does it close the serial port?), error handling for no connection, or whether it's safe to call multiple times.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words. Efficiently communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the basic purpose but lacks behavioral context (e.g., prerequisites, error states). Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline 4 applies as there are no parameters to document.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb (disconnect) and resource (flight controller), and among siblings like connect_flight_controller and reconnect_flight_controller, it distinguishes what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. While siblings imply a connection lifecycle, the description does not state prerequisites or scenarios for disconnecting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It correctly implies a read operation ('Get') and adds meaning about the value's effect. No mention of side effects or return structure, but adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no fluff. Front-loads the purpose and immediately provides the key parameter info in a structured format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately explains the parameter meaning and effect, but lacks usage context within the broader tuning workflow. No mention of the corresponding setter tool, though it is present in siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so description adds all meaning. It explains the value type (UINT16), range (10–5000), default (300), and unit (Hz×10), which is highly informative.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets the low-pass filter cutoff for altitude estimate, explains the trade-off between smoothness and lag, and distinguishes from other altitude-related getters like get_altitude and get_altitude_d_lpf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The context implies it's for reading a tuning parameter, but lacks direct advice for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the type and default but does not confirm that this is a read-only operation (implied by 'get' but not stated). No side effects, permission requirements, or response details are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three substantive phrases. It front-loads the core purpose ('Get blackbox_device: Logging destination') then lists value meanings. Could be slightly more structured (e.g., bullet points) but is efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description sufficiently explains the return value meanings and default. It does not need to explain return format as there is no output schema. It is complete for a straightforward getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need for parameter documentation. The description adds value by explaining the possible enum values and default, which helps interpret the return value. Baseline for 0 params is 4, and this is adequately handled.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the blackbox logging destination, explains the meaning of each possible value (SPIFLASH, SDCARD, SERIAL), and includes the type and default. This distinguishes it from sibling tools like get_blackbox_mode or get_blackbox_sample_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading the current device setting but provides no explicit guidance on when to use it versus alternatives. It does not mention that set_blackbox_device should be used to change the value, nor does it describe prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description explains the setting's effect (exclude attitude data) but does not disclose the tool's own behavior (e.g., returns current value, no side effects). Annotations absent, so minimal burden but adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, efficient sentence with appended type/default info. Slightly redundant by repeating tool name, but otherwise concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a param-less getter with no output schema, nearly complete. Informs type and default, but could explicitly state return value (current setting). Minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema. Description adds value by stating type (UINT32) and default (OFF), which is useful since schema is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the setting that excludes attitude data from blackbox logs. Distinguishes from siblings like get_blackbox_disable_acc by specifying 'attitude'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. other getter tools or the corresponding setter. Implied by context but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only states the action, no disclosure of side effects, prerequisites, or return behavior. Minimal transparency beyond the basic operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loads action and resource, no wasted words. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple no-parameter tool, but lacks description of return format or what the map consists of. No output schema to compensate, so slightly incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100% by default. Description adds value by explaining what the channel map represents ('order of AETR channels'), exceeding the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Get' and resource 'RC channel map', with parenthetical explanation 'order of AETR channels'. Distinct from siblings like set_channel_map and many other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage when needing channel map information, but no explicit guidance on when to use this vs alternatives or when not to use. No exclusions or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not mention that this is a read-only operation, what the return format is, or any side effects. The lack of annotations and minimal description leaves the agent underinformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracketed type/default. Every part serves a purpose: naming, functionality, usage context, and data type.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description mentions the return type and default but does not fully specify the output format (e.g., 'returns 0 or 1'). Given no output schema, this omission reduces completeness. It is adequate for a simple getter but not thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description does not need to explain parameter semantics. The baseline for zero-parameter tools is 4, and the description adds no parameter info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the 'crsf_use_negotiated_baud' setting, which configures CRSF baud rate negotiation. It distinguishes from sibling getters by specifying the exact parameter name and its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a hint about when the feature is relevant ('Enable when using faster CRSF rates'), but it does not explicitly state when to use this getter versus the setter, nor provides alternatives. The guidance is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only mentions the data type and default value. It does not disclose that the tool performs a read-only operation with no side effects, nor does it describe any potential permissions or safety considerations. The agent is left to infer behavior from the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional type and default info in brackets, making it highly concise and front-loaded with essential information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no output schema, the description provides the core purpose and type. However, it does not specify the return format or that it returns the current value. Given the high number of similar get_ siblings, a bit more context (e.g., 'returns current value as integer') would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the description adds value by specifying the type (UINT16) and default value (0), which goes beyond the empty schema. This helps the agent understand what the returned value represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the 'Static D-term notch bandwidth' value, distinguishing it from sibling tools like get_dterm_notch_hz which retrieves the notch frequency. The verb 'Get' combined with the resource 'dterm_notch_cutoff' makes the purpose explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like get_dterm_notch_hz or set_dterm_notch_cutoff. However, the naming convention and pattern of get_ tools implicitly indicate its usage for reading the configuration parameter, making it adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As a simple getter with no annotations, the description discloses the nature ('Static D-term notch centre frequency'), type (UINT16), and default (0). It does not mention side effects or permissions, but none are expected for a read operation. The description adequately conveys safety but could be more explicit about being read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using just two sentences with no filler. The purpose is front-loaded, followed by key details (disabled value, usage hint, type/default). Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the return value (centre frequency), type, default, and a usage context. The unit (Hz) is implied by the parameter name. Minor inference needed for exact format, but sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description adds no parameter info. However, it adds value by stating the return type and default in brackets '[UINT16, default: 0]', which compensates for the lack of an output schema. Schema coverage is 100%.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get dterm_notch_hz: Static D-term notch centre frequency', specifying the resource and value type. It also notes '0 = disabled' and 'Rarely needed when dynamic notch is active', providing context. The name itself distinguishes from siblings, but there is no explicit differentiation from other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it ('Rarely needed when dynamic notch is active'), suggesting preference for dynamic notch when active. However, it does not explicitly state when not to use it or name alternative tools like get_dyn_notch_* for comparison.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the meaning of the value and includes range/default information, but does not explicitly state read-only semantics or any side effects. However, given the tool is a parameter getter with no parameters, the behavioral transparency is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a bracketed note. It front-loads the tool's name and purpose, and every sentence adds useful information without redundancy. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, output schema, or annotations, the description covers the essential points: what the value represents, default, and effect of changing it. It could mention that the operation is read-only, but overall it is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage). The description adds value by specifying the value's range (200–1000) and default (600), which goes beyond the schema's empty definition. According to guidelines, with 0 parameters the baseline is 4, and the description provides extra meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get dyn_notch_max_hz' clearly indicating a read operation on a specific configuration parameter. The phrase 'Maximum frequency any notch will track' defines the resource precisely. The purpose is obvious and distinct from sibling tools like set_dyn_notch_max_hz, though not explicitly differentiated from other get_* notch tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about when adjusting this value might be beneficial ('Narrowing the range improves notch resolution'), but it does not explicitly state when to use this getter versus alternatives. For a simple read operation, the guidance is adequate but lacks explicit usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the tool is a read operation (get), the data type (UINT8), and default (OFF), but lacks details on side effects, rate limits, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parenthetical note, conveying purpose, protocol, compile requirement, type, and default efficiently without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter of a configuration parameter, the description covers the essential aspects: purpose, protocol, compile dependency, type, and default. No output schema is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, and schema coverage is 100%. The description adds context by explaining what the setting does, which is sufficient for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a setting for enabling half-duplex UART for ESC sensor telemetry, specifying the protocol and compile requirement. It distinguishes from other 'get_' tools, though not explicitly from the 'set_' variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a compile-time requirement (USE_ESC_SENSOR) but does not discuss when to use this setting versus alternatives or mention any prerequisites beyond the compile flag.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits (e.g., read-only, safe). The name suggests a read operation, but the description lacks explicit clarity on behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one informative sentence plus a data type annotation. Front-loads the name and explains purpose efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description covers purpose and parameter details (type, range, default). Missing return format or side effects, but adequate for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description need not add meaning beyond the schema. The data type hint [UINT8, 0–100, default: 15] adds value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the feedforward_yaw_hold_gain parameter and explains its function: sustaining residual FF signal in yaw after stick release. This distinguishes it from siblings like get_feedforward_yaw_hold_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the tool name and description (use to read the parameter value), but there is no explicit guidance on when to use this vs alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly disclose that this is a read-only operation or detail any side effects. It only states the parameter type and default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with a format annotation, front-loaded with purpose. Every word earns its place; no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter getter with no parameters and no output schema, the description provides all necessary context: purpose, meaning, type, default, and a usage recommendation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters exist, so schema coverage is 100% (baseline 3). The description adds value by explaining what the retrieved value represents, its type, default, and usage hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the static cutoff for LPF1, distinguishing it from numerous sibling get_* tools that retrieve other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting 'Set to 0 to disable (recommended with RPM filtering)', but does not explicitly state when to use this tool over alternatives or that it is a read-only operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the data type (INT16), valid range (-300 to 300), and default value (0), plus a prerequisite. It does not explicitly state it's read-only, but the 'get' prefix implies it. Minor gap but overall transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, containing the purpose, prerequisite, and value specification in a few lines. The repeated name prefix is slightly redundant but does not significantly harm conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a simple getter nature, the description covers the essential behavioral aspects: what it retrieves, the prerequisite, and the value characteristics. It could explicitly note it is a read operation, but the 'get' prefix suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. Baseline is 3. The description does not add parameter-specific value, but none is needed. The range info is about the return value, not input parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the magnetic declination correction for the user's location. It distinguishes itself from many sibling 'get_' tools by specifying its unique purpose, though the name repetition is minor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires: USE_MAG') but does not provide guidance on when to use this tool versus alternatives like set_mag_declination or get_mag_hardware. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits beyond being a getter. It omits details like what occurs if the prerequisite is unmet or if the tool has any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with every sentence providing essential information: purpose, prerequisite, and value characteristics. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the return value and prerequisite but does not explain the conceptual role of the I gain or provide broader context about the RPM limiter, leaving some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, but the description adds significant value by documenting the return value's data type (UINT16), range (0–1000), and default (10), which are beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the I gain for the RPM limiter controller, specifying the exact parameter and differentiating it from siblings like get_rpm_limit_d and get_rpm_limit_p.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires: USE_RPM_LIMIT'), which guides usage, but it lacks explicit when-to-use or when-not-to-use guidance compared to alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It explains that values below this trigger signal-loss detection, adding behavioral context beyond the name. However, it does not explicitly state it is a read-only operation or any other side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with key information, front-loaded with the name and purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless tool with no output schema, the description covers the return type (UINT16), default value (885), and behavioral impact. It is complete enough for an agent to understand usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%, so the baseline is 4. The description does not need to add parameter info as none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the shortest channel pulse width considered valid, with a signal-loss detection effect. While the sibling get_rx_max_usec exists, the description does not explicitly differentiate, but the name and context are sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a simple getter for the minimum pulse width. No explicit when-not or alternatives are provided, but for a parameterless tool, this is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It provides the data type, range, and default, and explains the parameter's function. However, it does not explicitly state that the tool is a read-only getter with no side effects, nor does it mention any required permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three sentences to convey purpose, range, and a usage example. No unnecessary words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description adequately covers the parameter's purpose, range, and a key usage (turtle mode). It could explicitly label it as a read operation, but overall it is complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so baseline is 4. The description adds value by explaining the meaning of the parameter (arming lock, turtle mode requirement) beyond the schema's empty property list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the small_angle parameter, a pre-arm safety lock. It explains the parameter's role and range. While it distinguishes the parameter from others, it does not explicitly differentiate this getter from sibling 'get_*' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the parameter is used for arming lock and mentions a specific use case (turtle mode requiring 180). However, it lacks guidance on when to use this getter vs. alternatives like set_small_angle or other getters, and does not state prerequisites or typical usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention that the operation is read-only, side-effect-free, or any other behavioral traits. The 'Get' verb hints at read-only, but explicit safety or idempotency info is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence listing key components without any waste. Every word adds value, and it is appropriately front-loaded with the verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should help the agent understand the return structure. It lists several data fields but not exhaustively. The tool likely returns a status object, but the description does not specify the format or additional fields. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description does not need to add parameter-level meaning. Baseline score for 0-parameter tools is 4, and no deduction is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb ('Get') and resource ('flight controller status') and lists key fields (cycle time, I2C errors, active sensors, mode flags, active profile). This distinguishes it from sibling getters that target individual parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The intended use as a general status overview is implied, but the description does not mention exclusions or comparative context with sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but description discloses it returns a list with timing statistics. Since it has no parameters and is read-only, this is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no extraneous words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, description adequately specifies the return type. However, it lacks detail on the format or fields of the list items.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters. Description adds value by clarifying the return content (list with timing statistics) beyond the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'list of scheduler tasks and their timing statistics'. It is specific but does not explicitly differentiate from sibling 'get_task_statistics', which could be confused.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like 'get_task_statistics'. The description omits context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses the parameter's effect (maximum tilt angle during flight) and constraints (UINT8, 10-80, default 60). Does not mention side effects, persistence, or prerequisites like disarm state. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus bracketed information. Directly states purpose and constraints with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple parameter setter among many siblings. Lacks information about when changes take effect (immediate? reboot?) and any prerequisites (disarmed state). No output schema but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (type, range, required). Description adds context: 'degrees', 'angle mode', 'flight-time', and default value. Provides meaning beyond bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets 'angle_limit' (maximum tilt angle in angle mode during flight) with unit, data type, range, and default. This distinguishes it from other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other angle-related settings (e.g., set_angle_p_gain, set_angle_feedforward). Context of 'angle mode' is implied but not contrasted with alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the default (AUTO) and the requirement (USE_BARO), but does not describe side effects, whether changes take effect immediately, or what happens with invalid values. The behavior of 'forcing a driver' is vaguely defined.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the purpose, prerequisite, and default. No unnecessary words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration setter, the description covers the basic purpose, prerequisite, and default. However, it lacks documentation of valid parameter values (beyond 'AUTO') and does not explain the return value or side effects. Given no output schema, the description should provide more context on expected input values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description for the 'value' parameter is minimal ('Value for baro_hardware (UINT8)'). The tool description adds the concept of 'AUTO' as default and the purpose, but does not enumerate valid driver names. There is a potential contradiction: schema says type string, description says UINT8. Baseline is 3 due to 100% schema coverage, but the added value is modest.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set baro_hardware') and the purpose: to force a barometer driver or use AUTO-detect. It distinguishes from sibling tools like set_baro_bustype by specifying it targets the hardware selection, not bus parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (requires USE_BARO) which helps decide when to use the tool. However, it does not explicitly contrast with other baro-related settings (e.g., set_baro_bustype, set_baro_i2c_address) or provide when-not-to-use guidance, leaving some ambiguity for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides data type and default value, but no annotations exist. Does not disclose side effects, persistence, or effect on other logging. Minimal behavioral info beyond the tool's basic effect.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence that immediately conveys the tool's action. No redundant information, front-loaded with essential purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description is adequate but could clarify the impact of disabling RSSI on logging behavior. Lacks completeness on operational context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with enum values. The description adds the default 'OFF' and underlying type 'UINT32', which enhances understanding beyond the schema. Only minor gap in explaining the value's meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'blackbox_disable_rssi' with the purpose 'Exclude RSSI data'. It is distinct from sibling tools which target other blackbox disable options.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus other blackbox disable settings. The description lacks context about typical use cases or prerequisites, leaving the agent to infer 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses type (UINT8), range (0–100), and default (10), which adds value beyond the schema. However, it does not state whether the change takes effect immediately, requires a reboot, or persists across power cycles. This is a moderate gap for a configuration setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence followed by a concise parenthetical with type, range, and default. Every word adds value, no redundancy. Fully front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description covers purpose, meaning, constraints, and default. However, it omits behavioral details like persistence (save to flash?) and does not mention related tools (e.g., set_use_cbat_alerts). These gaps reduce completeness in a flight controller context where such details matter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema describes the parameter simply as 'Value for cbat_alert_percent (UINT8, 0–100)'. The description adds meaningful context: 'Remaining capacity percentage to trigger a battery alert' and the default value of 10, which is not in the schema. This significantly enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the cbat_alert_percent parameter and explains it as 'Remaining capacity percentage to trigger a battery alert'. This verb+resource pairing is specific and distinguishes it from sibling tools like set_use_cbat_alerts (which enables the feature) and set_vbat_* (voltage thresholds).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives. For example, it does not mention that set_use_cbat_alerts must be enabled for this setting to take effect. The description is purely descriptive without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description does not disclose behavioral traits such as whether the change takes effect immediately, persists across reboots, or requires a restart. For a mutation tool with no annotations, this is insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that efficiently conveys purpose, constraints, and default. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with no output schema and no annotations, the description covers the basic purpose and constraints but lacks behavioral context (side effects, persistence, validation details). It is adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description of the parameter. The description adds meaningful context by explaining what crash_time represents ('Minimum crash duration before recovery triggers') and the default value, which goes beyond the schema's technical constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the 'crash_time' parameter and defines it as 'Minimum crash duration before recovery triggers.' It provides constraints (UINT16, 100–5000) and a default (500 per profile), making the purpose very specific and distinguishable from other crash-related sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adjusting crash recovery sensitivity but does not explicitly state when to use this tool versus alternatives like set_crash_delay or get_crash_time. There is no guidance on prerequisites or scenarios to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the filter is 'always static,' which is a behavioral trait, and gives the default value. However, it does not mention side effects (e.g., affects D-term filtering, flight behavior), permissions, or constraints beyond the schema's wide min/max.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracketed note with type and default. It front-loads the purpose and is free of unnecessary words. Every element serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema), the description is nearly complete. It explains what the parameter does and its role. However, adding context that this is a PID filter parameter affecting flight dynamics would improve completeness, but it is not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the parameter with 100% coverage, but the description adds value by explicitly stating the type as 'INT16' and providing the default value '150,' which is not present in the schema. This helps the agent understand expected range and typical value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the cutoff for D-term LPF2 and explains its purpose as a secondary anti-noise stage. It is distinct from siblings like set_dterm_lpf1_static_hz by naming the specific filter stage. However, it does not explicitly differentiate from set_dterm_lpf2_type or similar tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance: 'Use as a secondary anti-noise stage.' This implies when to use (for noise reduction), but no explicit prerequisites, exclusions, or comparisons to alternatives like set_dterm_lpf2_type are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the effect (half-duplex UART enable) and the default value (OFF), but lacks details on side effects (e.g., does it change other settings?), persistence, or error conditions if the requirement is unmet. With no annotations, the description carries the full burden but is only moderately transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the action, a note on the requirement, and a type/default spec. There is no fluff, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has a single parameter, no output schema, and no annotations, the description is adequate but incomplete. It does not mention whether the setting is persistent, requires a reboot, or returns any confirmation. The presence of a sibling getter (get_esc_sensor_halfduplex) suggests a readback pattern, but the setter description does not connect to it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema by specifying the default (OFF) and the data type (UINT8), but it does not clarify the valid range or mapping (e.g., 0/1 for OFF/ON). The schema's parameter description is minimal ('Value for esc_sensor_halfduplex (UINT8)'), so the description provides some additional context but not full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Enable half-duplex UART for ESC sensor') and the specific hardware context (BLHeli32/AM32 telemetry on a single wire). It differentiates itself from sibling set tools like set_esc_sensor_current_offset by explaining the unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description mentions a compile-time requirement (USE_ESC_SENSOR) and provides hardware context, it does not explicitly guide the agent on when to use this tool versus alternatives like get_esc_sensor_halfduplex or other set commands. The usage context is implied but not clearly delineated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the parameter's type, range, and default but does not mention side effects, prerequisites (e.g., connection state), or whether changes are immediately applied. Minimal transparency beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: one sentence expressing purpose followed by a compact technical spec. Every element (name, range, default, unit) is essential, and it is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is adequate for a simple setter but lacks broader context such as when it is safe to use, any dependencies, or whether it triggers a save/reboot. The tool is part of a large set of similar setters, so the description is standard but not exceptional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds value by clarifying the default value (60) and interpreting it as 6 seconds, which is not in the schema. This helps the agent understand the unit and typical setting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the duration of Landing Mode (AUTO-LAND) Stage 2. It includes the data type (UINT8), valid range (0-250), and default value (60 corresponding to 6 seconds). This specificity distinguishes it from sibling tools like set_failsafe_delay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for configuring failsafe landing behavior but does not explicitly state when to use this tool versus alternatives. No exclusions or contextual cues are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the effect of each value (motor cut, auto-land, GPS rescue) and notes the default. However, it does not mention side effects, persistence, validation, or whether a reboot is required. The behavioral detail is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, with the purpose front-loaded. It lists options in a structured way. Minor improvement could be using bullet points, but it remains efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter), the description is fairly complete. It explains the three options and their behaviors, and notes the default. However, it could mention that this is a persistent configuration setting and that changes take effect immediately or after a reboot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the parameter as 'Value for failsafe_procedure (UINT8)' with 100% coverage. The description adds significant meaning by listing the three valid string values (DROP, AUTO-LAND, GPS-RESCUE) and their behavioral implications, which goes beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'failsafe_procedure'. It explains three distinct options (DROP, AUTO-LAND, GPS-RESCUE) with brief behavior descriptions. The tool is clearly distinguished from its sibling 'get_failsafe_procedure' as the write counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives, such as which failsafe procedure to choose for specific scenarios. It also lacks prerequisites or indications of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the range, default, and special value behavior, but omits side effects (e.g., whether a reboot is needed, if values persist). This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence plus inline details). Every element—verb, resource, action, special value, type, range, default—is included without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description covers purpose, special value, and constraints. It could mention persistence or system effects, but overall it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the integer format, min, max. The description adds meaning by explaining that 0 enables auto-detection from `vbat_max_cell_voltage`, providing context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set force_battery_cell_count') and purpose ('Override auto cell-count detection'), using a specific verb and resource. However, it does not differentiate from related sibling tools like `set_vbat_max_cell_voltage`, which is referenced in the description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when manual override is needed and explains the special value 0, but it does not explicitly state when not to use this tool or mention alternatives (e.g., `set_vbat_max_cell_voltage`).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions the value type [UINT8] and default, but lacks details on persistence, side effects, or whether setting triggers immediate action. The phrase 'send to the GPS module on init' implies delayed effect but is vague.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a supplementary type/default note, immediately stating the action and constraint. Every word serves a purpose, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description is mostly adequate. It covers purpose and usage constraint, but lacks detail on value formatting or error conditions, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the schema already documents the parameter. The description adds a default indicator '[UINT8, default: —]' beyond the schema, though the default value is ambiguous. It does not clarify expected format (e.g., valid NMEA sentence), so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets custom NMEA sentences to send to the GPS module on initialization, explicitly limiting to NMEA provider only. This effectively distinguishes it from other set_gps_* sibling tools like set_gps_auto_baud.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies when to use (on init) and the provider restriction (NMEA only), providing clear context. However, it does not offer explicit exclusions or alternatives compared to other GPS configuration tools, so it misses full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the parameter meaning and range but does not mention effects on flight behavior, required features (e.g., GPS rescue enabled), or mutability characteristics. The description is minimal and lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose, then provides type, range, and default. Every word adds value, and there is no redundancy or verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the core purpose and valid values. However, it could mention the broader GPS rescue context (e.g., that this parameter only affects behavior when GPS rescue is active). It is mostly complete but lacks a hint about the feature dependency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the input schema: it explains that the parameter controls the distance from home at which descent begins, while the schema only says 'Value for gps_rescue_descent_dist'. The range and default are also included, providing complete semantic understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('gps_rescue_descent_dist'), and defines the parameter as 'Distance from home at which descent begins'. This precisely differentiates it from sibling set_* tools that target different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives (e.g., other GPS rescue parameter setters). The description provides no context about prerequisites, order of operations, or scenarios where this parameter should be adjusted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description is the sole source. It explains the parameter effect and values but does not disclose potential side effects, whether changes require reboot, or how this setting interacts with other filters. Basic behavioral context is provided but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a parenthetical note. It is front-loaded with the purpose and immediately provides key guidance. Every word serves a purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers purpose, valid values, and default. It does not discuss return values (acceptable for a setter) or verification steps. Given the simplicity and no output schema, it is nearly complete, though it could mention how to confirm the change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, baseline is 3. The description adds substantial value by listing valid values (NORMAL, OPTION_1, OPTION_2, EXPERIMENTAL) and explaining their significance and defaults. This enriches the schema's minimal description significantly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets the gyro hardware low-pass filter mode. It explains what the parameter controls and lists valid values. While it distinguishes from get_gyro_hardware_lpf, it could more explicitly differentiate from other gyro filter setters like set_gyro_lpf1_static_hz, but the mention of 'hardware' mode provides good context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises that NORMAL is correct for most builds and alternative options are only for supported sensors. This gives practical usage guidance but falls short of explicitly stating when not to use this tool or comparing it to software filter settings. No prerequisites or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the burden. It specifies the setting is a UINT8 range 0–10 with default 5, and explains the effect on rise speed. However, it does not disclose side effects (e.g., immediate application, persistence across reboots, impact on flight behavior). For a flight controller parameter, these are relevant but not critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two short sentences plus a clear metadata tag. No unnecessary words. Front-loaded with the purpose and effect.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with a corresponding getter and no output schema, the description covers range, default, and effect. It could mention that the value is stored persistently or that a reboot is not required, but given the tool's simplicity, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides 100% coverage with description, but description adds meaning: it explains the expo curve shaping concept and the effect of higher values. The inline metadata '[UINT8, 0–10, default: 5]' reinforces constraints. This goes beyond the schema's generic 'Value for...' line.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets the expo curve shaping for dynamic LPF1 cutoff vs throttle with 'higher = faster rise'. This distinguishes it from sibling tools like 'set_gyro_lpf1_dyn_max_hz' (frequency) or 'set_dterm_lpf1_dyn_expo' (for D-term). However, it does not explicitly differentiate from all other set_* tools, but the name and context are sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives like get_gyro_lpf1_dyn_expo for reading. The description implies it is for tuning gyro filter response, but does not mention when to avoid or prerequisites. It would benefit from mentioning that this should be used in conjunction with related gyro filter parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the parameter is a cutoff frequency, can be disabled, and has a default. However, it does not mention whether changes take effect immediately, require reboot, or persist across sessions. The range is implied as UINT16 but the schema allows huge integers, creating ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences totaling 25 words. Every sentence adds value—the first identifies the tool and parameter, the second gives usage guidance and the default. No fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema and no annotations, the description covers purpose, parameter meaning, a usage hint, and default. Missing are units (Hz) and explicit valid range (uint16), but the context from the name and schema partially address these. Overall fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a generic description 'Value for gyro_lpf1_static_hz (UINT16)'. The description adds significant meaning: it explains the value as a static cutoff, that 0 disables, and notes the default of 250. This goes beyond the schema, justifying a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the action (set) and the resource (gyro_lpf1_static_hz), explaining it as the static cutoff for LPF1. It adds specificity by noting the option to disable with 0 and recommending it with RPM filtering. While not explicitly contrasting with siblings like set_gyro_lpf1_dyn_expo, the naming and parameter make it distinguishable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage guideline: setting to 0 to disable, recommended with RPM filtering. However, it does not explain when to set non-zero values, typical ranges, or compare with alternative filters like LPF2 or notch filters. No explicit 'when to use this vs others'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It explains the parameter's effect but does not mention any side effects, persistence, whether changes take effect immediately, or if it is safe to modify during flight. This is a significant gap for a setter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a bracketed range/default note. Every word earns its place, and the key information is front-loaded. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers the parameter's purpose and effect. However, it lacks behavioral transparency (e.g., immediate or delayed effect, safety during operation), which is needed for full completeness. It also does not reference the get_imu_dcm_ki sibling for reading the current value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds valuable context beyond the schema: it explains that non-zero enables slow acc-based yaw correction and notes it is rarely changed. This helps the agent understand the functional impact of the parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets 'imu_dcm_ki' (the complementary filter integral gain) and explains its effect (allows slow acc-based yaw correction). This distinguishes it from other set tools like set_imu_dcm_kp or set_acc_calibration, even though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It notes 'Rarely changed,' implying infrequent use, and explains the condition for non-zero values. However, it does not provide explicit guidance on when to use this tool versus alternatives (e.g., set_imu_dcm_kp) or describe prerequisites or safety considerations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states a prerequisite (USE_MAG) and a default value (NONE). It does not disclose whether the change is non-destructive, requires a save/reboot, or what happens if the prerequisite is not met. This is insufficient for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with a clear starting point ('Set mag_hardware'), followed by an important detail ('NONE = disabled'), a prerequisite, and type/default. Every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setter tool with no output schema or annotations, the description is mostly adequate but incomplete. It fails to list possible values beyond 'NONE' and does not clarify whether the change persists or requires a save/reboot. Given the simplicity of the tool, these gaps are noticeable but not severe.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a description ('Value for mag_hardware (UINT8)'). The description adds significant meaning beyond the schema: it documents that 'NONE = disabled', specifies the default value, and notes the prerequisite. This helps the agent understand the parameter's purpose and valid usage, though it does not list all possible values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set mag_hardware: Magnetometer hardware selection' with a specific verb ('Set') and resource ('mag_hardware'). It explains the meaning of the value 'NONE = disabled', which distinguishes the tool from siblings like get_mag_hardware (which retrieves the current value) and calibrate_magnetometer (which performs calibration, not selection).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires: USE_MAG') but does not provide explicit guidance on when to use this tool versus alternatives like get_mag_hardware or set_mag_declination. The usage context is only implied through the tool name and the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states 'Hard cap on pitch rate' and the default, but omits behavioral details such as whether changes persist, require reboot, or have side effects on flight dynamics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the tool name and purpose, containing no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description is adequate but lacks context about the effect on flight controller behavior or units. It could mention that this limits the maximum pitch rate during flight.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage, providing a baseline of 3. The description adds value by specifying the type (UINT16) and default value (1998), clarifying the effective range beyond the schema's generic integer constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set pitch_rate_limit: Hard cap on pitch rate', which is a specific verb and resource, and distinguishes it from sibling tools like set_roll_rate_limit and set_yaw_rate_limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to set a hard cap on pitch rate, but provides no explicit guidance on when to use it versus alternatives or any exclusions. It is minimally adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context by noting the data type ('UINT8') and default value ('OFF'). However, it does not disclose potential side effects, persistence, or required permissions, leaving gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words: one sentence plus a brief note on type/default. It is front-loaded with the purpose and efficiently communicates the essential details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter without an output schema, the description explains the effect adequately but omits accepted values (e.g., OFF/ON or numeric range). It could be more complete by specifying valid inputs to the 'value' parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage for the single parameter but only a generic description. The tool description adds the default value and type ('UINT8'), which supplements the schema. This additional information improves parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Allow re-arm without toggling the prearm switch between flights.' It uses a specific verb ('Set') and resource ('prearm_allow_rearm'), and the effect is well-defined, distinguishing it from many similar set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. Among the many set_ tools, it does not mention when this setting should be enabled or disabled, nor does it reference related settings like stick arming or arming flags.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden. Explains effect and provides type/default, but does not disclose side effects, required permissions, or behavior for different values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence plus a type hint; every word is informative. No redundancy, front-loaded with key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Lacks expected range (0-255) or explicit mapping of values to enable/disable. No output schema, but for a simple setter this is acceptable yet not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds default value and purpose beyond the schema description, which only restates the type. Schema coverage is 100% but schema descriptions are minimal; description compensates partially.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets rc_smoothing to enable RC input interpolation and smoothing, with data type and default. Distinguishes from sibling set_* tools by specifying the resource and effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., set_rc_smoothing_auto_factor). Lacks context on prerequisites or scenarios where this setting is relevant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the type (INT8) and default (OFF) but does not mention side effects, persistence, validation, or return behavior. For a mutation tool, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parenthetical note, making it very concise. It is front-loaded with the purpose and usage context. However, it could benefit from better separation of sections for clarity, but it is not wasteful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description adequately covers purpose and usage context. No critical information is missing, though more behavioral details could improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the parameter description 'Value for rssi_src_frame_errors (INT8).' The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate. No extra details like allowed range or format are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a parameter to derive RSSI from frame error rate, and specifies the use case for receivers that do not report RSSI directly. This is a specific verb+resource combination that distinguishes it from sibling tools like get_rssi_src_frame_errors or other set_ commands.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'for receivers that do not report RSSI directly.' This tells the agent when to use this tool, implying an alternative is receivers that do report RSSI directly. However, it does not explicitly list alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It states the tool sets the protocol and gives a default ('CRSF'), but it fails to disclose potential side effects, whether a reboot is needed, or validation constraints. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a brief technical note. It is front-loaded and contains no extraneous words, making it quick to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description is minimally adequate. It conveys purpose and a constraint. However, it lacks details on valid values, error conditions, or relationship to related settings like get_serialrx_provider or set_serialrx_inverted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying the data type ('UINT8') and the default value ('CRSF'), which are not in the schema description. This aids the agent in understanding valid inputs beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'serialrx_provider', and specifies it's about 'Serial RX protocol'. It includes a distinguishing constraint: 'Must match the receiver's output format.' This is specific and differentiates it from other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a key usage guideline: 'Must match the receiver's output format.' However, it does not explicitly state when to use this tool versus alternatives (e.g., get_serialrx_provider) or mention any prerequisites or consequences of misuse.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It mentions the data type (UINT8) and default value (RPY), but omits critical details such as whether the setting persists across reboots, requires a restart, or has any side effects. This is insufficient for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that immediately state the action and provide essential context. Every word adds value, with the example and default packaged efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool, the description covers the core purpose and default value. However, it lacks a full list of valid axis values (e.g., R, P, Y, RPY, etc.) and does not explain behavioral consequences like immediate effect or persistence, leaving the agent with incomplete information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters but only labels 'value' as a UINT8 string. The description adds meaningful context by explaining that the parameter selects which axes the sliders control and provides the default 'RPY' as an example, significantly enhancing the agent's understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting simplified_pids_mode, which controls which axes the simplified PID sliders affect. It provides an example 'RPY = all axes', making the purpose unambiguous and distinct from numerous sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is used to configure PID slider axes but offers no explicit guidance on when to use this tool versus alternatives like set_pid_sliders. It does not specify prerequisites or exclusions, leaving the agent to infer context from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the value is UINT16 with a per-profile default, but it does not mention side effects, permanence, or any impact on flight behavior. More behavioral context is needed for a setter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a parenthetical note. It is front-loaded with the tool name and purpose, and every word adds value. No wasted language.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter, no annotations, and no output schema, the description is adequate but not rich. It explains what the tool does and the requirement, but does not explain what SPA is or how this setting affects the system. More context would be beneficial for agents unfamiliar with the domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one well-described parameter. The description adds value beyond the schema by noting the default value and that it is per-profile ('default: 0 (per profile)'). This is helpful context not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'spa_yaw_center' (setpoint centre value for yaw SPA). It distinguishes itself from the sibling tool 'get_spa_yaw_center' and other set_ tools by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a requirement condition: 'Requires: USE_WING'. This gives some guidance on when the tool can be used, but it does not explicitly state when to use this tool vs. alternatives (e.g., other spa_ setters) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that profiling is visible via a CLI command and that turning off reduces overhead. However, it does not state immediate vs persistent effects, required permissions, or side effects beyond overhead.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a bracketed note, no fluff. Purpose and key info are front-loaded. Every sentence contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle with one parameter and no output schema, the description provides purpose, default, and usage hint. However, it lacks information on value format, whether changes take effect immediately, or if a reboot is needed. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter 'value' is described as 'Value for task_statistics (INT8)', covering 100%. The tool description adds default 'ON' and type hint 'INT8', but does not clarify acceptable values (e.g., 0/1, ON/OFF). Baseline 3, slight improvement but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool enables CPU task profiling visible via the `tasks` CLI command, using the verb 'Set' and specifying the resource 'task_statistics'. It distinguishes itself among many set_* siblings by describing its specific function and output visibility.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a usage guideline: 'Turn OFF to reduce overhead on heavily loaded systems.' This advises when to disable, but does not mention when to enable (default ON) or compare with alternatives like get_task_statistics for retrieval. No when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only repeats schema information (type, range, default) without disclosing any behavioral traits such as whether the change is persistent, requires reboot, or affects other settings. The agent learns nothing beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise at two sentences, front-loading the purpose and parameter constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter set tool with one parameter, the description is minimally sufficient. However, it does not explain what throttle expo does or its impact on flight behavior, leaving the agent to infer from context. Could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds 'Throttle expo' which explains the meaning of the parameter, and includes the type, range, and default value, going beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set thr_expo: Throttle expo.' It specifies the verb ('Set'), the resource ('thr_expo'), and provides the parameter type, range, and default value in brackets. This distinguishes it from siblings like set_thr_hover or set_thr_mid.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, the description implies it is used to configure throttle expo, and given the naming convention among siblings, usage is implicitly clear. Lacks prerequisites or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must convey behavioral traits. It explains how the expo value affects attenuation (negative for low throttle, positive for high throttle) and gives the default value. However, it does not state whether changes take effect immediately, require a reboot, or if there are any side effects. For a simple parameter setter, this is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two clear sentences plus a prerequisite note and a type/default hint. It is well-structured, with the most important information (what it does and effect) first. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that sets a single integer parameter, the description provides complete context: the parameter's role, its range behavior, the required feature, and the default value. There is no output schema, but none is needed for a setter. All necessary information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes the parameter as 'Value for tpa_curve_expo (INT8)'. The description adds meaningful semantics: the effect of negative vs. positive values, the default of 20, and the range implications. This goes well beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as setting the tpa_curve_expo parameter and explains its effect on throttle-based attenuation. It is specific about the resource (TPA curve) and the action (setting the expo). However, it does not differentiate from sibling TPA-related set tools like set_tpa_rate or set_tpa_curve_type, which have similar scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite `USE_ADVANCED_TPA` feature, which provides a basic usage constraint. However, it lacks guidance on when to use this tool versus other TPA curve adjustments, such as set_tpa_breakpoint or set_tpa_curve_type. No alternative tools or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states that the tool sets a value, with no mention of side effects (e.g., immediate vs. post-reboot application), persistence, or constraints beyond the prerequisite. For a mutation tool, this is minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a prerequisite note and a type/default hint appended. It is front-loaded, efficient, and every part serves a purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers purpose, default, unit, and a prerequisite. However, it lacks behavioral context (immediate effect vs. reboot, persistence) and does not leverage the absence of annotations to provide richer detail. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100% (only one parameter, described as 'Value for tpa_curve_pid_thr0 (UINT16)'). The description adds significant meaning: unit (×0.1%), purpose (PID at zero throttle), and default interpretation (200 = 20%). This exceeds the schema's minimal text, earning above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (Set) and resource (tpa_curve_pid_thr0), explains the meaning (PID value at zero throttle for TPA curve), provides the default (200 = 20% of full PID), and the unit (×0.1%). This clearly defines what the tool does and distinguishes it from many sibling TPA-curve tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (`USE_ADVANCED_TPA`), giving context for when the tool is available. However, it does not explicitly state when to use this tool versus alternatives (e.g., set_tpa_curve_pid_thr100), nor when not to use it. Guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It claims the value is UINT16, but the input schema allows integers from -9e15 to 9e15, contradicting the description. This is a serious inconsistency. Additionally, no side effects, validation behavior, or persistence details are disclosed. The contradiction lowers the score to 1.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a requirement note and type/default in brackets. It is front-loaded with the action and resource, and every element (name, unit, requirement, default) is essential. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description provides the unit, default, and prerequisite. However, the annotation contradiction undermines completeness, and there is no explanation of typical values or the parameter's impact on flight behavior. Adequate but with clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter). The description adds the unit (mm), default value (370), and data type hint (UINT16) beyond the schema's minimal description. This provides meaningful additional context, earning a score above the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('tpa_speed_adv_prop_pitch: Propeller pitch (mm) for ADVANCED speed TPA physics model'). The unit (mm) and default (370) are provided. This distinguishes it from sibling tools like set_tpa_speed_adv_drag_k or set_tpa_speed_adv_mass which configure different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite: 'Requires: USE_WING'. This tells the agent when the tool is applicable. However, it does not specify when not to use it or suggest alternatives among the many TPA-related siblings. The guidance is helpful but incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the burden. It states it gets 'text output', implying a read operation, but does not explicitly state that it is non-destructive or read-only. The lack of detailed behavioral context keeps this at a mid score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence of 12 words, completely concise with no redundancy. It front-loads the action and resource efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description mentions 'status text output', hinting at the return type. It is mostly complete for a parameterless read tool, though it could elaborate on output format. Still, it is sufficient for the agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the schema coverage is 100%. The description adds no parameter information, which is fine since there are none. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource 'flight controller status text output' from the 'CLI status command'. It distinguishes itself from siblings like get_status and other CLI tools by explicitly mentioning the source command.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving CLI status text but does not explicitly differentiate from alternatives like get_status or cli_exec. No when-not-to-use guidance is provided, making it merely adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the offsets are written by the calibration routine and should not be manually edited, which is useful context for a getter. However, it does not state return structure or conditions under which values differ from defaults, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no filler. The front-loaded format immediately identifies the tool and its purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a zero-parameter getter with no output schema, the description provides the key facts: what is fetched, where it comes from, and default format. It lacks explicit mention of the return type (array of INT16) but implies it. Nearly complete for a trivial tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema description coverage, the description need not add parameter info. The baseline of 3 applies, and the description includes a note on the return format ('[INT16, default: 0,0,0,0]'), which is marginally helpful but not required for parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves raw accelerometer calibration offsets, contrasting with sibling tools like set_acc_calibration and calibrate_accelerometer. The verb 'Get' and resource 'acc_calibration' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Do not edit manually' implies read-only usage, but no explicit guidance on when to use or alternatives is provided. With many sibling getters and setters, the description could more clearly indicate this is for reading calibration offsets and that calibration should be done via calibrate_accelerometer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It implies a read-only operation ('Get') but does not explicitly state that it returns the current value without side effects. The type, range, and default info add some behavioral context, but it could be more explicit about return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with no superfluous information. It efficiently conveys tool purpose, value semantics, and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters or output schema, the description covers the essential aspects: purpose, value type, range, and default. It could be improved by linking to calibration flow or mentioning that this is a read-only query for a specific trim setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters, so coverage is 100%. The description adds meaningful context about the parameter data type (INT16), valid range (-300 to 300), and default (0), which goes beyond the empty schema and helps the agent understand the value semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the accelerometer roll trim for level calibration, explicitly naming the resource (roll trim) and distinguishing from sibling 'get_acc_trim_pitch'. The inclusion of data type, range, and default value provides complete clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives such as 'set_acc_trim_roll' or 'calibrate_accelerometer'. No conditions or exclusions are mentioned, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates the tool retrieves a factory calibration value, implying a read-only operation. However, no annotations exist to confirm safety, and the description does not explicitly state behavioral traits like idempotency or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes the action, resource, and key value details. It is front-loaded and contains no extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description covers the essential information (what it gets and the value range). It could mention the purpose of the calibration value in broader context, but completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (0 params), so the baseline is 4. The description adds value by specifying the return type (UINT16) and range (0–2000) with a default of 0, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'adc_vrefint_calibration'. It explains that it retrieves the factory calibration value for the ADC internal voltage reference, distinguishing it from other getter tools by specific name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While there is a sibling setter tool (set_adc_vrefint_calibration), the description does not mention it or provide context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only gives data type and default value, but does not disclose read-only nature or other behavioral traits like side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loads the purpose, and includes only essential information without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description adequately covers what is retrieved, the data type, default, and a prerequisite, making it sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero parameters, so the description's mention of return type (UINT8) and default value (DEFAULT) adds meaningful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the magnetometer orientation, and the sibling set includes 'set_align_mag' for setting, confirming distinct purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (Requires: USE_MAG) and implies usage for reading magnetometer orientation, but lacks explicit when-to-use or when-not-to-use guidance compared to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses the source (barometer) and units, but does not mention real-time behavior, data freshness, or any side effects. For a read-only sensor read, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence of 12 words. Every word adds value: 'Get current altitude (meters) and variometer (cm/s) from the barometer.' There is no wasted text or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema. The description specifies units (meters, cm/s) but does not indicate the return format (e.g., object fields, data type). It also lacks information about error conditions or edge cases. Given the absence of an output schema, the description should provide more structural context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% schema coverage), so the description logically adds no parameter information. With 0 parameters, the baseline for this dimension is 4, as the description has no need to elaborate on parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), clearly states the resource ('current altitude (meters) and variometer (cm/s)'), and identifies the source ('from the barometer'). This uniquely identifies the tool among many get_* siblings, as it specifically targets altitude and variometer data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. However, the tool is simple and its purpose is obvious: call it to obtain current altitude and variometer readings. The lack of alternatives mentioned is acceptable given the tool's straightforward nature, but it stays at an implied usage level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds value by disclosing the return type (UINT8), range (0-5), and default (2). It also notes the requirement. This covers key behavioral aspects for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loads the purpose, and packs type/range/default inline. Every word earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description covers the essential: purpose, prerequisite, and return constraints. It is complete for simple retrieval, though it could hint at how the bus number maps to hardware.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds no parameter-specific information, but the baseline of 3 is appropriate since nothing is missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the SPI bus number for the barometer. It is specific and uses a verb+resource format. However, among siblings like get_baro_i2c_device, it could more explicitly differentiate itself as the SPI variant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite note (requires USE_BARO), providing some guidance. However, it does not advise when to use this tool versus alternatives (e.g., get_baro_i2c_device) or mention any conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It states the return type (UINT32) and default value (OFF), which provides some transparency about the setting's nature. However, it does not explicitly declare the tool as read-only or describe any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with a single line that includes the tool name, purpose, and type/default info. No unnecessary words, perfectly front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple getter with no parameters and no output schema, the description provides essential information about the return type and default. While it could clarify what 'OFF' means numerically, it is sufficiently complete for this straightforward tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema (0 params, 100% coverage). The description adds value by specifying the type and default of the setting (UINT32, default: OFF), which goes beyond the schema and helps an agent understand the expected value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Exclude filtered gyro data' clearly states the tool retrieves a setting that excludes filtered gyro data. Among many get_blackbox_disable_* siblings, it is specifically for gyro, distinguishing it effectively.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives, such as other get_blackbox_disable_* tools. There is no mention of context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation via 'Get', but does not explicitly state it is read-only or safe. With no annotations, the description carries the full burden, yet it omits details like side effects or permissions. However, for a simple getter with no parameters, the implication is sufficient, earning a mid-range score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracketed type/default. Every word serves a purpose, and the structure is clear. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides the data type and default value ('[UINT32, default: OFF]'), which helps an agent understand the return format. It also identifies the specific setting (motor output data). However, it does not explain that the tool returns the current state of that setting, nor does it differentiate the return format from siblings. This is adequate for a simple getter but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the baseline is 4. The description adds no parameter information because none exist, but the schema coverage is 100% (empty). The mention of data type and default in brackets provides some value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'blackbox_disable_motors' setting, which controls exclusion of motor output data. The verb 'Get' and the specific resource 'motor output data' differentiate it from sibling 'get_blackbox_disable_*' tools that exclude other data types.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. For example, it does not mention that it should be used to check the current setting before modifying it with the corresponding 'set_blackbox_disable_motors' tool, nor does it contrast with other blackbox disable getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies read-only operation but does not explicitly state idempotency or side effects. Adds data type and range but lacks disclosure of connection requirements or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, includes essential technical details without waste. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, description is sufficient: defines the parameter, its type, range, and default. Lacks broader context (e.g., profile dependency) but adequate for simple retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100% (empty). Description adds value by specifying data type (UINT8), range (50–255), and default (100), which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the crash_recovery_rate, defines it as 'Rate at which the FC tries to recover from a crash', and provides data type, range, and default. This distinguishes it from many sibling get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention any context, prerequisites, or related tools (e.g., set_crash_recovery_rate).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the type, range, and default, which adds value. However, it does not explicitly state it is read-only, lacks side effects, or mention any access requirements. 'Get' implies reading, but full transparency is not achieved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loaded with the purpose, and efficiently includes technical details in brackets. No redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description provides essential information: what it retrieves and the expected value constraints. It could further explain the role of the threshold in crash detection, but is largely sufficient for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description does not add parameter meaning because none exist. The type/range info pertains to the return value rather than parameters; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the crash setpoint threshold, including its data type (UINT16), range (50–2000), and default (350). This specific resource name distinguishes it from hundreds of sibling getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when the crash setpoint threshold is needed, but does not explicitly state when to use or not use this tool vs. alternatives. For a parameter-specific getter, the context is straightforward, but no guidance on selection among siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a 'get' operation (read-only) but does not disclose any side effects, destructive potential, rate limits, or authentication requirements. The description lacks behavioral context beyond the operation type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: the first clearly states purpose and return fields, the second provides a usage note. No redundant information. Front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description provides reasonable context: what it returns and a usage hint. However, it lacks details on return format (e.g., data types) and prerequisites like connection state. Still fairly complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema description coverage is 100% (empty schema). The description adds value by listing the returned fields ('ready state, total size, and used size'), which compensates for the empty schema. Baseline for 0 params is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a summary of onboard blackbox flash storage, specifying 'ready state, total size, and used size.' Among siblings like 'get_blackbox_device' and 'get_blackbox_mode,' this tool is uniquely focused on flash storage summary, making its purpose distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'call this before any CLI tools in the same session' provides a specific usage order but does not explain when to use this tool versus alternatives or when not to use it. No sibling tools are compared, so guidance is limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that this tool is read-only or non-destructive. While the name implies a get operation, the lack of side-effect disclosure or safety assurances means the agent cannot be sure of behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact at three sentences, with front-loaded purpose and usage advice. However, it mixes read and write guidance, which could be streamlined by separating the get tool's role from the parameter-tuning advice.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter get tool with no output schema or annotations, the description is remarkably complete. It explains the parameter's function, when to avoid it (baseline tuning), potential risks (oscillation), and numeric constraints, covering all needed context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description adds value by specifying the value range (0–200) and default (20) in brackets, providing context that is not required by the schema but aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the d_max_advance parameter and explains its role in allowing D boost to start before gyro rate peaks, with a specific verb (Get) and resource (d_max_advance). It also provides the value range and default, distinguishing it from sibling get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises setting the parameter to 0 during baseline tuning and exploring only after stabilization, but this advice is more relevant to the set operation. It does not explicitly clarify when to use this get tool versus the set_d_max_advance sibling, leaving the agent to infer the read-only purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description only says 'Get' which implies read-only, but it does not confirm no side effects, permissions, or other behavioral traits. The burden of disclosure is on the description, and it falls short.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence plus a type/default hint. No wasted words, front-loaded with the key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description adequately states the purpose. It lacks details on return format, but the context is minimal and the tool is simple.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema coverage is irrelevant. Per guidelines, 0 params earns a baseline of 4. The description adds no parameter details, but none are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get d_max_yaw: D_max for yaw.' It uses a specific verb and resource, and the name distinguishes it from siblings like get_d_max_pitch and set_d_max_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The naming convention implies a read operation for the yaw axis, but there is no mention of when not to use or alternative tools like get_d_max_pitch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not explicitly state that the tool is read-only or has no side effects, though 'Get' implies a read operation. More clarity on its behavior is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose and including key information (purpose, prerequisite, type, default). Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description provides a good overview of the setting's purpose and requirements. However, it does not explicitly state the return value (just the type), which could be improved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds context about the parameter's meaning and prerequisites, which is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get dshot_bidir' and explains that it enables bidirectional DSHOT for RPM telemetry. It differentiates from sibling tools like get_dshot_bitbang, get_dshot_burst, etc., by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that it is required for RPM filtering and that ESC firmware must support it, providing context on when it's relevant. However, it doesn't explicitly state when to use this tool versus alternatives or when not to use it. Usage is implied as a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it provides additional ESC data, that FORCE enables EDT even when bidirectional mode is off. No annotations exist, so description carries the burden. Missing info on side effects or permissions, but for a read operation this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is brief but packs essential info: purpose, feature, requirements, and type/default. A bit cluttered but efficient for a parameterless getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately explains what it returns (additional ESC data) and special behavior (FORCE). Requirements are stated. Sufficient among many sibling getters.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, yet description includes '[UINT8, default: OFF]' which suggests a parameter that doesn't exist. This is misleading and contradicts the schema. No parameters to document, so baseline is 4, but the extraneous info lowers the score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves extended DSHOT telemetry (beyond RPM). Distinguishes from other get_dshot_* tools like get_dshot_bidir by specifying it provides additional ESC data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for obtaining extended telemetry and notes force mode. Mentions required compile flags (USE_DSHOT, USE_DSHOT_TELEMETRY) but lacks explicit when-to-use vs alternatives or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the return type and range (UINT8, 0–10, default 5), which is important behavioral context for a getter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no wasted words. Front-loaded with purpose and includes tuning advice and type info. Appropriate length for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description provides sufficient context: what the value represents, tuning guidance, and data type/range. Could be more explicit about the return value, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% trivial. The description adds value by specifying the return value's data type, range, and default, compensating for the lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets 'dterm_lpf1_dyn_expo' and explains it is the 'Expo curve for dynamic D-term LPF1 vs throttle.' This clarifies the purpose, though it does not explicitly differentiate from sibling getters for similar parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a tuning guideline ('Push as high as possible without mid-throttle oscillations') but does not explain when to use this getter over alternatives like the setter or other dterm parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It indicates a read operation ('Get') and provides type and range, but lacks details on prerequisites, side effects, or return format. For a simple getter this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by parenthetical type/range info. It front-loads the key information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description sufficiently explains what the tool returns. It does not elaborate on the broader dynamic idle controller context, but that is likely domain-specific and not required for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100% vacuously. The description adds value by explaining the returned value's type and range. With 0 parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'dyn_idle_d_gain', explicitly defining it as the D gain of the dynamic idle RPM controller. It distinguishes itself from siblings by providing the specific parameter name and its meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like get_dyn_idle_i_gain or set_dyn_idle_d_gain. The description only defines what the tool does without any contextual usage advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description indicates it is a read operation ('Get') and includes a type/range hint. It does not detail the function's behavior or return format, but for a simple getter, the background is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two brief sentences plus a bracket note—with no repetition. Every piece of information contributes to understanding the tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers purpose, recommended setting, constraints, and a sanity check. It feels complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds value by providing a type/range/hint for the value returned, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves the minimum frequency for dynamic notch tracking. It explains what the value represents and provides context on its purpose. Among many get_ siblings, the specific name and description make it unique.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives concrete guidance on setting the value (e.g., 'Set ~25 Hz below the lowest resonance', 'ideally >=150 Hz'), but it does not explicitly state when to use this get tool versus alternatives. The guidance is more about parameter tuning than tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not explicitly state that this is a read-only operation with no side effects. It mentions type and default but not the behavior of the get operation itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences cover purpose, usage hint, type, and default. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description provides the essential meaning and type but could be improved by explicitly stating it returns the current value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so no need for parameter descriptions. Tool is fully described given zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the enable_stick_arming setting for stick-combination arming. It distinguishes itself from sibling get tools by specifying the exact setting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at when to disable (if using a dedicated arm switch) but lacks explicit guidance on when to use this tool vs alternatives like the set tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It implies a read operation (get) but doesn't explicitly state it's read-only or free of side effects. Provides type, range, and default, which is helpful but lacks explicit behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a brief data specification in brackets. Front-loaded with purpose, followed by type info. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately explains what is being read and its characteristics (UINT8, 0-200, default 25 per profile). It is complete for a simple getter, though it could mention that it returns the current value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters. Schema coverage is 100% (no params). The description adds value by explaining the return value semantics (throttle percentage, range, default, per-profile). Baseline 4 for 0 params is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states what it does: 'Get ez_landing_threshold: Throttle percentage below which EZ landing activates.' The verb 'Get' and resource 'ez_landing_threshold' are specific, and the context distinguishes it from many other getters in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention when to read vs set, or any conditions. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It explains the effect of the setting but does not state that this is a read-only operation with no side effects. The agent must infer safety from the 'get' prefix; no explicit mention of read-only or non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two short sentences and a brief type/default annotation. It is front-loaded with the tool's purpose, and every word adds value. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description adequately covers the tool's purpose and the setting's impact. It explains the behavioral nuance of the setting (first arm only). However, it does not describe the return format or potential values beyond the default hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100%. With no parameters, the baseline is 4. The description does not need to explain parameters. The type and default are noted in brackets, adding clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves the current setting of 'gps_set_home_point_once', and explains the setting's behavior: only sets home point on first arm after battery connect, preventing reset if disarmed/re-armed mid-field. This is specific and distinguishes it from the sibling 'set_gps_set_home_point_once' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the setting does, implying the tool is used to check the current configuration. However, it does not explicitly state when to use this getter versus alternatives, such as the setter tool or other GPS-related tools. No direct usage scenario or exclusion is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the output is a UINT16 with default 0, hinting at read-only behavior via 'Get'. However, it does not explicitly state that it is a read operation or describe any other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively communicates the purpose and additional details. It is front-loaded with the action and resource, then provides the attribute and type. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-less getter, the description is reasonably complete. It specifies the returned value's meaning, data type, and default. It could be enhanced with allowed range or unit, but it covers the essentials.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema description coverage is 100% (empty schema). Per guidelines, baseline is 4. The description adds the output type and default value, which is helpful but not about parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get gyro_notch2_cutoff: Bandwidth of gyro notch 2', clearly identifying the resource (gyro notch 2) and the attribute (bandwidth/cutoff). This distinguishes it from sibling tools like get_gyro_notch2_hz or set_gyro_notch2_cutoff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 any prerequisites or conditions. It merely states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It correctly indicates a read operation, but lacks detail on behavior (e.g., connection state, no side effects). However, for a simple getter with no parameters, the behavior is predictable, so 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line with clear structure (name, explanation, format info). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description is mostly complete—it states the value, range, and default. However, it could briefly mention what the parameter affects or how it relates to horizon mode for fuller context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema, but the description adds value by specifying the data type, valid range (0–100), and default value (75). This provides meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: retrieve the 'horizon_level_strength' parameter, specifying it is the level mode strength at stick center in horizon mode, with type, range, and default values. This allows an AI agent to understand the exact resource and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not mention any context, prerequisites, or when this parameter is relevant compared to sibling getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It merely states the value range and default but omits any mention of side effects, safety profile (e.g., read-only nature), or required permissions. For a tool that likely just reads a register, it fails to explicitly confirm it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with an inline format specification. Every word is informative; no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with no parameters and no output schema, the description covers the essential information: what is retrieved (offset), its unit, range, and default. It could be improved by explicitly noting it is a safe read operation, but given the tool's simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (schema coverage 100% vacuously). The description adds value by explaining the meaning of the returned value: unit (millivolts), data type (INT16), range (-32000 to 32000), and default (0). This exceeds what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the ibata_offset, identifying it as the ADC current sensor offset in millivolts. This specific verb-resource pairing distinguishes it from hundreds of other get_* sibling tools that retrieve different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call it when you need the current sensor offset. However, there is no explicit guidance on when not to use it or how it compares to alternatives like set_ibata_offset or other get_* tools. The context of sibling tools includes many similar getters, but the description does not differentiate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only nature, permissions, or side effects. The 'get' prefix implies reading, but more clarity on safety would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with two sentences and a bracketed type/default. It is front-loaded with the purpose and uses no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the purpose, use context, and data type. It is sufficient for the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description adds value by explaining the returned value's meaning and type ('UINT8, default: OFF'). This helps the agent understand the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the I-term rotation setting and explains its function: rotates I-term vector during yaw to reduce cross-axis coupling. It distinguishes from sibling tools by noting it's primarily useful for 3D flying, which is a unique context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('primarily useful for 3D flying') but does not explicitly state when to use or not use this tool versus alternatives. For a simple getter, this is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals the data type (UINT16) and default value (1050), which adds value, but does not disclose side effects or if it's purely read-only. The name implies read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. It efficiently conveys the purpose and key characteristics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description provides the parameter type and default. It could explicitly state that the return value is the current min_check value, but overall it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (0 params), so baseline is 4. Description adds meaning by specifying the value is a UINT16 with a default of 1050, which is helpful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the min_check RC channel threshold, which distinguishes it from sibling getters like get_max_check. The verb 'Get' plus resource 'min_check' is specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_max_check). No mention of when reading this threshold is appropriate or that setting is done via set_min_check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only states it's a get operation but does not mention side effects, permissions, or performance implications. A simple read operation is implied but not explicitly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with a single sentence that front-loads the purpose. No unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description provides essential information (what it gets, data type, default). It could mention the range or units, but for a simple parameter getter it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage by default), so baseline is 3. The description adds value by specifying the data type 'UINT8' and default value '45', which goes beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'Yaw P gain', using a specific verb 'Get' and resource 'p_yaw'. It distinguishes from siblings like get_p_roll or get_p_pitch by specifying 'yaw'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool over alternatives. For a simple getter, the purpose is clear, but it lacks context on when it's appropriate versus other PID-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It only states it returns values and mentions 'all active channels', but does not disclose what 'active' means, the format of the return, or any potential side effects, which is insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two short sentences, no unnecessary words, and is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is mostly complete. It specifies the return unit (microseconds) and that it returns active channels. Minor additions like channel numbering could enhance completeness, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). The description adds no parameter information, which is acceptable since there are none. Baseline 4 for 0 parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets current RC channel values in microseconds and returns all active channels. It uses a specific verb ('get') and resource ('RC channel values'), effectively distinguishing it from numerous other getter tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly specify when to use this tool versus alternatives. Its usage is implied from the simple read nature, but no guidance on exclusions or conditions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reports a read-like operation (retrieving a computed value) and adds the data type and default (UINT8, OFF). However, it does not explicitly state that the operation is read-only, nor does it describe any side effects or performance implications. The description is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a data type annotation in brackets. It contains no unnecessary words, and the key information is front-loaded. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description provides the essential purpose and data type. It could be improved by specifying the output format (e.g., a numeric value in volts) or usage context, but it is largely complete for a simple retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the input schema is trivially complete. According to the rubric, 0 parameters warrants a baseline of 4. The description adds value by specifying the returned data type and default state, which compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool retrieves a report of per-cell voltage (total/cell count) for use in telemetry, distinguishing it from similar tools like set_report_cell_voltage. The verb 'get' and resource 'report_cell_voltage' are explicitly defined, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It mentions 'instead of pack voltage', implying a comparison, but does not list conditions, prerequisites, or exclusions. The sibling list includes many get_ and set_ tools, but no selection criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full disclosure burden. It reveals the return type (UINT8) and default value (67), and notes it reflects the 'ACTUAL system' value. This adequately hints at a read-only operation with no side effects, though it could be more explicit about safety or permissions. No contradictions with annotations (none present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with minimal characters. Every word adds value: the name, the explanatory phrase, the data type, and the default. There is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter tool with no output schema, the description is nearly complete. It explains what is retrieved, its meaning, type, and default. The phrase 'ACTUAL system' could be elaborated, but for an expert user this is sufficient. Minor omission: no explicit statement that this is a read-only operation, but it is strongly implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100% (trivially). The description does not add parameter-related information, but none is needed. Baseline 3 is appropriate as the description offers no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Get'), the resource ('roll_srate'), and provides context ('Roll super rate — max rate at full stick deflection (ACTUAL system)'). Although sibling tools exist for pitch and yaw, the tool name and description sufficiently differentiate by focusing on 'roll', making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., get_pitch_srate or get_yaw_srate). There is no mention of conditions, prerequisites, or situations where this tool is preferred, leaving the agent with no basis for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It specifies the return type (UINT8) and default value (30), which adds transparency about the output. However, it does not explicitly state that the operation is read-only, safe, or free of side effects. The behavior is implied by the 'Get' prefix, but explicit confirmation would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two connected sentences that front-load the action and provide essential details. Every word adds value—action, resource, purpose, type, and default. No extraneous text. This is a model of efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately covers what the tool does and what it returns (type and default). It lacks some context about the meaning of the LPF period in a practical sense (e.g., units, range), but the combination of name and description likely suffices for an agent familiar with the domain. Slightly incomplete for a novice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters (empty schema), so baseline score is 4. The description adds meaning beyond the schema by stating the return type (UINT8) and default (30), which is effectively documentation of what the tool returns (though this dimension concerns parameters). For a parameterless tool, the baseline is justified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get rssi_src_frame_lpf_period: LPF period for frame-error-based RSSI smoothing.' It specifies the exact parameter being retrieved and its function, distinguishing it from other getters in the sibling list (e.g., get_rssi_channel, get_rssi_smoothing). The verb 'Get' paired with the parameter name provides unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. The description does not explain when to use this tool versus alternatives, such as the corresponding setter (set_rssi_src_frame_lpf_period) or other RSSI-related getters. It implies querying the current value but lacks contextual instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description provides the data type, range, and default, which adds value beyond the empty schema. However, it does not explicitly state that this is a read-only operation (though implied) or mention any prerequisites like a connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional bracketed info, concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description covers the return value well. Minor omission: no mention of side effects or whether the rate is currently applied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, but the description explains the return value with type, range, and default, which adds meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the serial update rate, specifying the resource and verb. It distinguishes from the sibling set_serial_update_rate_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., setter) is provided. The description simply states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only describes what the value represents but does not mention any behavioral traits such as safety (read-only), permissions, or side effects. The 'get' prefix implies read-only, but this is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a data type note. It front-loads the purpose and includes essential details (default, scaling) without any redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although there is no output schema, the description fully explains the meaning of the returned value (master multiplier scaling all PID gains, default 100). It could mention the full range implied by UINT8 (0-255), but that is implicit. The information is sufficient for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema description coverage is trivially 100%. The description adds useful context beyond the schema by noting the default value (100) and the scaling effect, which clarifies the semantics of the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Get' and resource 'simplified_master_multiplier', clearly stating it retrieves a master gain slider that scales all P, I, D, and D_max together. It distinguishes from siblings like get_simplified_d_gain by explaining it is a global scaling factor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use this tool versus alternatives like individual gain getters. It provides context by referencing 'PIDtoolbox Master Multiplier' but lacks when-not-to or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a read-only operation and provides type and default value, but no annotations exist to confirm. Lacks disclosure of any prerequisites, side effects, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one informative sentence plus a type annotation. No redundant text, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description adequately explains what is retrieved and its type. Could mention range or connection requirements but is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is trivial. The description adds value by specifying the return type (UINT8) and default value (100), which are not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a pitch-specific P and I multiplier, using a specific verb 'Get' and resource 'simplified_pitch_pi_gain'. The parenthetical explains the meaning, distinguishing it from other gain tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. With many sibling tools like get_simplified_pi_gain, the description should differentiate use cases but does not.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation via 'Get' and notes a prerequisite. However, it does not disclose any side effects, return format, or error conditions, which are low-risk for a getter but could still be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using about 30 words to convey the purpose, prerequisite, data type, and default value. Every sentence adds value with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description provides sufficient context: what the value represents, a requirement for use, and type and default. It lacks units or range bounds but is reasonably complete for a basic getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description cannot add semantic meaning. The schema coverage is 100% (empty schema), leading to a baseline score of 3. No additional parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Get') and resource ('spa_roll_width'), and explains its meaning ('Setpoint range over which attenuation ramps from 0 to full (roll)'). This distinguishes it from other get_* tools, particularly other SPA parameters, by specifying the roll axis and the concept of width roll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires: USE_WING') but does not provide explicit guidance on when to use this tool versus alternatives like set_spa_roll_width or other get_spa_ parameters. The usage context is implicitly clear from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It discloses the possible values (OFF/ON), data type (UINT8), and default (OFF), which provides useful behavioral context for a getter. However, it does not explicitly state that the operation is read-only or non-destructive, though 'Get' implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single dense sentence that front-loads the tool's purpose and packs the value explanations, type, and default. No wasted words; every part of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides the type and default, and explains the possible values. It could explicitly state that it returns the current setting, but overall it covers the essential information for a simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4 per rubric. The description adds no parameter-specific information, but schema coverage is 100% trivially. The description does explain the meaning of the values, which aids understanding of what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool gets the 'tpa_low_always' setting and explains the meaning of OFF and ON values. It clearly identifies the specific resource and adds value by defining the parameter's effect. Among many sibling get tools, this description uniquely defines what this tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_tpa_low_always or other TPA-related tools). The description does not provide context about when this read is appropriate or how it relates to other configuration tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description should disclose behavioral traits. It does not mention that this is a read-only operation, whether it might fail, or any prerequisites. The agent must infer it's a safe read based on the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one line naming the tool, one line for purpose, and a clear enumeration of values. No superfluous words. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is quite complete. It explains the meaning of the returned value and possible options. However, it lacks any note on when this setting is relevant or how it interacts with other TPA-related tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters with 100% coverage. The description adds value beyond the schema by explaining the meaning of the return values (e.g., 'D' = D only, default safest) and the default value. This helps the agent interpret the result correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the purpose: retrieving the TPA mode and explaining what each possible value means. It distinguishes from sibling 'set_tpa_mode' by being a getter, and the enumeration of values ('D', 'PD', 'PDS') makes the output interpretable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs. other getters or settings. The name and context imply it's a straightforward config read, but no when-not-to-use or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the value type and default but does not explicitly state that the operation is a safe read with no side effects. Minimal but adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus example and type/default note). Every part serves a purpose, and it is front-loaded with the tool's action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless read tool, the description adequately covers the returned value's semantics and default. It does not mention error conditions or edge cases, but that is acceptable given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so baseline is 4. The description adds value by explaining the returned value's meaning (e.g., '65 = PIDs are at 35% above the breakpoint') and its data type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get tpa_rate' and explains it as 'Maximum attenuation percentage at full throttle' with an example. It distinguishes itself from sibling get_* tools by clarifying the meaning of the value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., set_tpa_rate or related get_* tools). The description does not specify context or exclude cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It adds that the value is a UINT8 with a default of ON, which is helpful, but does not explicitly state that it is a read-only operation or describe any side effects. The 'Get' verb implies read-only, but behavior is only partially disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a type annotation, efficiently conveying purpose and value type. It is front-loaded with the key action and contains no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description explains the purpose and value type. It lacks details on the return format or potential error conditions, but is reasonably complete given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), and schema description coverage is 100%. The description does not need to explain parameters, but it adds value by noting the return type and default, which is beyond the schema's scope. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool retrieves the setting for enabling voltage-based OSD/beeper warnings. It specifies the verb 'Get' and the resource 'use_vbat_alerts', and distinguishes it from sibling tools like 'set_use_vbat_alerts' (setter) and 'get_use_cbat_alerts' (current-based alerts).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'set_use_vbat_alerts' or 'get_use_cbat_alerts'. Being a simple getter, context is minimal, but explicit usage direction is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavior. It states it retrieves a value with a default, but it does not explicitly confirm that this is a read-only operation or describe any side effects (though none are expected). The behavioral scope is minimal but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and to the point—only two sentences. It front-loads the purpose and includes essential technical detail (default, unit). No unnecessary words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
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 a straightforward purpose, the description is mostly adequate. However, it does not explicitly state the return type (though implied as UINT16) or whether the value is in raw format or scaled. This minor gap prevents a higher score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters. The description adds value by documenting the default value and its voltage interpretation (410 = 4.10V), which clarifies the expected output. This exceeds the baseline for a param-free tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Get' and the resource 'vbat_full_cell_voltage', defines its role ('Full cell voltage for capacity display'), and provides default value and unit. This clearly distinguishes it from sibling get_vbat_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance is provided. The purpose is clear from the name, but an agent would need to infer usage context from the description alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits beyond what the name implies (read operation). No mention of side effects, permissions, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, conveying purpose, units, range, and default in a single line. Every element is necessary and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description sufficiently explains what the parameter is and its format. It is complete enough for an agent to understand the tool's function, though it does not explicitly state the return value (inferred from the name).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is trivial. The description adds significant value by specifying units (×0.01V), range (0–250), and default value (1), which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the vbat_hysteresis parameter, explaining it's hysteresis on voltage warnings to prevent flicker, with units, range, and default. This differentiates it from sibling tools like set_vbat_hysteresis and other get_vbat_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Among many battery-related getters, the description lacks differentiation beyond the parameter name, leaving the agent to rely on naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data type (UINT8), valid range (0-100), and default value (0). This is useful behavioral info beyond a simple 'get'. However, no annotations exist to contradict, and it does not explicitly state read-only nature (though implied). Still adds value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus bracket notation. Front-loaded with tool name and purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with zero parameters, the description provides essential info (type, range, default). It could mention that it is read-only, but that is reasonably inferred. Acceptable completeness given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters. Schema description coverage is 100% (trivially). The description does not add parameter-specific info, but that is not needed. Adequate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the yaw-specific deadband value. The description specifies the verb 'Get' and resource 'yaw_deadband', and adds context that it's a deadband around center. Among many sibling get_* tools, this one is uniquely identified as yaw-specific, avoiding confusion with generic get_deadband.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_deadband or set_yaw_deadband. The description only states what it does, not when to use it. Missing context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds type (UINT16) and default value (1998), which is useful but does not disclose behavioral traits such as whether the operation is read-only or if the value is modifiable (a set sibling exists). It is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracket note. Every word earns its place, with key information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description is fairly complete—it specifies the type and default. However, it lacks explicit explanation of the return value's unit (degrees per second), which could be inferred from context but is not stated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Per guidelines, a zero-parameter tool receives a baseline of 4, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('yaw_rate_limit'), and specifies it is a 'Hard cap on yaw rate', which differentiates it from similar siblings for pitch and roll rate limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. Given the large number of sibling get_* tools, explicit context or exclusions would help the agent choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the output value ranges and the effect (setting motor output). However, it does not disclose failure modes, persistence of the setting, or safety state requirements beyond the props-off warning. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences front-load the action and warning, then explain the values. No filler. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with two parameters and no output schema, the description covers the key aspects: purpose, value semantics, and a safety warning. Lacks notes on success/failure signals or persistence, but given the tool's simplicity, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters fully described. The description reiterates the value range and adds the '0 = off' clarification, but this is already in the schema. There is no additional semantic insight beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set the output value for a specific motor' with a specific verb and resource. It distinguishes from sibling tools like motor_get by its action. The value range and meaning are also provided, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a caution ('use with caution — props off!') but does not explicitly state when to use this tool versus alternatives, or when not to use it. There is no guidance on prerequisites like arming state. Sibling tools like motor_get are for reading, so the usage is implied but not compared.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description states it sets the value and includes range and default. However, it does not mention side effects, persistence, or disarm requirements, leaving behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus parenthetical range/default. Front-loaded with name and purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description is adequate. It provides the necessary range and default, though it could mention relationship to calibration workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers type and range (100% coverage). Description adds the default value (0) not present in schema, which is useful. No additional semantics beyond that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly identifies verb 'Set' and resource 'acc_trim_pitch', specifies it's for accelerometer pitch trim in level calibration. Distinguishes from sibling tools like set_acc_trim_roll and calibrate_accelerometer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_acc_trim_roll or calibrate_accelerometer. Lacks context on prerequisites or whether it should be used before/after calibration.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It communicates the parameter range and default but does not mention side effects, persistence, reboot requirements, or whether the change takes effect immediately. This is a gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence that states the purpose, explains the parameter range, and ends with a recommendation and type hint. Every word adds value, and the structure is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the parameter semantics and offers a usage recommendation. It could be improved by noting whether the setting is persistent or requires a reboot, but it is largely complete given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context beyond the schema's minimal description: it explains what the value represents (proportion of earth-frame reference) and clarifies the meaning of the endpoints (0 = body frame, 100 = full earth frame). This helps an agent select an appropriate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: setting the proportion of earth-frame reference used in angle mode. It explains the meaning of the values (0 = body frame, 100 = full earth frame) and gives a recommended value for GPS rescue compatibility. This distinguishes it well from other set_* tools in the large sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by recommending 100 for GPS rescue compatibility, but it does not explicitly state when to use this tool over alternatives or provide exclusions. Among siblings, this is the unique setter for angle_earth_ref, so usage is straightforward, but the guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of behavioral disclosure. It states that the tool sets a parameter and explains the value's meaning, but lacks information on side effects (e.g., requires reboot, affects arming). It provides the range and default, which is acceptable but not comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences. It front-loads the action and critical information (meaning, range, default) without any superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single integer parameter, no nested objects, no output schema), the description is fairly complete. It includes the meaning, range, and default. However, it could mention the return behavior or confirm if a reboot is needed, which would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the parameter with 100% description coverage. The description adds value by explaining that the value represents seconds of throttle-zero and that 0 disables, going beyond the schema's simple label. This enriches the agent's understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Set' and the resource 'auto_disarm_delay', defines its function (throttle-zero seconds before auto-disarm), and notes the special case of 0 disabling it. This distinctly identifies the tool among many set_ siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., the corresponding get_auto_disarm_delay tool). There is no mention of prerequisites such as needing a connected flight controller or the appropriate operational state (e.g., disarmed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the key behavioral traits: doubles precision for gyro and setpoint fields, and increases log size. It also provides type and default info. However, it does not cover possible resets, reboot requirements, or reversibility.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a hint in brackets. It is front-loaded with the primary purpose and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description covers the essential aspects: what it does, the effect on precision and log size, and parameter type/default. It is fairly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter. The description adds value by noting the default value ('OFF') and type ('UINT8'), which complements the schema description. This is above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('blackbox_high_resolution'), and explains the effect ('Double the data precision for gyro and setpoint fields'). It distinguishes itself from sibling tools like 'get_blackbox_high_resolution'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It mentions 'Increases log size' as a consequence but offers no when-to-use or when-not-to-use criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It provides the units, range, and default value, but does not disclose whether the change takes effect immediately, requires a reboot, or any side effects. The description lacks behavioral context beyond the parameter definition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with two clear parts: the action and the parameter specification. It is efficient, front-loaded with the purpose, and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple configuration setter with one parameter, the description is mostly complete: it gives the parameter's role, units, range, and default. It does not explain how this threshold interacts with other crash detection parameters, but such detail is not strictly necessary for a standalone setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter as 'Value for crash_dthreshold (UINT16, 10–2000)' (100% coverage). The description adds semantic meaning ('D-term threshold above which crash is detected'), units (deg/s2), and the default value (50 per profile), which goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool sets the crash_dthreshold parameter, which is the D-term threshold in deg/s2 for crash detection. The verb 'Set' is explicit, and the resource is named precisely, distinguishing it from other crash-related parameters like crash_gthreshold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like set_crash_gthreshold or set_crash_time. However, as a simple parameter setter, the usage is implied: to configure the crash detection sensitivity via the D-term threshold. No exclusions or when-not-to-use guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully cover behavioral traits. It only states the type (UINT8) and default (AUTO) but does not disclose what AUTO does, error handling, side effects, or if a reboot is required. This leaves significant gaps for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a parenthetical. It is front-loaded with the purpose and includes key info (type, default, prerequisites) with no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers purpose, type, default, and prerequisites. It could mention valid value ranges (UINT8 implies 0-255) but is otherwise sufficient for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds value by specifying the type as UINT8 (schema says string) and default value AUTO, which the schema lacks. This goes beyond the minimal schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and resource 'dshot_bitbang_timer', defines its purpose as 'Timer used for bitbang DSHOT', and distinguishes it from sibling tools like set_dshot_bitbang. It also specifies type and default, making the tool's function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions prerequisites ('Requires: USE_DSHOT + USE_DSHOT_BITBANG'), which implies when the tool is applicable. However, it lacks explicit guidance on when to use this tool versus others (e.g., get_dshot_bitbang_timer) or when not to use it. No alternatives or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes setting the mode and AUTO behavior, but lacks details on side effects, permissions, or post-set behavior. Annotations absent, so description carries full burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: two sentences plus parenthetical. Front-loaded with action. Could be better structured but efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers what it does, default, and prerequisites, but does not explicitly list allowed values (ON, OFF, AUTO). Output schema absent; description sufficient but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: explains AUTO selection, default value, and required compile defines. Schema only describes parameter as string for UINT8.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set dshot_burst: DSHOT burst transmission mode' and explains AUTO selection based on hardware. Distinguishes from siblings like set_dshot_bidir, set_dshot_bitbang.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisite (USE_DSHOT + USE_DSHOT_DMAR) and default AUTO, but does not guide when to choose ON/OFF vs AUTO or compare with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It explains each mode's effect (simulates signal loss, instant GPS rescue/drop, instant disarm) and includes a safety warning for KILL. However, it does not mention if the change takes effect immediately or requires a reboot, or if there are any side effects beyond the described behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, consisting of a single sentence with a list. It is front-loaded with the tool name. Every part provides information, though the structure could be slightly improved by separating the list more clearly. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the modes and default. However, it lacks information about persistence (whether the setting survives a reboot), immediate effect, or any required conditions (e.g., failsafe system must be configured). Given no output schema, it would be helpful to mention that the tool returns nothing or confirms the change.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage for the single required parameter 'value', but its description ('Value for failsafe_switch_mode (UINT8)') is minimal. The tool description adds significant semantic value by enumerating the three accepted modes (STAGE1, STAGE2, KILL) and detailing their behavior, which is not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'failsafe_switch_mode' for Aux switch behavior, listing three distinct modes (STAGE1, STAGE2, KILL) with specific use cases. This is a specific verb-resource pairing that distinguishes it well from sibling set_* tools, which all target different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., other failsafe settings or auxiliary switch configurations). The description lacks prerequisites, context about when this setting is applicable, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral consequence (disarm vs Landing Mode) and the pilot protection scenario, but does not disclose whether the setting is persistent, requires reboot, or has any side effects. With no annotations, the description carries the full burden, and it is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences. It front-loads the tool name and action, explains the effect, gives the purpose, and includes the parameter constraints. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description adequately covers the parameter, default, effect, and use case. It could mention interaction with other failsafe settings, but given the simplicity, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema is 100% covered (one parameter), and the description adds value by specifying the default value (100, corresponding to 10 seconds) and the range (0–300). This provides context that the schema alone does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'failsafe_throttle_low_delay', and explains the specific behavioral effect (immediate disarm instead of Landing Mode). It is unambiguous and distinguishes this tool from the many other set_ tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., when to get vs set, or how it compares to other failsafe parameters). The sibling 'get_failsafe_throttle_low_delay' exists, but the description does not mention it or offer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the effect on smoothing but does not disclose side effects, persistence, whether changes take effect immediately or require a reboot, or any limitations. This is minimal transparency for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two short sentences plus a default note. Every sentence is informative and earns its place. The purpose is front-loaded, and the structure is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setter with one value, the description covers the purpose, the possible values, their effects, and the default. However, it omits details like whether the change requires a restart or if there are any prerequisites. Given no output schema and no annotations, it is fairly complete but not fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema already describes the parameter (100% coverage), the description adds significant value by listing the allowed values (OFF, 2_POINT, 4_POINT), explaining their numerical representation (UINT8), and clarifying the behavioral effect of each option (no averaging vs. heaviest smoothing) as well as the default. This goes beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets feedforward averaging, explains its function (smooths RC link quantization by averaging stick input samples), and lists the possible values (OFF, 4_POINT) with their effects, including the default (2_POINT). It is a specific verb+resource combination that distinguishes itself from its get_ sibling and other set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the trade-off between 'snappiest' (OFF) and 'heaviest smoothing' (4_POINT), which implicitly guides usage, but it does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternative tools or contexts where this setting is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the requirement and data type but does not mention side effects, validation behavior, or implications for stored data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with clear structure: name, colon, purpose, requirement in parentheses, and type/default. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, this description covers purpose, requirement, type, and default. Given no output schema, it provides sufficient context for invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3). Description adds context beyond schema: the parameter's role ('SPI bus number for onboard flash'), the default value (3), and the UINT8 type, which the schema describes generically.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Set' and the resource 'flash_spi_bus', and explains the purpose: 'SPI bus number for onboard flash (blackbox storage)'. This distinguishes it from numerous other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a prerequisite ('Requires: USE_FLASH_SPI') but does not provide explicit guidance on when to use this tool versus alternatives. Usage is implied by the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains what each mode does behaviorally and warns that CURRENT_ALT is not recommended. However, it does not disclose whether changes are persistent, require a reboot, or affect other settings. With no annotations, the description carries the full burden but only partially addresses behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a colon-and-list format to explain three modes in two sentences. Every word adds value, and the default value and type are mentioned efficiently. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is a setter with one parameter and no output schema, the description adequately covers the behavior of each mode. It lacks information about persistence or side effects, but for a simple configuration tool, this is sufficient. The sibling tool list is large, but the description effectively distinguishes this tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema, explaining each possible value's behavior. The schema only says 'Value for gps_rescue_alt_mode (UINT8)', which is minimal. The description clarifies the semantics of each option, though there is a type mismatch (schema says string, description says UINT8) which slightly reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Set gps_rescue_alt_mode', clearly identifying the verb and resource. It explains three distinct modes (MAX_ALT, FIXED_ALT, CURRENT_ALT), which distinguishes it from sibling tools like set_gps_rescue_initial_climb or set_gps_rescue_return_alt.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. Although it lists the modes, it lacks context on choosing one over another in a workflow, and no exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Provides data type, range, and default but omits behavioral details such as whether the setting persists across reboots or takes effect immediately. No annotations to cover this gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus compact bracketed info. Extremely concise and front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple single-parameter setter. Lacks context about GPS rescue mode and typical values, but sufficient for basic parameter setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with type, min, max, description. Description adds the default value (750) and reiterates range, adding slight value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (Set), resource (gps_rescue_ascend_rate), and specific purpose (climb rate during initial climb phase). Distinct from siblings like set_gps_rescue_descend_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Does not mention prerequisites, typical scenarios, or relationships with other parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the value range (UINT8, 0–200) and default (20), implying it updates the parameter. However, it does not explain persistence, side effects, or whether a reboot is required. This is acceptable for a simple parameter setter but could be improved.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence plus bracket info) and front-loaded with the purpose. Every word is necessary, and there is no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set tool with one parameter and no output schema, the description adequately covers intent, parameter range, and default. It could mention persistence or related parameters, but it is sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds semantic value by explaining the parameter's role ('Yaw P gain during rescue (heading correction)') and providing range/default info. This goes beyond the schema's generic description ('Value for gps_rescue_yaw_p').
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Set gps_rescue_yaw_p: Yaw P gain during rescue (heading correction)'. It uses a specific verb (Set) and resource (gps_rescue_yaw_p), and provides context (Yaw P gain during rescue) that distinguishes it from sibling tools like 'get_gps_rescue_yaw_p' and other set_* parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description does not mention prerequisites, exclusions, or related tools (e.g., other GPS rescue PID gains). The agent must infer usage 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It explains that setting this requires SBAS integrity data before using corrections, and notes the data type and default. However, it does not specify allowed values (e.g., 0/1) or consequences if integrity data is unavailable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose and includes essential details (data type, default). No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description adequately explains the tool's effect. It could be more complete by listing acceptable values, but the meaning is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter as 'Value for gps_sbas_integrity (UINT8)'. The description adds semantic meaning by explaining what the value controls (require integrity) and the default, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'gps_sbas_integrity', and explains its effect: 'Require SBAS integrity data before using SBAS corrections.' This distinguishes it from siblings like set_gps_sbas_mode and get_gps_sbas_integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. It only mentions the default is OFF, but no context on choosing between SBAS modes or integrity requirements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the effect (only set on first arm, prevents reset) and notes the default is OFF. However, it does not disclose prerequisites (e.g., GPS fix required), side effects, or behavior of ON vs OFF beyond the basic description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a type/default note. Every word adds value, and the most critical information (action and behavior) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the core purpose and effect. However, it does not specify the expected value format or range, and omits details about the return value or confirmation of the setting.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage but the description contradicts it by stating 'UINT8' while the schema defines the parameter as a string. The description does not clarify acceptable values (e.g., 0/1 or ON/OFF) beyond the default, and lacks format guidance for the string input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets a GPS home point parameter to only set home on first arm after battery connect. It explains the behavioral effect and distinguishes from other set_ tools by specifying the unique behavior of preventing home reset on disarm/re-arm.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (to limit home point setting to first arm) and implies the default behavior is different. However, it does not explicitly state when not to use it or compare with alternatives like other GPS home point settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses a key behavioral trait: setting this parameter enables detection of gyro ADC saturation that results in disarming. This goes beyond redundancy and adds value by explaining the safety implication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a technical note, very concise. The purpose is front-loaded in the first sentence, and every phrase adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should fully inform the agent. It explains the feature's purpose and recommended default, but fails to list possible values (e.g., OFF, ON, ALL) or their effects, making it incomplete for parameter selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters with a basic description. The description adds the type hint 'UINT8' (though schema says string, a minor inconsistency) and the default value 'ALL'. It recommends 'ALL' but doesn't enumerate possible values or their meanings, leaving ambiguity for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: sets the gyro_overflow_detect parameter, which detects gyro ADC saturation and causes disarm. This is a specific verb-resource pairing that distinguishes it from the many other set_* sibling tools by naming the exact parameter and its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Recommended: ALL' which provides a value recommendation but no explicit guidance on when to use this tool vs alternatives (e.g., get_gyro_overflow_detect). The usage is implied (change the parameter), but no prerequisites, exclusions, or context for when to set vs leave default are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It provides the value range and default, but does not mention side effects, persistence, or required conditions. While not misleading, it lacks depth for a setter without annotation support.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a bracketed specification. It is highly concise, front-loads the action and parameter, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is adequate: it explains the parameter's purpose, valid range, and default. However, it could be improved by noting that this setting only applies in horizon mode (already stated) and perhaps linking to related parameters like get_horizon_level_strength.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter 'value' has schema description 'Value for horizon_level_strength (UINT8, 0–100)'. The description adds the default value (75) and the meaning 'level mode strength at stick center in horizon mode', providing context beyond the schema. Although schema coverage is 100%, the extra information justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set horizon_level_strength' and defines it as 'Level mode strength at stick center in horizon mode.' This specifies both the resource and the context, distinguishing it from other set_* tools such as set_horizon_delay_ms or set_horizon_ignore_sticks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., requiring horizon mode to be active) or scenarios where adjusting this value is appropriate. The description is purely declarative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It explains the effect (full acro authority at that stick deflection) but does not disclose side effects, persistence behavior, or whether the change takes effect immediately. It adds basic context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a compact bracketed range/default. Every word adds value; no redundancy. It is front-loaded and highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple numeric parameter with full schema coverage, the description adequately explains the purpose, meaning, range, and default. It is complete enough for an agent to use correctly, though it could mention persistence if relevant. No output schema needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline 3. The description adds meaning by explaining the parameter's role in horizon mode and providing the default value (75), which is helpful but not essential beyond the schema's range and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'horizon_limit_sticks' and explains its purpose: 'Stick deflection (%) at which horizon mode gives full acro authority'. It includes the data type and valid range, distinguishing it from sibling tools like get_horizon_limit_sticks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (to adjust the stick deflection threshold) but does not explicitly state when to use it versus alternatives or when not to use it. For a simple setter in a large family, it lacks explicit context for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as persistence, side effects, or whether a reboot is required. The act of setting a parameter implies mutation, but without further details, transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences: the first states the purpose and units, the second provides a usage hint, and a bracketed segment adds range/default. No superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers the parameter's meaning, units, range, and default. It is nearly complete but lacks explanation of how the setting takes effect (e.g., immediate vs. after reboot), which would be useful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters (single integer 'value' with range). The description adds significant value by explaining the unit (mV/A × 10), the need for calibration, and the default value (558), providing context beyond the schema's range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('ibata_scale'), specifying it as the ADC current sensor scale factor with units (mV/A × 10). It distinguishes itself from siblings like 'get_ibata_scale' and other set tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a calibration hint ('Calibrate against a known load'), implying usage in calibration scenarios. However, it lacks explicit guidance on when not to use the tool or alternatives, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the valid range, default, and that 0 disables, but does not mention side effects, persistence, or if a reboot is required. This is minimal behavioral disclosure for a setter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line with essential information: purpose, context, range, default. No waste, front-loaded with key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and a simple single-parameter input, the description covers purpose, range, default, and use context. It does not describe return values, but that is typical for a setter and the completeness is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining what the parameter controls (impact threshold), indicating 0 disables, and providing units and default. This goes beyond the schema's bare description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'landing_disarm_threshold', and explains its purpose (accelerometer impact threshold for auto-disarm on landing) and context (used by GPS Rescue and EZ Landing). It distinguishes from other set_* tools by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the parameter is used by GPS Rescue and EZ Landing, giving implicit context, but does not explicitly state when to use this tool vs alternatives or provide conditions/exclusions. The guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the change is persistent, requires a reboot, or affects other settings. It only states the type and default, lacking important transparency for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence containing all key information: action, resource, purpose, type, and default. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is mostly complete. It explains the parameter's meaning and default, though it could optionally mention a typical valid range instead of relying on the schema's very wide min/max.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The description adds semantic value beyond the schema by explaining what max_check represents and providing the default value, helping the agent understand the parameter's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'max_check', and explains its purpose: 'RC channel value above which arm/disarm and stick commands are recognized.' This is specific and distinguishes it from siblings like 'set_min_check' and 'get_max_check'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use the tool (to set the max_check threshold) and includes the default value, but does not explicitly compare to alternatives like 'set_min_check' or mention when not to use it. Adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral transparency. It adds context about PWM protocols and default, but does not disclose potential safety implications (e.g., setting too high may damage ESCs) or whether a reboot is needed, leaving significant gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with the tool name front-loaded, followed by a meaningful explanation and type/default in brackets. No extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description covers the essential purpose, protocol context, and default. However, it omits relationships with sibling tools like set_min_command and does not specify the unit (e.g., microseconds) or any validation constraints beyond the informal UINT16 hint.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a basic description, but the description adds value by specifying a default value and narrowing the type to 'UINT16' (unsigned 16-bit), which is more restrictive than the schema's wide integer range, helping the agent understand precise constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the maximum throttle PWM value for ESCs, specifying the verb 'Set' and the resource 'max_throttle' with context about PWM-based protocols, distinguishing it from numerous other set_* sibling tools for different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions it's for PWM-based protocols and provides a default value, implying usage context, but does not explicitly state when to use this tool versus alternatives or when not to use it, such as for other protocols.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the reordering behavior and default values but does not mention side effects like persistence, validation, or required reboot. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, front-loading the purpose. It could be slightly more streamlined but is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the essential purpose and parameter format. However, it lacks details on validation, expected string format (e.g., comma-separated), and behavioral side effects, which are relevant for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is 100%, the description adds significant value by explaining the parameter as 'output index for each motor position' and providing a default sequence. This clarifies the format beyond the schema's generic 'Value for motor_output_reordering (UINT8)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reorders motor output channels without rewiring, specifying the output index for each motor position. It distinguishes itself from siblings like 'get_motor_output_reordering' and other set tools by its specific action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs. alternatives. While it mentions 'without rewiring' as a contextual hint, there is no comparison to other set tools or conditions for use, leaving the agent to infer.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'Invert PWM output polarity' and mentions a default, but fails to describe side effects, reversibility, or any impact on system operation (e.g., motor behavior). This is inadequate for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (two sentences), front-loads the action, and includes essential context (use case and default). No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setting tool with a single required parameter, the description provides purpose, use case, and default. It lacks explicit enumeration of valid values, but the overall context is sufficient for an experienced agent. Output schema is absent, but not critical here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter). The description adds the default value 'OFF', which is helpful, but does not enumerate acceptable values (e.g., ON/OFF, 0/1). The schema type is string, leaving ambiguity; the description's mention of 'UINT8' conflicts with the schema type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool inverts PWM output polarity, specifies the use case for ESCs requiring inverted signal, and names the resource 'motor_pwm_inversion'. This distinguishes it from numerous other set_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use: 'For ESCs that require inverted signal.' However, it does not mention when not to use it or alternative tools, though there are no direct competitors among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description bears full burden. Explains clamping behavior and tuning recommendation, but does not mention side effects, persistence, or whether a reboot/save is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences plus a bracketed spec. Front-loaded with purpose, then usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately covers purpose, usage, and default, but omits whether the setting is persistent or requires additional actions like save or reboot, which is common for such configuration tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% with a basic description, but the tool description adds substantial meaning: clamping behavior, default value, and tuning purpose, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the pidsum_limit and explains its function (clamping total P+I+D output). However, it does not explicitly distinguish from sibling tool set_pidsum_limit_yaw, which could cause confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific guidance on when to set to 1000 (during initial PID tuning) and to restore to default after. This gives concrete context but no exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the format (UINT8) and default, and explains the disabled value. However, it does not disclose potential side effects, reboot requirements, or behavior on invalid input.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise lines with no redundant information. Every part is essential: purpose, output count, disabled value, type, and default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description adequately covers the input format and default. It could mention the order of outputs (1-4) but is otherwise sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the parameter description is minimal ('Value for pinio_box (UINT8)'). The description adds significant meaning by showing the default format (255,255,255,255) and indicating it is a comma-separated list of four UINT8 values, which the schema does not convey.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and resource (pinio_box) and specifies it is for AUX box assignments of the 4 PINIO outputs, with the meaning of value 255 (disabled). This distinguishes it from siblings like set_pinio_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives such as get_pinio_box or set_pinio_config. The description lacks context for appropriate use cases or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions UINT8 range and default, but does not disclose persistence, whether changes take effect immediately, or require re-arming. Lacks details on side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: three short sentences covering purpose, effect, and type/default. Front-loaded with key information, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description is fairly complete. It explains what the parameter does and the consequence of extreme values. Lacks only behavioral details like immediate vs persistent effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a basic description of 'value'. The tool description adds domain context 'Roll P gain' and the effect of high values, improving understanding beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set p_roll: Roll P gain. Reacts to angle error.' This is a specific verb-resource pair that distinguishes from sibling tools like set_p_pitch and set_p_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Hints at consequence of too-high value ('fast oscillations on sharp moves') but does not explicitly state when to use or when not to use this tool vs alternatives. No guidance on prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses the value type and range (UINT8, 0–30, default: 5) and the effect (blocks arming). However, it does not specify whether changes take effect immediately or after reboot, or any potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a brief parenthetical note on type/range. It is front-loaded with the purpose and contains no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description adequately explains the purpose, value constraints, and why it matters. It could mention persistence or reboot requirement, but given the simplicity, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter, describing it as 'Value for pwr_on_arm_grace (UINT8, 0–30)'. The description adds 'UINT8, 0–30, default: 5' which overlaps with the schema, but provides context by explaining the parameter's role in the grace period.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function using a specific verb ('Set') and resource ('pwr_on_arm_grace'), and explains its purpose: 'Grace period after power-on during which arming is blocked (prevents arming before receiver binds).' This distinguishes it from sibling tools, many of which are getters or other setters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context ('prevents arming before receiver binds') but no explicit guidance on when to use this tool vs alternatives. It is adequate for a straightforward setter, but lacks comparative advice or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does not mention side effects, persistence, required permissions, or any implications of changing the yaw P gain. The description is minimal and lacks transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with a note. It conveys all essential information without superfluous words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter tool with no output schema, the description adequately covers the action, resource, type, and default. Minor gaps include lack of explanation about change persistence or side effects, but these are less critical for such a straightforward operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond the schema by specifying the default (45) and the semantic meaning ('Yaw P gain'). The parameter name 'value' is generic, and the description clarifies its purpose. The type hint (UINT8) reinforces the schema's integer range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set'), the resource ('p_yaw'), and what it represents ('Yaw P gain'). It also provides the data type (UINT8) and default value (45). This effectively distinguishes it from sibling set tools for other axes or parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is given on when to use this tool versus alternatives. The context of similar set_* tools implies usage, but there are no exclusions or when-not-to-use instructions. The agent must infer from naming conventions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides some behavioral info: type (UINT8) and default value (30). However, it does not disclose side effects, persistence, or the meaning of 'aggressiveness'. More could be said about the expected range or impact on flight behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a short bracket note. Front-loaded with purpose and type/default. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is largely complete. The presence of a getter sibling fills in reading capability. However, it could mention if the value persists across reboots or if it requires a save/reboot to take effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes value as integer with wide bounds. Description adds default (30) and semantic context 'aggressiveness'. This provides useful meaning beyond the schema's minimal description, though explicit valid range (0-255) is not stated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the specific resource 'rc_smoothing_auto_factor_throttle', and explains it is 'Auto-smoothing aggressiveness for throttle channel'. This distinguishes it from related siblings like set_rc_smoothing_auto_factor (which likely affects all channels) and set_rc_smoothing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., set_rc_smoothing_auto_factor for global setting, or other smoothing parameters). The description lacks context for when adjustments are appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral traits. It states the tool sets a configuration value, implying mutation, but does not disclose side effects (e.g., whether changes persist, require reboot, or need disarming). The description is adequate but lacks important behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the tool name and action. It includes essential context (unit/legacy mode, default) without any extraneous words. Every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description is largely complete. It explains the parameter's meaning and default. However, it lacks information about the effect of the set operation (e.g., immediate vs. saved after reboot), which would improve completeness for a configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining that the value represents the actual roll rate in deg/s×10 or a legacy RC multiplier, with a default of 7. This interpretation goes beyond the schema's 'UINT8' type, aiding the agent in selecting an appropriate numeric value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as setting the roll_rc_rate, specifying it as the roll rate at stick center. It distinguishes from siblings like set_pitch_rc_rate and set_yaw_rc_rate by naming the axis. The note about ACTUAL vs legacy modes further clarifies the parameter's interpretation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives (e.g., set_roll_rate_limit for max rate, set_roll_srate for super rate). No context is given for prerequisites or circumstances where this should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It confirms the parameter is a UINT16 with range 100–500 and default 150, which is helpful. However, it does not explain side effects such as whether changes take effect immediately, require a reboot, or affect performance. The behavioral transparency is adequate for a simple setter but lacks deeper context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a bracketed range/default. It is extremely concise, front-loaded with the purpose, and contains no filler. Every word contributes to understanding the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the essential purpose and parameter constraints. It lacks details on persistence or side effects, but given the tool's simplicity and the context from sibling tools (all similar set_ commands), the description is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents the parameter type, range, and default. The description adds value by explaining that this filter is a 'post-notch smoothing LPF' applied to the RPM signal for notch tracking, providing context beyond the schema's raw definition. This helps the agent understand the parameter's role in the system.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states this tool sets the post-notch smoothing LPF for the RPM signal used in notch tracking. The verb 'Set' is implied by the name, and the resource is explicitly 'rpm_filter_lpf_hz'. It distinguishes itself from siblings by specifying the exact filter type and its role in the signal chain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 (e.g., other filter settings for RPM). It does not mention prerequisites, scenarios, or exclusions. The agent receives no context about whether this should be adjusted before or after other filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the parameter type and default but does not disclose side effects, whether changes take effect immediately or require a reboot, or any dependencies. For a setter, more context on persistence and impact is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a type/default notation. Front-loaded with purpose, no wasted words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one parameter and no output schema, the description covers the parameter meaning, trade-off, and default. It lacks mention of whether the change is persistent or requires reboot, but the overall completeness is good given low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description is minimal ('Value for rssi_smoothing (UINT8)'). The description adds significant meaning by defining it as an LPF period and explaining the effect of higher values. Schema coverage is 100%, but the description compensates well.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'rssi_smoothing', defines it as an LPF period for RSSI smoothing, and explains the trade-off (higher = smoother but slower response). It distinguishes from the sibling 'get_rssi_smoothing' by explicitly being a setter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to adjust RSSI smoothing period but does not explicitly state when to use it or provide alternatives. No guidance on when to choose higher vs lower values or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the behavioral effect of the parameter (deactivation threshold) but does not disclose side effects, validation, or whether changes take effect immediately. It adds some context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, well-structured sentence with embedded type and default. Every part is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description covers purpose and constraints. Lacks interaction details with other runaway settings, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds meaning by explaining that the value represents a threshold for deactivating runaway protection, which is not in the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Set' and defines the parameter as the throttle percentage above which runaway protection deactivates. It distinguishes this parameter from related siblings like set_runaway_takeoff_deactivate_delay by explaining its specific role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It does not mention prerequisites, typical scenarios, or conditions under which the setting should be adjusted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that values below the threshold trigger signal-loss detection, but does not mention whether the change persists, requires a save, or if there are any side effects. The default value is helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at 19 words, front-loaded with the action, and efficiently communicates the purpose and effect in a single sentence with bracketed metadata.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter, the description covers the purpose, effect, and default. It does not explicitly mention units (usec is implied) or the existence of a getter companion, but overall it is sufficient for an AI agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter as 'Value for rx_min_usec (UINT16)' with a range. The description adds meaning by linking the value to signal-loss detection and providing the default. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the shortest channel pulse width considered valid, explains its role in signal-loss detection, and includes the default value. This distinguishes it from similar tools like set_rx_max_usec.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives like set_rx_max_usec or other set_* tools. It does not mention prerequisites or scenarios where adjusting this parameter is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits such as side effects, persistence, or permissions needed. Only indicates it sets a value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with parenthetical note, no wasted words, information front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter without output schema or annotations, the description adequately explains purpose and parameter. Could benefit from noting that its a configuration change typical of the set_* family.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers parameter with description 'Value for scheduler_debug_task (UINT16)', but description adds default value 0 and explicitly states type UINT16, adding meaningful context beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool sets a task index for scheduler debug output, using specific verb 'Set' and resource 'scheduler_debug_task'. It distinguishes from its getter sibling 'get_scheduler_debug_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description mentions use for per-task timing analysis, giving context on when to use, but does not explicitly exclude other scenarios or compare with alternatives like the getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral impact. It discloses the parameter type, range, and default, and implies a mutation (set operation). However, it does not mention side effects (e.g., immediate effect, persistence, need for reboot) or potential risks of extreme values. For a simple setter, this is acceptable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bracketed spec. Every sentence is informative, with the purpose front-loaded and the constraints in a compact format. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description provides a good amount of context: the parameter's role, valid range, and default. It lacks mention of related tools (e.g., get_scheduler_relax_rx) or persistence behavior, but for a straightforward setter, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter description (100% coverage), so the baseline is 3. The description adds value by explaining the parameter's purpose ('controls how much other tasks can run during RX processing') and providing the default value (25), which is not in the schema. This helps the agent understand the semantic meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the scheduler relaxation time for the RX task. It specifies the resource ('scheduler_relax_rx'), the verb ('Set'), and explains its effect on allowing other tasks during RX processing. This clearly distinguishes it from siblings like set_scheduler_relax_osd.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives like get_scheduler_relax_rx or set_scheduler_relax_osd. There is no mention of prerequisites, use cases, or scenarios where adjusting this parameter is appropriate. The agent is left without context on when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool is a setter (write operation) for a multiplier affecting pitch D term, with a UINT8 type and default value 100. However, it does not mention side effects, persistence, or prerequisites (e.g., disarmed state), leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with a brief type/default note. Every word is informative and front-loaded. No repetition or unnecessary details. It is a model of brevity for a simple setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward parameter setter, the description covers the essential purpose, parameter meaning, and type/default. It does not mention that the setting is likely for a flight controller PID tuning or that it persists after reboot, but given the tool's simplicity and the presence of many similar setters, the description is contextually adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by explaining the parameter is an 'Additional D multiplier for pitch only' and specifying its type 'UINT8' and default '100', which are not fully captured in the schema (schema only has wide integer bounds). This provides meaningful context beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the specific resource 'simplified_pitch_d_gain'. It adds context by explaining it is an 'Additional D multiplier for pitch only', which differentiates it from similar tools like set_simplified_d_gain (general D gain) and set_simplified_pitch_pi_gain (PI gain).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus its alternatives. It does not mention that it should be used for pitch-specific D gain tuning or that set_simplified_d_gain might be used for overall D gain adjustments. The agent must infer usage solely 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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It discloses the parameter is UINT8 with a default of 0 and requires USE_WING. However, it does not describe persistence, side effects, or range enforcement beyond the schema. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parenthetical note, concise and front-loaded with the core purpose. It could be structured more explicitly but is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the key points: purpose, requirement, default. It does not explain impact on flight behavior or when to use, but it is adequate for a straightforward configuration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline is 3. The description adds the default value (0) not in the schema, and clarifies the type. This enriches the parameter meaning beyond the schema definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the S-term (stability term) for roll, a specific parameter. It distinguishes from siblings like set_s_pitch and set_s_yaw by specifying roll. The verb 'Set' plus resource 's_roll' is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement 'USE_WING' but does not provide guidance on when to use this tool versus alternatives (e.g., when to set s_roll vs s_pitch). It implies usage via the requirement but lacks explicit context or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the transient behavior triggered by fast stick changes and includes range and default. However, it does not disclose whether the change is persistent or takes effect immediately, nor potential side effects on flight performance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a concise parenthetical note on range/default. It is front-loaded, no wasted words, and efficiently conveys the tool's purpose and key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description adequately covers what the tool does, the parameter meaning, and the effect. It lacks only minor details like persistence or immediate application, but overall it is sufficiently complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The description adds the default value (5) and contextual meaning of the parameter beyond the schema's min/max/type, helping the agent understand the parameter's role and typical value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'throttle_boost', and explains its function: 'Transiently boosts throttle output on fast throttle stick changes for immediate throttle feel.' This distinguishes it from many sibling 'set_*' tools and pairs with 'get_throttle_boost'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool vs alternatives, when not to use it, or mention any prerequisites. Usage is only implied by the tool's purpose, which is insufficient for an agent to make nuanced choices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description lacks disclosure of side effects, persistence, or reboot requirements. For a setter, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with essential details, no wasted words, front-loaded with action and context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the purpose and value meaning, but lacks behavioral details like persistence. Adequate for a simple setter with one parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage, but description adds unit scaling (×0.01V per cell) and default value (300), enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a voltage threshold for battery detection, with specific units (×0.01V per cell) and default value. It is distinct from sibling set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as setting a configuration parameter, but no explicit guidance on when to use compared to alternatives (e.g., get_vbat_detect_cell_voltage) or any exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description only indicates a 'set' operation, implying a write. It does not disclose persistence, reboot requirements, value clamping, or safety considerations. Additional behavioral context would benefit the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences to convey the parameter name, purpose, unit, and default. It is front-loaded with the key information and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description explains the parameter well. However, it lacks context on how this setting interacts with auto cell-count detection or other battery-related settings. Still, it is largely complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description is generic ('Value for vbat_max_cell_voltage (UINT16)'), but the tool description adds significant meaning: the parameter's role (max per-cell voltage for auto cell-count), unit conversion (×0.01V), and default (430 = 4.30V). This enriches understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'vbat_max_cell_voltage', and explains its purpose ('Maximum per-cell voltage for auto cell-count detection') with unit and default value. This distinguishes it from numerous sibling 'set_*' tools by specifying exactly what parameter it configures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for setting the max per-cell voltage, but offers no explicit guidance on when to use this tool versus alternatives like set_vbat_min_cell_voltage or set_vbat_full_cell_voltage. No when-not-to-use or prerequisite information is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the alarm trigger and default value, but does not mention persistence, reboot requirements, or other side effects. Annotations are absent, so description carries the burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with additional essential details. No redundant information, perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers purpose, effect, scaling, and default. Lacks confirmation of persistence or units, but adequate for a simple setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter description, but the tool adds meaningful context: scaling (×0.01V) and interpretation of default (330 = 3.30V), adding value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the minimum cell voltage and triggers a battery-critical alarm, with scaling and default explained. It is specific and distinguishes from other setter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. With many sibling setter tools, such guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It mentions the effect of the parameter value but does not discuss side effects, persistence, permissions, or safety implications of setting this parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with an additional clarifying note in brackets. It is front-loaded with the tool's purpose and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description defines the function and parameter effect adequately. It is missing mention of persistence or dependencies (e.g., requiring vbat_sag_compensation to be enabled), but overall it is sufficiently complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds significant meaning: it explains that lower values mean faster response, indicates the parameter type (UINT8) by default value (2), and provides context beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the LPF period for battery sag compensation voltage measurement and explains the effect (lower = faster response). It is well-distinguished from numerous sibling set_ tools by its specific parameter name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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, no prerequisites, and no exclusions. It simply describes what it does without usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description alone must disclose behavior. It states the parameter range and default but does not mention any side effects, state changes, or requirements for use. It is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a compact bracketed specification, efficiently conveying the essential information without extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple integer parameter setter, the description covers purpose, range, and default. However, it could elaborate on the relationship with the general deadband setting for fuller context, but it is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds context beyond the schema by explaining the parameter represents a 'deadband around center' and includes the default value, which is not in the schema. Schema coverage is 100%, so the description adds meaningful value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action ('Set') and the resource ('yaw_deadband'), explicitly stating it is yaw-specific, which distinguishes it from the sibling tool 'set_deadband' that sets the general deadband for other axes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'set_deadband'. It does not address conditions, prerequisites, or scenarios where this tool should or should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden for behavioral disclosure. The use of 'Get' implies a read-only operation, but it does not explicitly state that no state is modified, nor does it mention any side effects, authentication needs, or rate limits. For a simple config getter, the implication may suffice, but more explicit transparency would improve clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence with no unnecessary words. It efficiently communicates the key information: purpose, resource, and additional type/default info.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is mostly complete. It explains the purpose and includes the type/default. However, it could be improved by specifying the expected output format or units, and by explicitly tying it to its sibling setter tool (set_adc_device) for context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema provides no parameter-level documentation. The description adds valuable semantic information by indicating the data type (INT8) and default value (2), which are not available from the schema alone. This fully compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'adc_device' configuration, which is the ADC device used for voltage/current sensing. This directly distinguishes it from other get_* tools such as get_acc_hardware or get_gyro_hardware, as it specifically targets the ADC device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., get_adc_vrefint_calibration or set_adc_device). The description does not mention any prerequisites, context, or exclusions, leaving the agent to infer usage solely from the tool name and brief purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It discloses the UINT8 type, range (0–100), and default (25), which is helpful. However, it does not mention any side effects, idempotency, or whether the tool requires a connected flight controller. The description provides basic transparency but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two informative sentences plus a technical spec. Every part adds value: the title, the definition, the behavioral note, and the type/range/default. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter getter tool with no input parameters and no output schema, the description provides all essential information: what is retrieved, its meaning, and its valid range. The agent can use this tool confidently without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description does not need to explain parameters. Baseline 3 applies, and no additional value is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the throttle percentage for airmode activation. It uses the verb 'Get' and specifies the resource 'airmode_start_throttle_percent'. The behavioral note about motors idling at higher values adds clarity. The existence of a sibling setter tool provides clear differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The pairing with 'set_airmode_start_throttle_percent' is implicit but not mentioned. For a simple getter, the usage is straightforward, but the description does not confirm or exclude specific scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the return value type (UINT8), range (0–200), and default (50). This is sufficient for a simple read operation. However, it does not mention potential failure modes or connection requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One short sentence plus bracket-encoded type info. Every element adds value: purpose, effect, and value specification. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description fully covers what the tool does, why it is used, and the characteristics of the returned value. No output schema needed because the description provides the type and default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description adds no parameter information since there are none, meeting the baseline. It does add output value semantics but that is not parameter-related.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get angle_feedforward' and explains it provides feedforward in angle mode to reduce lag. It distinguishes from the sibling set_angle_feedforward tool by using 'get' and describing the read-only nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like set_angle_feedforward. The description does not provide context on prerequisites or when retrieval is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description implies a read operation but uses 'Force barometer driver' which could be misinterpreted as mutating. It does not explicitly state read-only or destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence plus a prerequisite note and type hint. Every element is necessary and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is minimal. It covers the basic purpose and prerequisite but lacks details on possible return values and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters; schema coverage is 100%. The description adds context about the value type (UINT8) and default (AUTO), which is helpful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'baro_hardware' and contrasts it with AUTO-detect, distinguishing it from other get_baro_* siblings. The verb 'Get' and resource 'baro_hardware' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (USE_BARO) but provides no guidance on when to use this tool versus alternatives like get_baro_bustype. No when-not-to-use information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the behavioral effect (doubles precision for specific fields) and side effect (increases log size). It also mentions data type (UINT8) and default (OFF). This is good transparency for a read operation. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical note. It is concise, front-loaded with the action, and every part adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no parameters and no output schema. The description explains the effect and side effect, but does not specify the return format (e.g., whether it returns ON/OFF, 0/1, or the actual value). For a simple getter, this is a notable gap. Otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params, 100% coverage). The description does not need to explain parameters. It adds context about what the tool retrieves (the high resolution setting). Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the resource ('blackbox_high_resolution'). It explains the effect: doubling data precision for gyro and setpoint fields. It also mentions a side effect (increases log size) and provides data type and default. This distinguishes it from sibling getters that retrieve other settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It only implies a trade-off by noting that it increases log size, but does not explain scenarios where this would be beneficial or detrimental. No comparison with other getter tools or when to prefer this setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects (expected none), authentication needs, or read-only nature. The description only states what the tool does, not any behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a bracketed spec, front-loading the purpose. No unnecessary words, efficient and clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description includes type, range, and default. However, it does not clarify what 'per profile' means or describe the return value format. With no output schema, a brief note on return value would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (no parameters), so schema description coverage is 100%. The description adds value by specifying the data type (UINT16), valid range (10–2000), and default value (50 per profile), which are not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the specific resource 'crash_dthreshold', and defines the parameter's purpose as 'D-term threshold above which crash is detected (deg/s2)'. It also provides type, range, and default, distinguishing it from sibling getters for other crash parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives like set_crash_dthreshold or other crash-related getters. However, as a parameter getter, usage is straightforward and implied by its name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It indicates a read operation and gives the data type, range, and default, but does not explicitly state that the tool is read-only, has no side effects, or disclose any behavioral traits beyond the value retrieval. It is adequate for a simple getter but lacks explicit transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bracketed spec. It is front-loaded with the purpose ('Get deadband: RC deadband...'), then adds a usage hint, and finally the technical constraints. Every element serves a purpose with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters, no annotations, and no output schema, the description provides a solid explanation of the deadband concept, its unit, the effect of increasing it, and the acceptable range. It is nearly complete, though it could mention that the value is persisted in the flight controller configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is trivially 100%. The description adds meaningful context by specifying the returned value's type (UINT8), range (0–32), and default (0), which goes beyond the empty input schema. This provides an agent with valuable information about what to expect without needing to infer from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the RC deadband around stick center in microseconds, specifying it's for RC sticks. It distinguishes from the sibling get_yaw_deadband by explicitly saying 'RC deadband'. However, it could be more explicit about the differentiation from other deadband parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage hint ('Increase if sticks don't return to exact center'), which implies when to adjust the value. However, it does not explicitly state when to use this getter versus other tools (e.g., set_deadband) or provide guidance on alternatives. The hint is useful but only partially addresses usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only or safety aspects. It does mention the type and default, but fails to explicitly state the non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence and a parenthetical for type and default. It is front-loaded but could benefit from better structure for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description explains the purpose, lists key values, and provides default. However, without an output schema, it does not fully describe the return format, so slight incompleteness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so baseline is 4. The description adds value by explaining the key debug modes and default, which helps understand the tool's purpose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets debug_mode, which selects internal signals exposed in blackbox debug fields. It lists key modes and distinguishes from the sibling set_debug_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a getter for debug mode, and the context of a setter sibling is present. However, it does not explicitly state when to use or not use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses the value range (1-1000, default 300) and max useful value ~1000, which is behavioral info. It does not explicitly state read-only, but 'Get' implies no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a bracketed spec, front-loaded with the purpose. No extraneous words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a getter with no parameters, the description covers the value's meaning, tuning strategy, and value range. It is complete enough to use the tool correctly, though it could explicitly mention that the return is a single integer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so baseline is 4. The description includes bracketed info about the value's type (UINT16), range, and default, which adds context about the return value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the Q factor, specifying it's the narrowness of each notch. The verb 'Get' distinguishes from the sibling setter 'set_dyn_notch_q', but no explicit differentiation is made.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides tuning guidance ('Increase until the resonance just stays within the notch, then stop') implying use during tuning. However, it lacks explicit when-to-use or when-not-to-use instructions, nor does it mention alternatives like the setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral effect of the mode ('holds the current angle as the setpoint rather than actively leveling') and includes type and default value (UINT8, default OFF), providing useful context beyond a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with the functional description plus a brief technical note. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter with no output schema, the description adequately explains the setting's effect and type. Minor gap: it does not explicitly state that the return value is the current ON/OFF value, but this is inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds meaning (explains the mode) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the level_race_mode setting and explains its purpose. However, it does not explicitly distinguish itself from the sibling 'set_level_race_mode', though the name implies a getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied (read the current setting), but there is no explicit guidance on when to use this tool versus alternatives like 'set_level_race_mode'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It mentions the data type (UINT8), default value (NONE), and a requirement. However, it does not describe failure behavior if USE_MAG is disabled or the exact output format, leaving some gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that includes purpose, special value, requirement, and type. Every part is informative without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with no parameters and no output schema, the description covers the essential: purpose, one possible value, requirement, and type. However, it could be improved by listing all possible magnetometer hardware options and clarifying the output format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%. There is nothing for the description to add about parameters, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get mag_hardware' with the resource 'Magnetometer hardware selection'. It distinguishes itself from siblings like 'set_mag_hardware' and 'calibrate_magnetometer' as a read operation, and explains the special value 'NONE' and requirement 'USE_MAG'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the prerequisite 'Requires: USE_MAG', which guides when to use this tool. However, it does not explicitly contrast with alternative tools like 'set_mag_hardware' or note when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It specifies the returned value's type ([UINT8]) and default (100), adding transparency beyond the empty schema. However, it does not clarify that this is a read-only operation (implied by 'get') or describe any potential side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three sentences covering purpose, usage scenario, and data format. Every sentence is informative with no redundancy or unnecessary details. Ideal for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-less getter with no output schema, the description covers the value's purpose, when to use it, and its type/default. It lacks a note that 100% means no limit, but this is reasonable given the default. Overall sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has zero parameters, so description need not explain params. Baseline is 4. The description adds value by explaining the meaning of the output (caps per-motor output) and providing the default value, making the data more understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get motor_output_limit' which is slightly tautological, but immediately clarifies purpose with 'Caps per-motor output as a percentage.' It clearly identifies what value is retrieved and its function, distinguishing it from other getters through specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use when running higher cell count than motors are rated for' with a concrete example (6S on 4S build → ~66%). Does not mention when not to use or list alternatives, but the guidance is strong and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the burden. It clarifies a read operation ('Get'), specifies the data type (UINT8) and default value (47), which are behavioral traits beyond the name. There is no contradiction, and the description is sufficient for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with one sentence stating the purpose and a parenthetical note on type and default. Every part is useful and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description adequately conveys the return type and default. It adds tuning context without being verbose. It does not specify the exact return format, but for a scalar UINT8, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. Per the guidelines, the baseline for 0 parameters is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the pitch P gain and provides a tuning hint about inertia. The verb 'Get' and resource 'p_pitch' are specific, though it does not explicitly distinguish from similar tools like get_angle_p_gain or get_p_roll. The added context about pitch needing higher P adds value but is not a direct sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage in PID tuning by noting pitch typically needs higher P than roll. However, there is no explicit guidance on when to use this tool versus alternatives, nor any conditions where it should not be used. The hint is useful but not a full guideline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full responsibility. It discloses the trade-off (smoothness vs. lag) and mentions the default value (30) and type (UINT8), but does not specify the return format, range, or valid values, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—three short sentences. Every sentence provides essential information: what it is, the trade-off, and the default/type. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of an output schema, the description would benefit from clarifying the return value format (e.g., just the numeric value, any units). Currently, it only tells the agent what the parameter is about but not what the response will look like. Still, for a simple getter, it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100% (empty schema). The description adds value beyond the schema by explaining the trade-off, default, and type, which helps the agent understand the semantics. Thus it exceeds the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: retrieving the auto-smoothing aggressiveness for setpoint channels. It uses a specific verb ('Get') and resource ('rc_smoothing_auto_factor'), and distinguishes itself from other getters by explaining the trade-off ('Higher = smoother but more lag').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. As a read-only getter, usage is implicitly to read the current value, but the description does not mention that checking this parameter before setting it or that it is relevant only for certain RC link types.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description includes data type and default value, which partially conveys behavior, but does not disclose whether the operation is read-only, side effects, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with the data type, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should clarify the return value. It states the setting but does not explicitly say it returns the current inversion state. The INT8 hint is helpful but incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is perfect. The description adds value by specifying the data type (INT8) and default value (OFF), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the RSSI inversion setting, specifying the verb 'Get' and the resource 'rssi_invert'. It distinguishes from sibling tools like set_rssi_invert and other get_rssi_* parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at a scenario (some receivers send inverted RSSI) but does not provide explicit guidance on when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden for behavioral traits. It discloses the derivation method and a default state ('OFF'), but does not confirm whether the operation is read-only, whether it requires permissions, or what side effects exist. The sibling set_rssi_src_frame_errors suggests configurability, which is unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences front-load the purpose and context, with no wasted words. The format is efficient and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is relatively complete for a simple getter with no parameters, but it lacks specification of the return value format (e.g., is it a numeric RSSI value or a boolean indicating use of frame errors?). The phrase 'Derive RSSI' suggests a computed value, but it's ambiguous whether the tool retrieves the configuration setting or the derived RSSI. Given the sibling set_rssi_src_frame_errors, the description could clarify.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds no parameter info (none needed), but includes an extra detail about return type suggestion '[INT8, default: OFF]', which provides value beyond the empty schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool derives RSSI from frame error rate, specifying it is for receivers that do not report RSSI directly. This effectively distinguishes it from other RSSI-related getters like get_rssi_channel or get_rssi_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at when to use ('for receivers that do not report RSSI directly') but does not explicitly exclude other use cases or mention alternative tools. Siblings like get_rssi_channel are not compared, so the guidance is implied but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The 'Get' prefix implies a read-only operation, but the description does not explicitly state safety or side effects. It adds context about the return value but lacks behavioral detail.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (three sentences) but the first sentence redundantly repeats the tool name. Efficient overall with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description covers purpose, usage, and return type. Lacks mention of the setter counterpart but is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description adds return value info '[UINT16, default: 0]', providing semantics beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves a task index used in scheduler debug output for per-task timing analysis. The verb 'Get' and resource 'scheduler_debug_task' are specific, and it distinguishes from the sibling 'set_scheduler_debug_task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It specifies usage for per-task timing analysis, but does not provide when not to use or mention alternatives like the setter counterpart. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses the operation is a get (read), explains the value's meaning and effect, and specifies the data type and default. No contradictory information, but could mention if it requires FC connection or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Fairly concise, but the first phrase 'Get simplified_gyro_filter_multiplier:' is redundant with the tool name. Otherwise, every sentence provides value. Could be slightly shorter without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the value's role and range adequately for a simple getter. It covers the core meaning and effect, though it doesn't specify if the value is cached or real-time. Sufficient for most use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so baseline 4 applies. The description does not need to add parameter info since none exist. It correctly notes the type and default as context, which is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the simplified gyro filter multiplier, describes it as a gyro filter cutoff scaling slider, explains the effect of raising or lowering the value, and includes the data type and default. This distinguishes it from other getters by providing specific meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_simplified_gyro_filter or set_simplified_gyro_filter_multiplier. The description implies general usage for reading gyro filter cutoff scaling but does not mention when not to use it or how it differs from related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds context: it is a read operation, requires USE_WING, specifies UINT16 type, and default value per profile. However, it does not disclose side effects, behaviors if USE_WING is missing, or persistence details beyond the profile hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a parenthetical note, each part adding value: purpose, requirement, type, and default. No redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter, the description covers purpose, requirement, type, and default. It lacks explanation of SPA acronym or value range, but given no output schema, it is minimally adequate. Sibling tools provide context but description could be more self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage. The description adds no parameter info beyond confirming no parameters are needed, which meets the baseline for a param-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the setpoint centre value for yaw SPA, specifying the exact resource. It differentiates from sibling tools like get_spa_yaw_width and get_spa_yaw_mode by targeting the centre value, and from set_spa_yaw_center as the read counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the prerequisite USE_WING but provides no explicit guidance on when to use versus alternatives like set_spa_yaw_center or other getter tools. The naming implies usage for reading, but no exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It specifies the data type (UINT8), default (OFF per profile), and a prerequisite (USE_WING). However, it does not disclose that the tool is read-only (implied by 'get'), nor describe the return value format or any side effects. Basic behavioral context is present but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a requirement annotation and type/default info. Every element is functional and to the point, with no wasted words. Front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description provides adequate context: type, default, and prerequisite. It could explicitly state that it retrieves the current setting value of SPA yaw mode per profile, but overall it is complete for its complexity level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (empty schema). The description adds value by specifying the type, default, and prerequisite, which are not in the schema. It compensates for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the SPA mode for yaw. The tool name and description together differentiate it from sibling tools like get_spa_pitch_mode and get_spa_roll_mode by specifying the axis. No explicit mention of alternatives, but name and context make it clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the requirement `USE_WING` for this tool to be valid, and provides the type (UINT8) and default value (OFF per profile). It implies use when you want to read the current yaw SPA setting, but does not explicitly state when not to use it or list alternatives (e.g., use set_spa_yaw_mode to change).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully bears the responsibility. It discloses the data type (UINT8), valid range (0–30), default value (0), and the auto-detect behavior. For a simple read-only tool, this is sufficiently transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each providing essential information: purpose, usage hint, and data constraints. There is no redundancy, and the most important details are front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description adequately covers the return value semantics and usage context. It is complete for a simple getter, though it could hint at related tools (e.g., set_system_hse_mhz).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and the description compensates by explaining the meaning of the returned value, its range, and default. This adds value beyond the schema, meeting the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the external crystal frequency in MHz, with additional details on valid values. While the name and description are specific, there is no explicit differentiation from other getter tools, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions when the value is required ('for some non-standard clock speeds') and that 0 enables auto-detect. This provides basic usage context but does not specify when to use this tool over alternatives or include explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the burden of behavioral disclosure. It correctly indicates this is a read operation ('Get') and explains the parameter's role, but does not disclose side effects or safety. The default value is mentioned, which adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a requirement and type/default annotation. Every component serves a purpose, with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple getter with no parameters and no output schema, the description fully covers what the parameter is, its unit, default, and prerequisite. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0 parameters, so schema coverage is 100% trivially. The description adds value beyond the schema by specifying the type (UINT16) and default value (1000), which are not present in the schema. Baseline for 0 params with high coverage is 3, but the added details justify a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets a specific parameter (tpa_speed_basic_delay) and explains its function: delay in ms before speed-based TPA updates after a speed change. This distinguishes it from other getters in the sibling list by providing a unique, specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes a prerequisite (requires USE_WING) but provides no guidance on when to use this tool versus alternatives (e.g., the setter or other getters). There is no explicit context for when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It states that the tool 'gets' a setting, implying a read-only operation with no side effects. However, it does not explicitly confirm that it only reads a configuration value and does not modify any state. While a simple getter has limited behavioral complexity, the description could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining the purpose, plus a bracket notation for the data type, range, and default. Every element adds value, and there is no wasted space. It is front-loaded with the essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description adequately explains what the return value represents (percentage, meaning, range, default). It is complete for a simple getter, though it could potentially benefit from mentioning how this value interacts with other settings (e.g., it is used in conjunction with vbat_sag_compensation).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (input schema has no properties), so schema coverage is complete by default. The description adds no parameter information because none is needed. This is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the vbat_cutoff_percent setting, specifying its meaning as the percentage of vbat_sag_compensation to apply at critically low voltage. It also includes the data type, range (0-100), and default value (100). This is specific and distinguishes it from other getter tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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. It does not specify prerequisites, context, or differentiate it from other vbat-related getters such as get_vbat_sag_compensation or get_vbat_warning_cell_voltage. The agent is left without explicit usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully disclose behavioral traits. It explains the value's meaning, unit, and default, but does not explicitly state it is a read-only operation or discuss any side effects, prerequisites, or return format beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the tool name, and includes all essential information in a single efficient sentence. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with no output schema and trivial usage, the description is complete: it explains the value, unit, data type, and default. An agent can fully understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so baseline is 4. The description adds context about the retrieved setting's meaning and default, which is adequate. No parameter details are needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the maximum per-cell voltage for auto cell-count detection, including unit (×0.01V) and default value (430 = 4.30V). It is specific and unambiguous, distinguishing this tool from numerous sibling getters by naming the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 like set_vbat_max_cell_voltage or other getters. It lacks explicit context for usage decisions, though the tool's purpose is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only defines the parameter. It lacks any disclosure of behavioral traits such as persistence, side effects, or whether a reboot is required. This is a significant gap given the absence of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a bracket, front-loading the purpose and key details. Every word serves a purpose, and there is no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but without annotations, the description should cover basic behavioral context (e.g., immediate effect, reboot needed). It does not, leaving the agent partially uninformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the parameter's function (low-pass filter cutoff for vertical speed), units (Hz×10), and default value (100), which are not in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'altitude_d_lpf', and specifies that it is a low-pass filter cutoff for altitude derivative (vertical speed). It includes units (Hz×10), range, and default, distinguishing it from siblings like set_altitude_lpf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for vertical speed filtering via 'altitude derivative', differentiating from set_altitude_lpf. However, it does not explicitly state when to use or when not to use this tool, nor does it mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description covers the basic behavior (setter, reduces lag) and parameter constraints (UINT8, 0–200, default 50). It does not disclose side effects, persistence, or required connection state, but is adequate for a simple parameter setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exceptionally concise: two sentences plus the range/default inline. No redundant words, all information is front-loaded and relevant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity tool with one parameter and no output schema, the description is complete. It explains the purpose, effect, and valid values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with min/max but no default. The description adds the default value (50) and the UINT8 type, providing clarity beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set angle_feedforward' and explains its effect: 'Feedforward in angle mode — reduces lag when moving the angle setpoint.' This distinguishes it from the many other set_* tools and the get_angle_feedforward sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no exclusions, and no context about prerequisites or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It does not disclose side effects, persistence, permissions, or impact on flight behavior. Only basic functionality is described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parenthetical range/default; no wasted words. Information is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, it covers purpose and parameter semantics adequately. Missing behavioral context like persistence or effect on flight, but acceptable given tool simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds the default value (0) not in schema, along with type and range in brackets, enhancing parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set deadband: RC deadband around stick center (microseconds),' specifying the action, resource, and domain. It distinguishes from sibling tools like set_yaw_deadband by focusing on the main deadband.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Increase if sticks don't return to exact center.' This gives a clear use case, though it does not mention alternatives or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It mentions prerequisites (compile-time defines USE_DSHOT and USE_DSHOT_TELEMETRY) and the default value (OFF), which is helpful. However, it does not specify whether the change takes effect immediately, requires a reboot, or is persisted. It also does not indicate if setting is possible while the flight controller is armed or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single clear sentence followed by a parenthetical with technical details. It is front-loaded with the key action and purpose, and every part adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given its simplicity (single parameter, no output schema), the description covers the main purpose and prerequisites but lacks details on the exact allowed values for the parameter and whether the setting is temporary or persistent. The type mismatch (string vs UINT8) also undermines completeness. Overall, adequate for a basic parameter setter, but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'value' parameter minimally as a string. The description adds the type '(UINT8)', the default 'OFF', and the required compile-time defines. This goes beyond the schema, providing useful semantic context. However, there is a slight contradiction: the schema says 'string' while the description says 'UINT8'; also the allowed values (e.g., ON/OFF or 0/1) are not specified, which could cause confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set dshot_bidir: Enables bidirectional DSHOT for RPM telemetry. Required for RPM filtering.' It identifies the specific action (setting a parameter), the resource (dshot_bidir), and the functional context (RPM telemetry and filtering). This distinguishes it from other set_* tools in the sibling list, as it focuses on a unique parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: 'Required for RPM filtering' and a prerequisite ('ESC firmware must support it'). However, it does not explicitly state when to use this tool versus alternatives (e.g., other set_* tools for DSHOT features like set_dshot_burst or set_dshot_bitbang). There is no guidance on when not to use it or which tool to use instead for other DSHOT configurations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the parameter's role (expo curve vs throttle) and tuning goal, but does not mention persistence, reboot requirements, side effects, or that the tool modifies persistent settings. This is a moderate disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a compact parenthetical with type/range/default. Every word is relevant and front-loaded with the main purpose. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (1 param, no output schema), the description covers purpose, tuning guidance, and parameter details. It doesn't mention the companion get tool or note that this is an advanced PID setting, but for a straightforward setter it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter fully described), so baseline is 3. The description adds meaning by providing the default value (5) and the tuning strategy ('push as high as possible without oscillations'), which goes beyond the schema's range and type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the resource ('dterm_lpf1_dyn_expo'), and explains it as an 'Expo curve for dynamic D-term LPF1 vs throttle.' This is specific and unambiguous. However, it does not explicitly distinguish from sibling tools like set_dterm_lpf1_dyn_max_hz, though the unique name suffices.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit tuning guidance: 'Push as high as possible without mid-throttle oscillations.' This tells the agent the objective and constraint for choosing the value. It does not compare to alternatives (e.g., other D-term filter settings), but for a single-parameter setter this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It tells that the tool sets a rate, specifies the data type (UINT8), range (0-250), and default value (50 per profile). However, it does not disclose whether changes take effect immediately, require saving to a profile, or trigger any side effects. The information is adequate for a simple parameter setter but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence with a parenthetical technical note. It front-loads the purpose and includes key details. The structure is efficient, though the tool name is repeated in the description, which is slightly redundant but acceptable. Every part contributes to clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description conveys the core purpose, range, default, and that the setting is per profile. It lacks information about persistence or activation, but given the low complexity, it is reasonably complete. The per-profile note adds useful context not evident from the schema alone.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the 'value' parameter with its type and range (100% coverage). The tool description adds meaning by explaining the parameter's role ('rate at which throttle is reduced') and providing the default value ('default: 50 (per profile)'), which goes beyond the schema's description. This extra context helps the agent understand the parameter's practical significance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and the resource ('ez_landing_speed'), and explains its function as the rate of throttle reduction during EZ landing. This distinguishes it from sibling tools like set_ez_landing_limit and set_ez_landing_threshold, which control different aspects of EZ landing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to configure the EZ landing speed parameter, but it does not explicitly state when to use this tool over alternatives or provide any contextual guidance such as prerequisites or side effects. The presence of sibling tools like get_ez_landing_speed and set_ez_landing_limit suggests a family of related settings, but no comparison is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It specifies the parameter's range and default but does not disclose whether changes take effect immediately, require a reboot, or persist. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, with no redundancy. It frontloads the purpose and immediately provides essential details (unit, range, default). Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description and schema together cover the parameter's meaning and valid values. However, the lack of behavioral context (e.g., persistence, immediate effect) and absence of output schema limit completeness. A score of 3 reflects adequate but not thorough coverage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context beyond the schema: it explains the parameter's role ('yaw FF hold after stick release') and provides the default value. This helps an agent understand the parameter's semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and the specific resource ('feedforward_yaw_hold_time'), and provides context that it is a duration in milliseconds for the yaw FF hold after stick release. This distinguishes it from siblings like set_feedforward_yaw_hold_gain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While there is no explicit 'when to use' or 'alternatives,' the description is self-contained for a simple parameter setter. The name and context from siblings (e.g., set_feedforward_yaw_hold_gain) provide implicit differentiation. A score of 4 is appropriate because the description implies its use for tuning yaw feedforward hold time.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool sets the model and notes the default, but it does not disclose potential side effects, such as whether a reboot is required or if GPS must be active. Mutation is implied but not explicitly stated as safe or critical.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. It front-loads the purpose and key details, with no unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers purpose, default, and an example. However, it does not enumerate all possible dynamic model values, which could help an agent choose the correct input. Overall, it is fairly complete but missing parameter options.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'value' parameter has 100% schema description coverage. The description adds the default value ('AIRBORNE_4G'), explains it as 'UINT8', and provides an example, giving significant meaning beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the UBlox dynamic model used during flight. It provides the specific value 'AIRBORNE_4G' and explains its use case for high-dynamics FPV. Among siblings, it is distinct from other set_gps_ublox_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'AIRBORNE_4G handles high-dynamics FPV' which implies usage context, but it does not explicitly state when to use this tool versus alternatives, nor does it provide conditions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses that the setting is hardware-level and the default is OFF, but does not detail whether a reboot is needed or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with essential information front-loaded. Every word is functional and no unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description fully covers purpose, usage guidance, type, and default. No output schema is needed, and complexity is low.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the description adds the default value 'OFF' and repeats the data type 'INT8' already in the schema. This adds some value but does not compensate beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets input_filtering_mode to enable hardware-level RC input filtering, with specific context about target hardware. It is not explicitly differentiated from sibling tools, but the purpose is unambiguous and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Required on some F1 targets; leave OFF on modern hardware.' This tells the agent when to use and when not to use this tool, though no alternative tool is named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the value type and default, but does not mention side effects, persistence, or whether reboot is required. Minimal behavioral context beyond the obvious setter function.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single informative sentence with a bracketed type/default hint. It is concise and front-loaded with the tool name and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description plus schema provide essential info. However, absence of output schema and lack of behavioral transparency (e.g., effect timing, success indication) leaves some gaps. Adequate but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter value as a UINT8 string. The description adds the default value ('OFF') and the protocol support qualification, providing meaningful addition beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets pid_in_tlm to include PID data in telemetry output, with protocol support qualification. The verb 'Set' and the specific parameter name distinguish it from get_pid_in_tlm and other set_ tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing PID data in telemetry, but does not explicitly state when to use this tool versus alternatives or provide conditions for use or non-use. It mentions protocol support but gives no exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the effect on stick response but does not disclose side effects, persistence, or whether a reboot/save is required. The type and default are given, but the schema's min/max conflict with the implied UINT8 range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parenthetical note, all front-loaded with the action. Every word serves a purpose, with no redundancy or unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the basic meaning and default, but is incomplete regarding the value range (schema allows large integers but description implies 0-255 UINT8). It also lacks info on persistence or interaction with other settings. Given no output schema, the description should clarify these points.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description is minimal ('Value for roll_expo (UINT8)'). The tool description adds significant meaning by explaining the exponential curve behavior and the effect of higher values. This provides useful semantic context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set roll_expo' and explains the parameter's effect: 'transition between center sensitivity and max rate. Higher = more expo, slower center, faster edges.' It distinguishes from sibling expo tools (pitch, yaw, thr) by specifying 'roll'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. While the purpose is clear, it lacks context about prerequisites or when adjustment is appropriate (e.g., during tuning, while disarmed).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Adds context about hard cap and application after rates curve, but does not disclose side effects, persistence, or validation beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with data type and default, concise and front-loaded; could be slightly more structured but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one param and no output schema, the description adequately explains the value's role, default, and type; lacks broader context but sufficient for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond schema: specifies the parameter is a hard cap in deg/s, default 1998, and applied after rates curve, enriching the schema's basic type info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the roll_rate_limit, a hard cap on roll rate in deg/s, distinguishing it from other rate limit setters like set_pitch_rate_limit and set_yaw_rate_limit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives; the purpose implies usage but lacks contextual when-not-to-use or prerequisite info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose whether changes persist, require a reboot, or affect other parameters. Basic behavioral context is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a bracketed summary. Every word carries weight, and the action is front-loaded. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description covers the purpose and parameter semantics well. It could be improved by mentioning related RPM filter settings or whether changes take effect immediately, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers only type and range (100%), but the description adds significant meaning: the parameter's role ('notches not applied'), a tuning recommendation, and the default value. This is excellent beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set) and the resource (rpm_filter_min_hz), and explains the effect (notches not applied below this frequency). However, among many similar set_rpm_filter_* siblings, it does not explicitly differentiate itself from other filter parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear tuning hint ('Lower on larger quads with slower-spinning motors') indicating when to deviate from the default. It does not mention when not to use this tool or suggest alternatives, but the context is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It discloses the data type (UINT8) and default value (OFF), but does not mention side effects (e.g., requires receiver support, may need reboot), validation, or behavior when set incorrectly. This is minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one action sentence, a condition, and a type/default note. No fluff, front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set tool with a single parameter and no output schema, the description provides the essential purpose and condition. However, it lacks details on valid value range, error handling, and whether a reboot is required, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds context by tying the parameter to the fast mode enablement and noting the type and default, but does not specify valid values or format beyond what the schema already describes.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: to set/enable fast (200kbps) SBUS mode. It specifies the target resource (sbus_baud_fast) and condition (for SBUS receivers that support it), distinguishing it from the corresponding getter and other configuration tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use this tool (for compatible SBUS receivers) but does not explicitly mention alternatives or when not to use it. It lacks direct comparison with the getter (`get_sbus_baud_fast`) or other serial configuration tools, but the condition is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must cover behavioral traits. It states the type (UINT8), range (0-100), and default (50), but omits important details for a setter: whether the change persists, requires reboot, affects flight dynamics immediately, or any safety implications. Insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with additional info in brackets, front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could mention return value or confirmation. It provides range and default but misses persistence and side-effect details. However, since many sibling setters behave similarly, the agent may infer, but it's not fully self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the 'value' parameter. The description adds the default value and explicit type info beyond the schema, enhancing understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set thr_hover' as verb+resource, explains it's the estimated hover throttle percentage used by alt-hold and internal calculations, and distinguishes from the many other 'set_' siblings by naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that the value is used by alt-hold and internal calculations, helping the agent know when it's relevant. Does not explicitly state when not to use or compare to alternatives, but the context is clear enough for typical use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states behavior (show only differing settings) but does not clarify read-only nature, side effects, or output format. Minimal disclosure beyond purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, 16 words, front-loaded with key action and comparison. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers purpose and comparison to sibling. Could mention output format but is fairly complete given the simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline is 4 for zero parameters. Description adds no param info, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Show' and resource 'settings that differ from defaults'. Distinguishes from sibling cli_dump by noting it's more concise than a full dump.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context for when to use this tool by comparing to a full dump, implying it's for quick review. However, does not explicitly state when not to use or list alternatives beyond cli_dump.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the operation 'may take several seconds', which is a helpful performance hint. However, it does not state whether the operation is read-only or if it requires an active connection, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, perfectly concise. Every word is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the core purpose and a key behavioral trait (time cost). It could mention that the output is a large set of commands, but it is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%, so the description need not add parameter details. It is adequate, though no extra context about the output format is provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'dumps the complete flight controller configuration as CLI commands'. The verb 'dump' and resource 'complete flight controller configuration' are specific and unambiguous. It distinguishes itself from sibling tools like cli_diff and cli_defaults by emphasizing completeness.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this tool is used to retrieve the full configuration, but it does not explicitly state when to use it over alternatives or when not to use it. No exclusions or context are provided, though the 'complete' qualifier helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions saving to EEPROM, rebooting, and closing the connection. However, it does not disclose whether all pending changes are saved, what happens to unsaved changes, or that the operation overwrites EEPROM. The warning is helpful but not fully comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first clearly states the action, the second is a critical warning. No wasted words, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and a straightforward action, the description is fairly complete. It could mention that it persists all pending `set` commands, but the warning about connection closure is valuable. For a simple tool, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so no additional parameter information is needed. Schema coverage is 100%. The description does not need to add param meaning, and baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool saves configuration to EEPROM and reboots the flight controller. It distinguishes from siblings like `reboot_flight_controller` (which only reboots) and `cli_defaults` (which resets to defaults). The verb 'save' and resource 'configuration to EEPROM' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage after configuration changes but does not explicitly state when to use it vs alternatives like `reboot_flight_controller`. The warning about connection closure gives indirect guidance, but no explicit 'when to use' or 'when not to use' is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly indicates a read operation but does not explicitly state non-destructiveness or other traits like requiring a flight controller connection. For a simple listing tool, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that states the tool's purpose without any fluff. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is complete enough: it explains what is listed (features) and what information is returned (enabled/disabled state). It could mention the return format, but the core information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (schema description coverage 100%), so the description does not need to add parameter information. The baseline for zero parameters is 4, and the description is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists all features and their enabled/disabled state on the flight controller. It uses a specific verb ('list') and resource ('features'), and the output is defined. The tool is distinct from siblings like feature_enable and feature_disable which modify features.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for viewing features, but does not explicitly state when to use it versus feature_enable or feature_disable. It provides no context on prerequisites (e.g., requiring a connection) or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains the meaning of the value ('limits correction', '0 = no limit') and provides type and range ([UINT16, 0–500, default: 0]). This gives adequate transparency for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence followed by a parenthetical with crucial type/range info. No filler, front-loaded with the tool's name and action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description explains the value's purpose and range. It could mention that it returns the current setting, but the action 'get' implies that. Adequate for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in the input schema, and the description adds meaning about the tool's output (type, range, default). Per rules, 0 params yields a baseline of 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and resource 'acc_limit', and explains its purpose: limiting the accelerometer correction applied to the attitude estimate in angle/horizon mode. This distinguishes it from siblings like set_acc_limit and get_acc_limit_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when to use or when not to use. As a getter, usage is implied but no guidance on alternatives among the many get_acc_* tools. Lack of context to help agent decide between this and get_acc_hardware, etc.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits beyond the getter action. It does not mention safety, connection requirements, or potential side effects, leaving the agent to infer from the tool name and type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus bracketed details. No redundant information, every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description is largely complete: it explains what is retrieved, the axis, and expected value characteristics. Missing are prerequisites like requiring a flight controller connection, but such context is common across all tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description adds value by documenting the expected output type (UINT16), range (0–500), and default (0), which aids output understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'acc_limit_yaw', explains it's the same as 'acc_limit' but for the yaw axis, and specifies the value range and default. It effectively distinguishes from the sibling 'get_acc_limit' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for yaw axis acceleration limit retrieval via reference to 'acc_limit', but does not explicitly state when to use this tool versus alternatives or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data type (UINT8) and valid range (10–250), which adds transparency. However, it does not mention what the return value looks like or any potential errors. For a simple getter, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately states the purpose and follows with the technical details in brackets. No superfluous words, and the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the core purpose and the parameter's specification. It could be improved by noting that it returns the current value of the setting, but overall it is complete enough for an AI to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description adds no parameter semantics beyond the schema. According to guidelines, 0 parameters gets a baseline of 4. The description does not need to add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb ('Get') and the resource ('angle_feedforward_smoothing_ms'), and explains the parameter's purpose ('Smoothing applied to angle feedforward signal'). The range and default value are provided, which distinguishes it from other get_* siblings like get_angle_feedforward.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, the 'get' prefix and context of sibling tools imply it is for reading the current value of this parameter. A clear description of when to use (e.g., 'Use to retrieve the current setting for angle feedforward smoothing') would improve.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It discloses the data type (UINT8), valid range (10-80), and default value (60), which is adequate. It does not mention side effects or permissions, but as a simple getter, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by technical constraints in brackets. It is efficient with no wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description provides essential return value details (type, range, default) and context (flight-time, angle mode). This is sufficient for a simple getter, though it could mention that it returns a single value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description provides meaningful context beyond the empty schema, including the type, range, and unit. This fully compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get angle_limit: Maximum tilt angle in angle mode during flight-time (degrees)', with a specific verb and resource, and includes type, range, and default. It effectively distinguishes from sibling tool 'set_angle_limit' and other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when/when-not guidance is provided, but its purpose as a read operation for a specific flight parameter is clear. Among many get_* siblings, it lacks differentiation advice, but the context of 'angle limit' is implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses that the tool is a getter with no parameters, returns a UINT16 value, and includes the range and default. This is sufficient for a simple read operation, though it could mention any side effects (likely none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences and a technical notation. It front-loads the purpose, explains usage, and provides technical specifications without any redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no annotations, no output schema), the description is complete. It explains what the tool does, its unit, range, default, and practical use case. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema covers 100% of properties (none). The description adds no parameter details, which is appropriate since there are none. For zero-parameter tools, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets battery capacity in mAh, specifying the unit and scope. While the tool name itself is self-explanatory, the description adds detail, but does not explicitly distinguish from sibling tools like get_battery or get_battery_state.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Used with current meter to estimate remaining charge,' which implies a scenario for use. However, it does not provide explicit guidance on when not to use this tool or suggest alternatives among the many sibling getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates it retrieves a configuration value ('Get battery_continue') and notes the default value (OFF). Without annotations, it lacks an explicit statement of non-destructive behavior, but the 'get' verb strongly implies a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence complemented by a requirement note and type/default. It is front-loaded and contains zero fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, no annotations, and no output schema, the description covers the essential purpose, context, requirement, and value type. It lacks details on error conditions or return structure, but those are less critical for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, earning a baseline of 4. The description adds value by clarifying the data type (UINT8) and default value (OFF) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it gets 'battery_continue' and explicitly explains its purpose: 'Continue logging/flying after battery disconnect/reconnect (for hot-swap builds).' This clearly distinguishes it from its sibling 'set_battery_continue' as a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a requirement (USE_BATTERY_CONTINUE) and context (hot-swap builds), which implies when to use this tool. However, it does not explicitly contrast with alternatives like set_battery_continue or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It notes the return type (UINT8) and default value, implying it's a read operation. However, it does not explicitly state it is non-destructive or safe, leaving some ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence with clear abbreviations and format. It front-loads the key information and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (type, possible values, default). It could mention that it returns the current setting of the current meter source, but it is sufficient for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, baseline 4. The description adds meaning about the return value, interpreting the possible values (ADC, ESC) and the default, which is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool gets the current_meter configuration, explaining it indicates the current sensor source with two specific options (ADC and ESC). The purpose is clear and distinguishes it from sibling tools like set_current_meter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It is implied for reading the current meter setting, but lacks context on conditions or prerequisites. Sibling tools are numerous but not differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds behavioral information beyond the tool name: it specifies the data type (UINT8) and the default value (46). Since no annotations are present, this helps the agent understand the expected output range and default, but it does not disclose side effects or authentication needs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short clauses. It efficiently communicates the purpose and a key behavioral detail (type/default), though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description does not explicitly state what the tool returns (e.g., the current D_max pitch value). While the type and default give partial info, a full description of the return value is missing, reducing completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (trivially). The description does not need to elaborate on parameters, and effectively conveys that no input is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get d_max_pitch: D_max for pitch.' This clearly identifies the tool as a getter for the D_max parameter related to pitch, distinguishing it from siblings like get_d_max_roll and get_d_max_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. It is implied that this tool is used when retrieving the D_max value for pitch, but no context on prerequisites or conditions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It describes the value's type (UINT8), default (40), and constraint, but doesn't mention error handling if constraint is violated or any side effects. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. All parts serve a purpose: name, definition, constraint, and type/default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description explains the purpose, provides a constraint, and specifies the type/default. It lacks broader context about how this parameter fits into the system, but that is acceptable for a parameter retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, so baseline is 4. The description adds useful information about the output value type and default, which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'd_max_roll', defines it as 'Dynamic damping ceiling — D value used during fast moves', and includes a constraint (must be >= d_roll). This distinguishes it from siblings like get_d_roll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a constraint ('Must be ≥ d_roll') but no explicit guidance on when to use this tool over other D-related getters. With hundreds of sibling tools, more context on when to query this specific parameter would help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It adds that AUTO dynamically selects based on hardware capability and specifies the return type (UINT8) and default (AUTO). However, it does not disclose possible values beyond AUTO or error handling when prerequisites are unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence that front-loads the key information: what it retrieves, the behavior of AUTO, compile requirements, and type/default. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple getter with no parameters and no output schema, the description covers the essential aspects. It could be improved by listing the possible values or stating that the setting is read-only, but still provides adequate context for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters and adds context about the return value type and default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'DSHOT burst transmission mode' and explains that 'AUTO selects based on hardware capability'. It distinguishes this from sibling getters like get_dshot_bidir or get_dshot_bitbang by specifying the exact resource and its behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for reading by naming it 'Get dshot_burst' and includes the compile-time requirements 'USE_DSHOT + USE_DSHOT_DMAR', but does not explicitly state when to use this tool versus alternatives like the setter or other getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implicitly indicates a read operation via 'Get', but does not explicitly state it is safe or read-only. It provides type and default info, but no further behavioral context (e.g., that no state is modified).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, highly efficient sentence. It front-loads the purpose, includes an example, type, and default, with no redundancy. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter without output schema or parameters, the description covers meaning, a typical value, and type/default. It could explicitly state the output unit (Hz) but infers it from the example. Overall, complete enough for an agent to understand what value is returned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% trivially. No parameter information is needed. Baseline for zero parameters is 4, and the description does not need to add anything beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'dterm_lpf1_dyn_max_hz' parameter, explaining it as the Dynamic D-term LPF1 maximum cutoff at full throttle. It provides an example value (AOS tune: 110 Hz) and type info (UINT16, default: 150). This distinguishes it from siblings like get_dterm_lpf1_dyn_min_hz and get_dterm_lpf1_static_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage context via 'at full throttle', but lacks exclusions or guidance on when not to use it. Given sibling tools exist, an explicit usage note would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description carries the burden. It explains the parameter's purpose and effect, but does not explicitly state that the tool is read-only (implied by 'get') or describe any side effects. For a simple getter, it is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a compact bracket notation for range/default. No redundancy, front-loaded with purpose, and every phrase adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema or annotations, the description explains the parameter's behavior and value interpretation. It does not describe the return format (likely just the numeric value), but for a simple getter this is sufficient. Slightly incomplete due to missing return type.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema covers all (0). The description adds value by providing the range [UINT8, 0–20, default: 7] directly, compensating for the schema's lack of constraints. Baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the feedforward_jitter_factor parameter and explains its function: suppressing FF on slow/jittery stick inputs. It also distinguishes the effect of higher vs lower values, which differentiates it from other feedforward parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on tuning (freestyle/HD vs racing) but does not explicitly state when to use this tool over alternatives like get_feedforward_averaging or get_feedforward_boost. No exclusions or decision criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description discloses the value type (UINT16), default, and purpose, but does not mention if the tool is read-only or any side effects. It carries the burden of behavioral disclosure partially.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with essential details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value (type and default) and the concept. It could mention that it returns the current value, but it's otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (coverage 100%). The description adds meaning by explaining the value's purpose, type, and default, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the f_roll feedforward value for roll, compensates for stick input lag, and is scaled by a slider. It distinguishes from siblings like get_f_pitch and get_f_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool vs alternatives like set_f_roll or other getters. Usage context is implied but not clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosure. It adds meaningful context about the behavior: it is a simple read operation for a configuration parameter, and provides the data type, range, and default. This goes beyond the minimal and helps the agent understand the nature of the value. No contradictions with annotations as none exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single line with a title and parenthetical info. It front-loads the action and resource, then provides the explanation. Every part earns its place with no wasted words. Ideal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides sufficient context: what parameter is read, its meaning, type, range, and default. It does not explicitly state the return format (e.g., the value alone), but this is implied. Given the tool's low complexity, the description is complete enough for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description adds no additional parameter information beyond what the schema provides. Per guidelines, with high coverage, baseline is 3. The description's inclusion of the parameter's type and range is helpful but not required for parameter semantics since there are no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the gps_rescue_ascend_rate parameter and explains it as the climb rate during initial climb phase. It specifies data type (UINT16), valid range (50-2500), and default value (750), providing a precise, unambiguous purpose that distinguishes it from sibling getters like get_gps_rescue_descend_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to read the current ascend rate setting, but does not provide explicit guidance on when to use it versus alternatives such as set_gps_rescue_ascend_rate or other gps_rescue getters. No when-not-to-use or context for selection is given, which for a simple getter is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist; the description does not disclose behavioral traits like read-only nature, side effects, or authorization requirements. The name implies reading but no explicit confirmation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with three sentences and a bracket, but it unnecessarily repeats the tool name. Could be slightly more streamlined.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the purpose, recommends usage, and provides technical context (CPU load impact). It is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite having no parameters in the schema, the description adds value by detailing the type (UINT8), range (1-20), and default (10) in brackets, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets the target GPS update rate, and distinguishes it from sibling tools by focusing on this specific parameter. It includes context about recommended values for GPS rescue and CPU load reduction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific usage guidance (10 Hz for GPS rescue, 1-2 Hz otherwise) with rationale (CPU load, 8k8k). Lacks explicit when-to-use vs. alternative getters, but the context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the data type (UINT8), valid range (0–10), default value (5), and the meaning of the value. This provides adequate transparency for a simple read-only tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining the purpose and effect, followed by a compact specification of type, range, and default. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no parameters or output schema, the description fully explains what the tool does and the semantics of the returned value. It is complete for its simple retrieval function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, and schema description coverage is 100% (vacuously). Baseline score of 3 applies; the description adds no parameter information because none exists.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves an expo curve shaping parameter for dynamic LPF1 cutoff vs throttle, and explains that higher values mean faster rise. This is specific and distinguishes it from numerous sibling getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Since it's a getter without parameters, the usage is implicit, but the description could mention that it is used to inspect the current setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'Get' which implies a read-only operation, and provides type/default info. However, it does not explicitly disclose that it has no side effects or require permissions. The transparency is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: one clear sentence plus a parenthetical hint and type/default. Information is front-loaded with the verb and resource. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description provides the purpose, a usage hint, and type/default. However, it does not explain the return value format or units beyond 'Hz' implied. Mostly complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0), and schema description coverage is 100%. Baseline for 0 parameters is 4. The description adds no parameter info because none exist, which is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get gyro_lpf1_dyn_min_hz: Dynamic LPF1 minimum cutoff (at low throttle)' which specifies the verb and resource. It distinguishes from siblings like get_gyro_lpf1_dyn_max_hz and get_gyro_lpf1_static_hz by mentioning 'minimum' and 'at low throttle', and provides a hint about static mode usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a usage tip ('Set equal to gyro_lpf1_static_hz to use static mode') but does not explicitly state when to use this tool versus alternatives among the many gyro-related getters. The context is implied but not fully clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It correctly indicates it's a read operation ('Get') and gives tuning hints but does not disclose any side effects, limitations, or safety profile beyond what is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with three sentences plus a note. It front-loads the key information and every sentence adds meaningful context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description provides enough context for a getter: it explains what the value represents, its impact, a special condition, and the default. It could mention the return format but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so schema coverage is 100%. The description adds value by explaining the parameter's meaning, tuning guidance, default value, and data type as a bracket note.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the gyro_lpf2_static_hz value, identifies it as LPF2 cutoff, and explains its significance with tuning guidance. It distinguishes this tool from many sibling get_* tools by naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly tell when to use this tool versus alternatives like get_gyro_lpf1_static_hz. It only provides context about the parameter's behavior, not selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the tool returns a gyro offset value and its range. As a getter, read-only behavior is implied. It does not describe side effects or permissions, which are minimal for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a bracketed info block. The purpose is front-loaded, and every element adds value (what, when, format). No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers purpose, usage context, return value type, range, and default. It is complete for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters. The description compensates by specifying the returned value's type (INT16), range (-1000–1000), and default (0), which adds meaning beyond the empty schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the yaw gyro trim value ('Manual yaw gyro trim'). It specifies the unit (tenths of degrees/s) and implies it's for correcting drift. While it doesn't explicitly differentiate from sibling getters, the context is sufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use this tool: 'Use to correct persistent yaw drift if trim sticks or acc trim are not sufficient.' It does not list exclusions or alternatives directly, but the condition is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It correctly identifies it as a read operation and specifies the data type, range, and default value. However, it lacks disclosure of potential side effects (none expected) or safety guarantees, though the description is adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded. It states the purpose in the first clause and inline provides type, range, and default without extraneous words. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema and zero parameters, the description is fairly complete. It explains the value's meaning and numeric constraints. It could mention that it is a read-only setting, but the verb 'get' implies that already. Overall, sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so there is no need to explain parameter semantics. Schema coverage is 100%, and the baseline for parameter-less tools is 4. The description adds value by defining the returned value's meaning and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the maximum attitude angle before horizon mode enforces leveling. It uses a specific verb ('get') and resource ('horizon_limit_degrees'), and the purpose is unambiguous, distinguishing it from sibling setter and other horizon getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives. While it is a straightforward getter, it does not mention when to prefer it over other horizon-related getters or the corresponding setter. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses unit, type, default, and requirement, but lacks details on behavior when requirement is not met or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with additional useful note. No extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Fairly complete for a simple getter with no parameters; includes default and requirement. Could mention that it's a read-only parameter and that a setter exists (set_i2c2_clockspeed_khz) but not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters; baseline 4. Description adds value by stating default value and requirement beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets the I2C bus 2 clock speed in kHz. Distinguishes from siblings like get_i2c1_clockspeed_khz by specifying bus 2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a requirement (USE_I2C_DEVICE_2) which implies when the tool is available, but does not explicitly state when not to use or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It correctly indicates a read operation but does not disclose potential behavioral traits like latency, connection status, or that it reads a flight controller parameter. It is minimally adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus a brief note on type and default. Every word adds value. No unnecessary fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description explains the meaning and effect of the value. It provides type and default but omits the allowed range (0-255) and whether the value is dynamic. Still, it is fairly complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is trivially 100%. The description adds meaning by explaining the parameter's purpose and effect on OSD smoothness, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the resource (ibat_lpf_period) and its function: 'LPF period for the displayed current reading.' It also clarifies the effect ('Higher = smoother OSD current display') and provides type/default. This distinguishes it from sibling getters like get_vbat_display_lpf_period which is for voltage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when one wants to read the LPF period for current display, but it does not explicitly contrast with alternatives or provide when-not-to-use guidance. No mention of the corresponding setter tool exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates a read operation and details the parameter type, range, default, and meaning of 0. No side effects or permissions mentioned, but adequate for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parameter name, description, usage context, and range specification. Front-loaded and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, description covers parameter identity, type, range, default, and behavioral meaning. Sufficient for agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters, so baseline is 4. Description adds rich context: meaning as accelerometer threshold, range [0-250], default 0, and tie to features. Exceeds baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the landing_disarm_threshold parameter, defines it as accelerometer impact threshold for auto-disarm on landing, and relates it to GPS Rescue and EZ Landing features. Distinct from siblings by specific parameter name.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. Among many get_* siblings, no context provided for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral info. It discloses the setting type and default (UINT8, default OFF) but doesn't explicitly state the return type or side effects. As a getter, behavior is simple, but the description could be more precise about the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with a single sentence plus a parenthetical, front-loaded with the tool name and purpose. No redundant information or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with no parameters, annotations, or output schema, the description provides sufficient context: what the setting does, when it's relevant, and its data type/default. It could optionally state that it returns the current value, but 'Get' implies that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so description adds value by describing the setting as UINT8 with default OFF. This informs the agent about the nature of the returned value, going beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the motor_pwm_inversion setting and explains its purpose (invert PWM output polarity). It distinguishes itself from the sibling setter tool by naming convention and verb usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a usage context ('For ESCs that require inverted signal') but lacks explicit guidance on when to use this vs alternatives like set_motor_pwm_inversion. No when-not or exclusion criteria are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the tool clamps PID output and is a getter, mentions UINT16 type and default. However, it doesn't disclose other traits like side effects (none expected) or rate limits. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a bracket note. No wasted words. Front-loaded with purpose. Very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is fairly complete. It explains the value and gives a use case. Could explicitly state 'returns current setting' but still sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds no param semantics (not needed). The baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the pidsum_limit value that clamps total P+I+D output. It distinguishes itself from siblings like 'get_pidsum_limit_yaw' and 'set_pidsum_limit'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a hint about setting to 1000 during tuning, implying when you might check the value, but doesn't explicitly state when to use this getter vs alternatives. No clear when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adds context by specifying the data type (UINT8), default value (0), and special meaning (0 = auto). It does not disclose side effects or permissions, but for a read-only tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and efficient, conveying all essential information in a single sentence. No wasted words, though it could be slightly more structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and empty input schema, the description fully explains what the tool returns: a UINT8 representing the cutoff, with 0 meaning auto. This is complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description adds meaning by explaining the parameter value type and its interpretation (manual cutoff, auto when 0).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the manual setpoint smoothing cutoff value. It distinguishes itself from siblings like 'set_rc_smoothing_setpoint_cutoff' and other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is used to read the current cutoff value, and notes that 0 means auto. However, it does not explicitly state when to use it over alternatives like the setter or other RC smoothing parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the character triggers a reboot when sent to the FC, which hints at the significance, but does not explicitly state that this is a read-only getter with no side effects. The type and range information is helpful but could go further.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two short sentences that front-load the purpose. It is mostly efficient, though the default value is mentioned twice ('default: R' and then the numeric default 82). This slight redundancy prevents a perfect score, but overall it is clear and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks an explicit statement about the return value format (e.g., returns a single character or a string). It also does not mention that this is a configurable setting linked to set_reboot_character. Given no output schema, more detail on the output would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no parameter information to add. With 0 parameters and 100% schema coverage, the baseline is 4. The description effectively explains what the tool does without needing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get reboot_character: ASCII character that triggers a reboot...' which combines a specific verb ('Get') with a specific resource ('reboot_character') and explains its purpose. Among many getters, this one is uniquely identifiable. The inclusion of the default value and range further clarifies the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates read-only retrieval via the verb 'Get', and the sibling set_reboot_character exists for writing. However, it does not explicitly state when to use this tool versus alternatives or any prerequisites. The context of many getters/setters provides indirect guidance, but explicit usage notes are missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly implies a read-only operation via 'Get'. It also adds behavioral details by specifying the value range and default, which helps the agent understand what to expect. Negative behaviors like side effects or auth needs are not applicable for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracket-format detail. It is front-loaded with the tool name and purpose, and every part adds value. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a parameter-less getter with no output schema, the description is nearly complete. It explains the purpose, value range, and default. It could mention the unit (Hz) explicitly, but it is clear from the name. Overall, sufficient for an agent to understand and use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the input schema is empty. The description adds significant value by providing the data type, range, and default value, which are not present in the schema. This helps the agent interpret the returned value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as getting the 'rpm_filter_lpf_hz' parameter, explains it is a 'post-notch smoothing LPF applied to the RPM signal used for notch tracking', and provides the data type (UINT16), range (100-500), and default (150). This distinguishes it from other RPM filter parameters like get_rpm_filter_q or get_rpm_filter_harmonics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, such as other RPM filter getters. However, the name and context imply it is a simple read operation for a specific parameter. No guidance on when not to use it or relationships with sibling tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the prerequisite and the data type/range, which implies a read operation. However, it does not explicitly state that the tool is read-only, nor does it mention potential side effects or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a parenthetical constraint. It front-loads the key information (Get + what it is) and then adds necessary details. Every sentence adds value with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter getter, the description provides data type, range, and default, which helps the agent understand the return value even without an output schema. The behavioral context is adequate, though it could explicitly state the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, and schema description coverage is 100% (vacuous). According to guidelines, baseline is 4 when there are no parameters. The description does not need to add parameter info, and the provided data type/range is sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the D gain for the RPM limiter controller. It distinguishes from sibling tools like get_rpm_limit_i and get_rpm_limit_p by specifying the gain component. The name and description together unambiguously convey the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite USE_RPM_LIMIT but does not explicitly guide when to use this tool versus alternatives like get_rpm_limit_p or get_rpm_limit_i. The context implies this is for reading the D gain parameter, but no explicit contrast or situational advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description partially compensates by indicating a read operation with data type/range/default. Missing details on error behavior when USE_RPM_LIMIT is disabled or safety implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence for purpose, one parenthetical for requirement and data format. No wordiness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides essential info (purpose, prerequisite, type/range/default). Could improve by clarifying return format or distinguishing from get_rpm_limit_value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (trivially 100% coverage), so baseline is 4. Description adds value with range '[0–100]' and default '25', which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'rpm_limit_p: P gain for RPM limiter controller', differentiating it from its set counterpart among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the prerequisite 'Requires: USE_RPM_LIMIT', implying when to use. However, it lacks explicit guidance on when not to use this tool versus alternatives like set_rpm_limit_p.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description discloses the default value and meaning of 0, but does not specify return format, potential errors, or side effects. Adequate for a simple getter but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with two sentences covering all essential information. No unnecessary text, well front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description effectively conveys the tool's function and a special value meaning. Could mention return type explicitly, but sufficient for this simple case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, schema coverage 100%). The description adds context about the returned value being an AUX channel and the significance of 0, exceeding the baseline expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the rssi_channel, which is an AUX channel carrying the RSSI signal. It also explains the meaning of value 0. This explicitly distinguishes it from siblings like set_rssi_channel.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a simple getter but does not provide explicit guidance on when to use this tool versus alternatives like get_rssi_scale or set_rssi_channel. Context helps but lacks explicit when-to-use or when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations present, so description carries full burden. It discloses the operation type (get), data type (UINT8), valid range (0–100), and default value (20). No side effects mentioned, but as a read-only getter, this is adequate. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with an appended type/range/default in brackets. Every part is informative and necessary. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully covers the purpose, return value type, range, and default. No missing information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description adds no parameter info, but none is needed. Baseline of 4 applies because the tool requires no parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves a specific threshold value for runaway protection deactivation. The description explains what the value represents (throttle percentage for deactivation). While the name is unique among siblings, no overt comparison is made, but the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when to use or when not to use. However, as a getter for a configuration parameter, the use case is self-evident: to read the current threshold. The sibling 'set_runaway_takeoff_deactivate_throttle_percent' exists, implying usage for reading vs writing, but this is not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral info: returns a UINT8 with default 100. However, it does not disclose any other traits such as range or side effects. As a simple getter, the transparency is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes essential information (action, resource, type, default). No unnecessary words, very concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the key aspects: what it gets, the type, and default. It could explicitly state the range (0-255) but 'UINT8' implicitly conveys that. Adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the empty schema by specifying the type (UINT8) and default value, providing useful context for a parameterless tool. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and the specific resource ('simplified_dterm_filter_multiplier'), and adds context ('D-term filter cutoff scaling slider') that distinguishes it from other get_* tools. It also provides type and default value, enhancing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The usage is implied (read the current multiplier), but no when-not-to or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that this is a read operation (Get) and provides type/range (UINT8, default 100). However, it does not mention side effects or safety profile; for a simple getter this is adequate but minimally informative beyond the obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with type info appended. It front-loads the tool name and provides no unnecessary details. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description explains what the returned value represents and its context within simplified PID tuning. It could mention relation to other gains, but is sufficiently complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100% by default. The description adds value by explaining the meaning of the retrieved value (additional D multiplier for pitch) and its type/default, which is essential context since the schema itself is empty.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the simplified_pitch_d_gain, an additional D multiplier for pitch only. This distinguishes it from siblings like get_simplified_d_gain (general D gain) and get_simplified_pitch_pi_gain (pitch PI gain).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies it is for reading the pitch-specific D gain, but does not explicitly state when to use it versus alternatives or provide any 'when not to use' guidance. The presence of set_simplified_pitch_d_gain suggests the getter is for reading, but no direct comparison is made.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation ('Get') and notes the type (UINT8) and default value (0), but does not disclose any side effects or permissions. The info adds some value but is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with the purpose, followed by a prerequisite and type/default info. Every part is meaningful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and many siblings, the description is sufficient: it identifies the resource, states a requirement, and gives the type and default. It lacks explicit mention of return behavior, but the name implies it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100%. The description adds value by stating the return type and default, which is beyond the empty schema, though not directly about parameters. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get s_yaw: S-term for yaw.' It identifies the specific resource (S-term for yaw) and uses the verb 'Get', distinguishing it from siblings like get_s_pitch and get_s_roll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite ('Requires: USE_WING'), giving context for when the tool is applicable, but does not specify when to avoid it or compare to alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds the requirement `USE_ADVANCED_TPA`, which is behavioral context. It does not explicitly state read-only behavior, but 'get' implies it. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, front-loaded with the name and purpose, and includes a requirement note without extra fluff. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the value options, default, and a requirement. It does not explain TPA broadly, but that is acceptable for a single parameter getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description need not explain them. It adds value by specifying possible values (CLASSIC/HYPERBOLIC) and a default (CLASSIC).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the TPA curve type with two specific values (CLASSIC, HYPERBOLIC) and their meanings. This distinguishes it from sibling getters like get_tpa_breakpoint or get_tpa_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when you need the current TPA curve shape, but provides no explicit when-not-to-use or alternative guidance. The requirement hint is helpful but limited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states it's a read operation and provides type/default info, but does not disclose any side effects, required connection state, or other behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with one sentence plus inline type/default info. Every part is essential with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read operation with no parameters or output schema, the description is complete enough, providing the value type and default. It doesn't explain the TPA concept, but that is acceptable for a configuration parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage). The description adds meaning by stating the value type and default, which is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the throttle level below which TPA Low applies, specifies the data type (UINT16) and default value (1050), distinguishing it from related siblings like get_tpa_breakpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading the TPA low breakpoint parameter but provides no explicit guidance on when to use it versus alternatives or any prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the data type (UINT16) and default value (1000), which adds some transparency. However, it does not disclose side effects, permissions, or whether the operation is read-only. The 'get' prefix implies reading, but without annotations, more context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line that efficiently conveys the core information: the resource, action, unit, requirement, and metadata. It is front-loaded and contains no superfluous words, making it easy for an AI agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential aspects: what is retrieved, the unit, the model, a prerequisite, and the data type with default. It does not explain domain terms like 'TPA' but that is acceptable. The description is sufficiently complete for a simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to explain parameter semantics. With no parameters, a score of 4 is appropriate as the baseline, and the description does not need to add anything beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the craft mass (g×0.1) for the ADVANCED speed TPA physics model. It identifies the specific resource and action, and differentiates from sibling tools by specifying 'ADVANCED' and the 'mass' parameter, along with the prerequisite 'USE_WING'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires: USE_WING'), which provides some guidance on when to use the tool. However, it does not explicitly state when to use this tool versus alternatives like get_tpa_speed_adv_drag_k or the set counterpart, nor does it mention that this is for reading only. The usage context is partially addressed but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states 'Get' which implies read-only, and describes the returned value type and default, but does not explicitly confirm no side effects or other behavioral traits. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, containing only one sentence plus a type annotation. It front-loads the purpose and wastes no words. Every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter retrieval tool with no parameters and no output schema, the description provides sufficient context. It explains what the tool does and what the returned value represents. A brief mention of the role in voltage divider configuration could enhance completeness, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so baseline is 3. The description adds value by explaining that the tool returns a UINT8 with a default of 1, clarifying the nature of the retrieved value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the vbat_multiplier parameter, using the verb 'Get' and specifying the resource. It adds context ('Voltage divider ratio multiplier') that distinguishes it from other get_ tools. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., set_vbat_multiplier). However, the 'Get' prefix strongly implies a read operation, and the sibling naming convention provides implicit guidance. Some agents might benefit from explicit when-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It indicates a read operation (get) but does not disclose any additional behavioral traits such as side effects, authentication needs, or return format details. The transparency is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise with two sentences—one for purpose and one for unit/default. It front-loads the key information without extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description explains the value and its default, which is fairly complete for a simple getter. It could mention it's a configuration parameter, but overall it provides necessary context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds value by explaining the return value meaning, unit, and default, which is adequate since no parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the warning threshold voltage per cell, specifies the unit (×0.01V), and provides the default value. The verb 'Get' and resource 'vbat_warning_cell_voltage' are explicit, distinguishing it from the 'set_' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. The name implies a read operation, but no guidance is given on context or prerequisites. It relies on user inference for usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It discloses the tool is a setter for a filter parameter and describes the trade-off, but does not mention side effects, persistence, or if a reboot is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with the range and default in brackets. No wasted words; all information is front-loaded and essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one input and no output schema, the description covers the core purpose, effect, range, and default. It could mention whether changes take effect immediately or after reboot, but overall it is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully describes the parameter (type, range), but the description adds the default value (300) and the unit (Hz×10), which are absent from the schema. This provides meaningful extra context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a low-pass filter cutoff for altitude estimate, specifying the unit (Hz×10) and effect (smoother but laggier). It uniquely identifies the resource ('altitude_lpf') and distinguishes it from many sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adjusting altitude filter smoothness but does not explicitly state when to use this tool versus alternatives (e.g., other filter settings). No prerequisites or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds value by specifying parameter type, range, and default beyond the schema. Does not disclose side effects or error conditions, but for a simple setter, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with inline key details (parameter type, range, default, and requirement). Front-loaded and compact with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and simple parameter, the description is complete. It tells what it sets and the required feature. Could mention if a reboot is needed, but not essential for a parameter setter among many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already covers parameter with description, min, max. Description adds 'UINT8' type and default value, but no additional semantic depth beyond the schema's structured data.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the I2C bus number for the barometer, specifying the parameter is UINT8 with range 0-5 and default 0. This distinguishes it from siblings like 'set_baro_i2c_address' which sets the address.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly notes the requirement 'USE_BARO' feature, indicating when the tool is applicable. Implicitly contrasts with getter sibling. Lacks explicit when-not-to-use or alternative tools, but context is clear among similar set_ tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits such as whether the setting persists, is immediately applied, or requires a reboot. For a simple setter, it lacks transparency about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence plus a parenthetical with constraints. Very concise, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description is fairly complete: it explains the parameter, range, default, and purpose. Could mention persistence or effect timing, but not critical.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds context: unit (mAh), range, default value, and explains the purpose (used with current meter). This goes beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the battery capacity in mAh, a specific resource, and explains its role in estimating remaining charge with a current meter. It distinguishes itself from siblings by focusing on capacity value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context that it is used with a current meter, implying when it is relevant, but does not explicitly exclude alternatives or specify when not to use it. Sibling tools like set_battery_meter handle other aspects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does disclose the parameter's effect (sets a rate limit), but does not mention whether the setting persists or requires a save/reboot, or any side effects. The disclosure of the range and default is helpful but incomplete for full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with the key information (action, resource, units, special value, range, default) presented clearly. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description covers the essential aspects: purpose, parameter meaning, range, units, special value, and default. Missing a mention of persistence or side effects, but for a simple setter this is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds semantic value beyond the input schema by explicitly stating that '0 = unlimited' and providing the default value. The schema already covers the range and description, so the added context about the special meaning of 0 and the default enhances understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the rotation rate limit during crash flip mode, specifying units (degrees/s) and the special value 0 meaning unlimited. The verb 'Set' and resource 'crashflip_rate' are precise, and it distinguishes from the many sibling set_* tools by focusing on this specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when configuring crash flip behavior, but lacks explicit guidance on when to use this tool versus alternatives like get_crashflip_rate or related set_crashflip_* tools. It would benefit from a note that this is for setting the rate limit specifically.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behavioral traits: active in smooth flight, damping behavior, boosting toward d_max_roll on fast moves. No annotations are present, so description carries the full burden, and it does so well, though no mention of side effects or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (four short sentences), front-loaded with action and resource, every sentence adds value (function, context, type, default). No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes the tool's purpose and behavior for a PID setter; includes type and default. Missing explicit valid range (0–255) which is inferable from UINT8 but not stated, and no units or scaling info.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with basic description; tool description adds contextual understanding of d_roll's role but no additional detail about the parameter itself beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly identifies the tool as setting d_roll (a PID parameter), explains its function ('damps rate of change, counters P overshoot and propwash'), and distinguishes it from related tools like set_d_max_roll by describing it as the base D that interacts with d_max_roll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage context (adjusting base D gain for roll axis) but lacks explicit when-to-use, when-not-to-use, or comparisons with alternative tools like set_d_pitch or set_d_max_roll.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses the effect (narrowness of notches) and includes practical limits (max useful value ~1000) and default (300). However, it does not mention side effects, persistence, or whether reconnection is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single efficient sentence with a bracketed format note. It is front-loaded with purpose and provides all necessary information without extra words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with no output schema, the description covers the action, parameter meaning, tuning advice, and valid range. It is nearly complete, though it lacks prerequisites or persistence details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with type and range. The description adds tuning guidance and a practical upper bound, which is valuable beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'dyn_notch_q', and explains it as 'Q factor — narrowness of each notch'. This distinguishes it from sibling tools like get_dyn_notch_q or set_dyn_notch_count.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides tuning guidance ('Increase until the resonance just stays within the notch, then stop') but does not explicitly state when to use this tool over alternatives like set_dyn_notch_count or set_dyn_notch_min_hz.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the behavioral effect on re-arming and stick input assessment, but does not disclose side effects, persistence, or required permissions. Slightly better than minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the purpose. No filler words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple parameter setter with no output schema, the description covers the parameter's role in failsafe stages, re-arming, and GPS Rescue. It includes range and default. Minor gap: no mention of when changes take effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description, but the tool description adds meaning by explaining the parameter's effect in the failsafe flow and provides the default value (5 = 0.5s), which is not in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the failsafe_recovery_delay parameter and explains its meaning in the context of failsafe Stage 2, re-arming, and GPS Rescue. It distinguishes from other failsafe-related tools like set_failsafe_delay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when the parameter applies (after Stage 2) but does not explicitly state when to use this tool versus alternatives. No exclusionary guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must explain behavioral effects. It does explain the effect on FF signal and I-term, but it does not disclose whether the change is immediate or requires reboot, nor does it mention any side effects or dependencies. It provides range and default, which adds some transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining the function and a bracket with range and default. Every element adds value without redundancy. It is front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single parameter, no output schema), the description covers the essential aspects: purpose, effect, valid range, and default. It could mention if a reboot is needed, but overall it is sufficiently complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context beyond the schema: it explains the purpose of the parameter (counteracting I-term under-yaw), which is not in the schema's description. This aids understanding of when to adjust this value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set feedforward_yaw_hold_gain' and explains the resource's function: 'Sustains a residual FF signal in yaw after the stick is released, counteracting I-term under-yaw.' This distinguishes it from sibling setters like set_feedforward_yaw_hold_time, which target a different parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description implies the tool is for tuning yaw hold behavior, it does not explicitly state when to use it versus alternatives (e.g., when to adjust gain vs time). No exclusions or prerequisites are mentioned, but the purpose is clear enough for basic usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions scaling behavior and default value but does not disclose side effects, persistence, or prerequisites. Adequate for a simple parameter setter but could be richer.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus bracketed type/default. Front-loaded with purpose. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, description covers purpose, related scaling parameter, and default. Missing units or range beyond schema, but complete enough for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides basic description. Description adds that it's UINT16 with default 120 and scaling by simplified_feedforward_gain. Since schema coverage is 100%, baseline is 3; extra context raises it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets feed forward for roll, compensates for stick input lag, and is scaled by a specific slider. Differentiates from siblings like set_f_pitch and set_f_yaw by specifying axis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage for tweaking roll feedforward but lacks explicit when-to-use or when-not-to-use guidance. No alternatives mentioned, though context implies it's part of PID tuning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses a key behavioral trait: if the quad is already above the target altitude, it maintains current altitude. This adds significant value beyond a simple parameter set. No annotations exist to contradict or complement this.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a concise bracket note. Front-loaded with purpose and efficient, every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter set tool with one parameter and no output schema, the description covers purpose, behavior nuance, and parameter details. Missing info about when the setting takes effect (e.g., immediate or after reboot) but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the single parameter. The description adds the default value (30) not present in schema, enhancing understanding of the expected range and typical value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the GPS rescue return cruise altitude and adds behavior description ('If the quad is already above this, it maintains current altitude'), distinguishing it from generic setter tools. The purpose is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus other set_gps_rescue_* tools (e.g., set_gps_rescue_alt_mode, set_gps_rescue_ascend_rate). Does not mention prerequisites like being disarmed or in configuration mode.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It mentions the type (UINT16) and default value, but lacks information on persistence (whether changes survive reboot), whether a reboot or arming is required, or any side effects. The schema's huge integer range contradicts the UINT16 claim, but the description does not clarify the actual valid range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus a type/default note. It is front-loaded with the purpose and every sentence serves a clear function with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one parameter and no output schema, the description covers the essential purpose, usage tip, and default value. Minor omissions include units and persistence behavior, but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so baseline is 3. The description adds a default value and context about the parameter's role as a dynamic cutoff frequency, but does not specify units (likely Hz) or provide additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the gyro_lpf1_dyn_min_hz parameter, specifies it's the dynamic LPF1 minimum cutoff at low throttle, and distinguishes from static mode by advising to set equal to gyro_lpf1_static_hz. This differentiates it from sibling tools like set_gyro_lpf1_dyn_max_hz and set_gyro_lpf1_static_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage tip: set equal to static_hz for static mode, indicating when to use this tool versus static mode. However, it does not explicitly compare with alternatives like set_gyro_lpf1_dyn_max_hz or explain when to adjust the minimum cutoff.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It mentions data type, default, and valid range but does not disclose whether changes take effect immediately, require reboot, or any side effects. Adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with essential details (type, default, range). No superfluous words. Ideal length for a simple parameter setter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers the parameter meaning, range, and default. Missing guidance on when to use this notch vs others, but overall adequate for the task.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Description adds meaning beyond the input schema: defines the value as centre frequency, explains that 0 disables the notch, and states the default. Schema only says 'Value for gyro_notch2_hz (UINT16)'. Good added context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set' verb and resource 'gyro_notch2_hz', defines it as 'Centre frequency of static gyro notch 2', and specifies valid range (0 = disabled) and type (UINT16). Differentiates from siblings by naming the specific notch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like dynamic notch or other static notches. The description is functional but lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the effect on flight behavior (delays return-to-level) and specifies valid range and default, but does not mention whether changes require reboot, persist, or if any state dependencies exist. Adequate for a simple parameter setter but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences: action + explanation + technical details. It front-loads the purpose and provides all necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool is a simple parameter setter with one parameter and no output schema, the description is reasonably complete. It covers purpose, effect, and valid range. Lacks mention of any runtime constraints (e.g., if settable while armed), but overall sufficient for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, setting baseline at 3. The description adds significant value beyond the schema by explaining the behavioral impact (more acro-like feel) and the range/default values, whereas the schema only provides minimal type/range info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (set horizon_delay_ms), explains the parameter's function (time before horizon mode re-applies leveling after sticks return to center), and its effect (more acro-like feel). It distinguishes itself from sibling set_* tools by naming the specific parameter and its role in horizon mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for adjusting horizon mode behavior but provides no explicit guidance on when to use this tool versus alternatives (e.g., set_horizon_ignore_sticks, get_horizon_delay_ms). No when-not or prerequisite information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden. It discloses the prerequisite and default, but does not mention whether the change requires a reboot, is persistent, or any side effects on other buses or devices.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with appended specification in parentheses. It is concise and front-loaded, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter of a numeric parameter, the description is mostly complete with purpose, prerequisite, type, and default. Missing details like persistence or effect timing, but these are not critical for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter. The description adds type (UINT16) and default value (800), which is not present in the schema's description (only says integer).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'I2C bus 1 clock speed in kHz'. It distinguishes from sibling tools like set_i2c2_clockspeed_khz by specifying bus 1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (USE_I2C_DEVICE_1) and default value, but provides no explicit guidance on when to use this tool versus alternatives or any conditions for changing the clock speed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions requirement and default but does not disclose if changes take effect immediately or require reboot, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a note. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with no output schema, the description adequately covers purpose, requirement, and default. Minor gaps: no valid range or immediate/reboot behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter described). The description adds the default value (800) and type (UINT16), providing useful context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description clearly state it sets I2C bus 3 clock speed in kHz. The description includes the unit and distinguishes from siblings for bus 1 and 2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement USE_I2C_DEVICE_3 is mentioned, providing a prerequisite. However, it does not explicitly compare with alternatives for bus 1 or 2 or advise on when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the requirement for USE_VIRTUAL_CURRENT_METER, implying it may fail if not enabled. However, lacks details on side effects, persistence, or need for reboot. No annotations to rely on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single line with all essential information: purpose, prerequisite, type, range, and default. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers prerequisites, value constraints, and default. Missing info on return value (e.g., success indication) but acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds default value (0) not present in schema, providing extra context. Also repeats range and type for clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets the ibatv_offset (virtual current sensor voltage offset). Includes prerequisite and value range. Very specific and distinct among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies a prerequisite (USE_VIRTUAL_CURRENT_METER) but does not provide guidance on when to use this tool vs other set_* tools like set_ibata_offset. No alternatives mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the parameter type, range, and default, and explains the blending behavior. However, it does not mention side effects, whether changes are immediate or require a reboot, or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Key information (purpose, effect, default, range) is front-loaded and clearly presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description covers the parameter's purpose, range, and default. It could mention the corresponding get tool (get_imu_dcm_kp) for completeness, but overall is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one param fully described). The description adds value by repeating the range and default in a human-readable form and explaining the parameter's role, going beyond the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the complementary filter proportional gain, explains its effect (blending acc data with gyro integration), and provides range/default. This distinguishes it from other set_* tools by specifying a unique parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Default is suitable for all normal use,' implying when to keep the default, but does not explain when a user might need to adjust the value or compare to alternatives. No exclusions or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral transparency burden. It explains the effect of higher vs lower values and gives a troubleshooting scenario, but does not mention side effects, permissions, or that setting takes effect immediately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is reasonably concise, but could be structured with bullet points for easier scanning. It front-loads the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description covers purpose, effect, typical ranges, and a troubleshooting scenario. It is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context beyond the schema: typical ranges per flying style and a tuning step-down procedure. This helps the agent select appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'iterm_relax_cutoff', and explains it is the cutoff frequency for the I-term relax HP filter. This distinguishes it from sibling tools like get_iterm_relax_cutoff and set_iterm_relax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides typical ranges for different flying styles (Racing, Freestyle, etc.) and a troubleshooting step for bounce-back or oscillation. However, it does not explicitly compare with sibling tools like set_iterm_relax or set_iterm_relax_type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the range and default value, but does not mention persistence across reboots, required configuration mode, or side effects on other settings. Basic behavioral context is present but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exceptionally concise, consisting of two clear sentences and a compact bracketed range/default specification. Every word contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setter with a single required integer parameter and no output schema, the description covers essential information: purpose, role, range, units note, and default. It could mention that this is a persistent configuration parameter but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value by providing the default value (550) which is not in the schema, enhancing the agent's understanding of typical values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Set') and the specific resource ('motor_idle'). It explains that it sets the idle throttle value sent to ESCs when armed and is used as the minimum non-zero motor command, effectively distinguishing it from sibling tools like get_motor_idle and motor_set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context about when the value is used (when armed) and its purpose (minimum non-zero command), but does not explicitly explain when to use this tool versus alternatives like set_min_command or set_motor_pwm_rate. No exclusions or alternatives are mentioned, leaving usage decisions somewhat ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description discloses that the tool clamps yaw PID output and mentions default/tuning values, but does not cover side effects like whether changes take effect immediately or require reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences front-loading purpose and usage. No extraneous text, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter, the description is adequate: explains function, default, and tuning use. Lacks mention of persistence or immediate effect, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value beyond schema by recommending specific values ('Set to 1000 during initial tuning') and stating the default, aiding parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the pidsum_limit_yaw parameter, which clamps total yaw PID output. It distinguishes from siblings by specifying 'yaw' and provides context with default and tuning values.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage guidance: 'Set to 1000 during initial tuning; default 400 limits yaw authority.' However, it does not explicitly compare to set_pidsum_limit (generic) or state when not to use this tool, lacking alternative differentiation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully convey behavior. It provides the data type (UINT16), valid range (0-100), and default value (8), plus a required condition. It lacks details on whether the change takes effect immediately, requires a save/reboot, or impacts other parameters. The information is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence with structured parenthetical additions. It front-loads the purpose immediately, then appends the requirement and parameter spec. Every element adds value, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description covers the essential aspects: purpose, range, default, and a prerequisite. It could mention persistence or application (e.g., 'applied immediately' or 'requires a save'), but given the low complexity and common patterns in sibling tools, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds the default value (8) and the requirement (USE_RPM_LIMIT), which are not in the schema. This extra context helps the agent understand the parameter's typical value and preconditions, going beyond the schema's min/max and basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets the 'D gain for RPM limiter controller' with a specific verb+resource. The tool name includes the parameter suffix (_d), distinguishing it from siblings like set_rpm_limit_i and set_rpm_limit_p, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (USE_RPM_LIMIT), which hints at when the tool is effective. However, it does not explicitly state when to use this tool versus alternatives (e.g., when adjusting I or P gains), nor does it provide guidance on typical usage scenarios. The guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a write operation ('Set') and provides the parameter range and default, but does not disclose whether changes take effect immediately, require a save/reboot, or have any side effects. Since no annotations are present, more behavioral context would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a bracketed specification, conveying all essential information without unnecessary words. It is front-loaded with the key action and resource name, then provides additional context efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one input and no output schema, the description covers the core semantics, range, and default. It lacks details on persistence or immediate effect, but is largely complete for an agent to use the tool correctly in most contexts.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaningful context: it explains that the value represents a time delay after arming and provides the default (500). The schema parameter description is generic ('Value for...'), so the description improves semantic understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the verb 'Set' and the resource 'runaway_takeoff_deactivate_delay', and defines it as 'Time after arming before runaway takeoff protection stops monitoring.' This provides a specific and unambiguous purpose, clearly distinguishing it from other setter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. Given the large number of sibling tools (especially other runaway takeoff settings), some context on typical use cases or exclusions would be helpful. However, the purpose is clear enough for an agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It reveals that the tool sets a configuration parameter, the data type (UINT16), default (0 per profile), and prerequisite. However, it does not disclose side effects, permission requirements, or whether changes take effect immediately or after reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with parenthetical notes. It is concise, front-loaded with the action, and every piece of information serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is fairly complete: it explains the effect, prerequisite, and default. Could mention value validation or range limits, but it's adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'value' with generic description. The tool description adds meaning by explaining that this value sets the range over which attenuation ramps, clarifying the parameter's purpose beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Set spa_roll_width) and explains its purpose: 'Setpoint range over which attenuation ramps from 0 to full (roll).' It is distinct from siblings like get_spa_roll_width.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires: USE_WING'), but does not provide guidance on when to use this tool vs alternatives or when not to use it. Sibling tools include many set_ parameters, but no direct alternative is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
As a setter, the description indicates a configuration change. However, it does not disclose side effects, persistence, or permissions. Given no annotations, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional range/default information in brackets. No unnecessary words, efficiently communicates the tool's purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple integer parameter setter, the description covers purpose, range, and default. It does not mention related settings or group context, but that is acceptable for a focused tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds the default value (15) and context that it's an LPF cutoff for throttle derivative, beyond the schema which only states the parameter's type and range. This provides useful information for parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets throttle_boost_cutoff, explains it's an LPF cutoff for throttle derivative used by throttle_boost, and provides type and range. This distinguishes it from siblings like set_throttle_boost.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for tuning throttle response but does not explicitly state when to use this tool over other throttle-related settings. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It explains the functional difference between OFF and ON (active only before Airmode vs. throughout flight) and notes the default. However, it omits potential side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is remarkably concise, using three short sentences to convey purpose, behavior, and type information without superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set tool with one parameter and no output schema, the description covers the essential meaning and effect. It could be slightly more complete by listing exact valid values, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%. The description adds some context (UINT8, default OFF) but does not explicitly list valid string values like 'ON' and 'OFF', which would be helpful. It repeats information already in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets 'tpa_low_always', explains the meaning of OFF and ON, and distinguishes it from many sibling 'set_*' tools by specifying exactly which parameter is being set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the effect of the two states but does not provide explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It indicates that the tool sets a throttle level and provides the default value and type, but does not disclose side effects, persistence, or whether a reboot is required. For a simple numeric setter, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences that cover the verb, resource, meaning, type, and default. Every piece of information is relevant, and there is no extraneous text. It is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is fairly complete. It could be enhanced by mentioning how it relates to other TPA parameters like set_tpa_breakpoint or set_tpa_rate, but it still delivers the essential information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value beyond the schema by stating the default value (1050) and clarifying the parameter's role in TPA Low application, which is not present in the schema's description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'tpa_low_breakpoint', and explains what the parameter controls ('Throttle level below which TPA Low applies'). This distinguishes it from siblings like set_tpa_breakpoint, which set a different threshold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool or when not to, nor does it mention alternatives. The purpose is clear, but no guidance on context or conditions for invocation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral burden. It indicates the setting is a UINT8 with default OFF, implying a write operation. However, it does not disclose side effects (e.g., requires reboot) or permissions needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences plus a parenthetical note. It front-loads the action and then explains context and default. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple toggle tool with one parameter and no output schema, the description covers the purpose, default, and a use case. It lacks mention of whether a reboot is needed, but overall it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter 'value', described as 'Value for usb_hid_cdc (UINT8)'. The description adds meaning: explains the value corresponds to enabling HID+CDC and provides the default, beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'usb_hid_cdc', explains the function (use combined HID+CDC instead of pure CDC), and provides a use case (required for some OTG hosts). This distinguishes it from other set_* siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions when to use (for OTG host compatibility) but does not explicitly state when not to use or compare with alternatives like set_usb_msc_pin_pullup. Guidance is present but minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains the parameter's role and range, but does not disclose potential behavioral aspects such as persistence, interaction with other settings, or any side effects. The description is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two short sentences plus an inline specification. It is front-loaded with the tool's purpose and includes all critical information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, no output schema), the description is nearly complete. It explains the parameter's function within the warning alarm context. However, it does not mention related settings like the warning threshold itself, but this is acceptable for a focused setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the 'value' parameter is described). The description adds context by explaining the unit (tenths-of-seconds), the purpose (prevent false alarms), and the range/default, providing semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool sets the duration for which voltage must remain below the warning threshold before the alarm fires, distinguishing it from the sibling 'set_vbat_duration_for_critical' by specifying 'warning alarm'. The verb 'Set' and the resource 'vbat_duration_for_warning' are explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool by noting it 'Prevents brief-spike false alarms', but it does not explicitly compare with alternatives like 'set_vbat_duration_for_critical' or 'set_use_vbat_alerts'. No explicit 'use when' or 'when not to use' statements.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It discloses the need for the FC to be level/stationary and the ordering constraint with CLI tools. However, it does not mention potential side effects (e.g., resetting previous calibration) or whether the calibration is immediate or requires a reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first states purpose, second provides precondition and ordering note. No fluff, every sentence adds value. Front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description covers the essential behavioral context: precondition and ordering. It could mention what happens if called in wrong order or the duration, but overall it's adequate for a simple calibration tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter details. The baseline for 0 parameters is 4, and the description does not detract from this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calibrates the accelerometer and provides a precondition (level and stationary). However, it does not explicitly distinguish from the sibling calibrate_magnetometer, which could cause confusion if both are present.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear precondition (place level and stationary) and an important ordering constraint (call before CLI tools because MSP cannot be used after CLI mode). It does not explicitly say when not to use this tool, but the context is sufficient for most use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description correctly identifies this as a read operation without side effects. However, it could be more explicit about the non-destructive nature and that it returns the current setting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using three lines to convey the action, purpose, and value constraints. It is appropriately sized for a simple getter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description covers the essential information: what is retrieved and the expected range. It is slightly incomplete in not explicitly stating that the return is the current setting value, but the context is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description adds value by specifying the data type (UINT16), range (0-500), and default (25), which is useful for understanding the returned value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the accelerometer low-pass filter cutoff frequency and explains its purpose in smoothing acc readings for attitude estimation. The 'get_' prefix distinguishes it from the sibling 'set_acc_lpf_hz'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool over alternatives, such as the setter tool. The usage is implied by the 'get_' naming, but no explicit guidance on context or exclusions is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It usefully specifies the data type (INT16), allowed range (-180-360), and default value (45). However, it does not mention side effects, permissions, or that this is a read-only operation, leaving some behavioral aspects unaddressed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences and a bracket note. It is front-loaded with the tool name and purpose, then provides type/range/default in a structured format. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter getter with no parameters and no output schema, the description covers all necessary context: what the value represents, its unit, range, default, and when it is relevant. It is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the description does not need to explain parameter semantics. According to guidelines, 0 parameters warrants a baseline of 4. The description adds no param info because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the board rotation offset in yaw degrees, and distinguishes itself from siblings like get_align_board_pitch and get_align_board_roll by specifying 'yaw'. The purpose is specific and immediately understandable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'For non-standard FC mounting orientations' implies when to use this tool, but there is no explicit guidance on when not to use it or alternatives. Usage context is implied but not fully elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It clearly indicates this is a read operation, specifies the return range (0-100) and default (100), and explains the meaning of endpoints. No side effects are hinted, which is appropriate for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences conveying the purpose, range, and default in a structured format. No superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no output schema, no parameters), the description is fairly complete. It explains the value semantics and constraints. Minor improvement could mention the corresponding setter, but it's not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no input parameters, so the schema provides no information. The description fully compensates by explaining the meaning of the retrieved value, its range, and default, which is exactly what an agent needs to interpret the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'altitude_prefer_baro' value and explains what it represents (weight given to barometer vs GPS altitude). It distinguishes itself from other altitude getters by specifying its unique meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly suggests using this tool to check the current baro/GPS preference weighting, but it does not explicitly state when to use it over siblings like get_altitude or get_altitude_source. No exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It adds context by specifying the value type (UINT8), range (0–100), and default (10), but does not mention safety, side effects, or permissions. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining the parameter, followed by a requirement note and a concise bracket summary of type/range/default. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with no output schema, the description adequately explains the parameter's meaning, constraints, and prerequisite. It could be slightly improved by stating the return format explicitly, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is high (4). The description adds value beyond schema by providing the meaning, range, and default for the returned value, which helps the agent interpret the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets the 'cpu_late_limit_permille' parameter, explains it as 'CPU late task limit in permille', and describes its function ('Controls scheduler behaviour when tasks are running late'). This is specific and distinct among numerous sibling getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a requirement ('Requires: USE_LATE_TASK_STATISTICS'), which implies the tool is only relevant when that feature is enabled. However, there is no explicit guidance on when to use this tool versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool is a getter that returns the static cutoff value, but does not disclose any additional behavioral traits such as side effects, permissions, or rate limits. For a simple getter, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with key details (verb, resource, purpose, type, default). No wasted words. Front-loaded with the tool name and purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema and zero parameters, the description is nearly complete. It explains the tool's role as a secondary anti-noise stage and provides the return type and default. Could be improved by explicitly stating units (e.g., Hz) for the cutoff value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (100% coverage), so baseline is 4. The description adds value by noting the return type 'INT16' and default value '150', which helps the agent understand the tool's output without needing an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'dterm_lpf2_static_hz', explaining it is the cutoff for D-term LPF2, always static, and used as a secondary anti-noise stage. This distinguishes it from siblings like get_dterm_lpf1_static_hz and get_dterm_lpf2_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description says 'Use as a secondary anti-noise stage,' which gives a clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternatives like the primary LPF or dynamic filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states this tool reads the failsafe landing time value and provides the data type, range, and default. It implies a read-only operation without side effects. No annotations are present, so the description carries the full burden, which it meets adequately by confirming the behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a brief technical note. It is front-loaded and concise, with no redundant information. It could be slightly improved by separating the technical details for clarity, but it is effective.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (no output schema) and the presence of sibling tools, the description provides sufficient context: the parameter's type, range, and default. It could be more complete by explaining that the value is in units of 0.1 seconds (as inferred from '60 (6 s)'), but overall it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty (100% coverage). The description adds value beyond the schema by describing the returned value: UINT8 with range 0–250 and default 60 (6 seconds). This provides meaningful context about the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves 'failsafe_landing_time', which is the duration of Landing Mode Stage 2. The verb 'Get' and the specific resource make the purpose unambiguous, and it is distinct from the sibling 'set_failsafe_landing_time' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading the current failsafe landing time setting, but provides no explicit guidance on when to use this tool versus alternatives like 'get_failsafe_delay' or 'set_failsafe_landing_time'. No exclusion or conditional usage is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description effectively explains the behavior of each possible return value (DROP, AUTO-LAND, GPS-RESCUE) and notes the default. This covers the key behavioral traits for a read-only tool. However, it could mention additional context like when this setting is applied (e.g., on failsafe trigger).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly concise, using a single sentence with a list. It avoids redundancy but could be slightly more structured (e.g., separating the type/default info). It earns a 4 as it communicates effectively with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description must explain return values. It covers the three options, their behaviors, and the default. It could mention the data type (UINT8) more explicitly. For a simple getter, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined in the input schema, so schema coverage is 100%. The description adds value by explaining the meaning of the returned values. With zero parameters, the baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'failsafe_procedure' and lists the three possible values (DROP, AUTO-LAND, GPS-RESCUE) with brief explanations. The verb 'Get' directly indicates the operation, and the content distinguishes it from setter tools like set_failsafe_procedure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it provide prerequisites or exclusions. It only implicitly describes the return value. Given the large sibling list of similar getters, more guidance would be beneficial.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the behavioral effect of the parameter on failsafe behavior (disarming vs landing mode). However, it doesn't explicitly state that the tool is a read-only getter, but that is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single paragraph that is concise and informative. It could be slightly more structured, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description provides a thorough explanation of the parameter and its context within the failsafe system. It covers the value range and default, making it complete enough for an agent to understand.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by explaining the meaning of the parameter being retrieved, including its range and default, which is beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'failsafe_throttle_low_delay' parameter and explains its purpose: it controls the 'Just Drop' override where the FC disarms instead of landing mode. It distinguishes from sibling 'set_failsafe_throttle_low_delay' by being a getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this getter vs other parameter getters is given. Since it retrieves a single parameter, the context is implicit but no exclusions or alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It identifies the tool as a getter (read operation) but does not disclose any additional behavioral traits such as side effects, permissions, or rate limits. The description is adequate for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a range specification. Every sentence provides essential information without waste. The structure is clear and front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool has no parameters and no output schema, the description is fully complete. It explains what the tool gets, what the value represents, and its constraints. There is no missing information needed for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds value beyond the input schema (which has no parameters) by explaining the meaning of the returned value: 'Altitude to climb...' and providing the data type, range, and default. This helps the agent understand what the tool outputs.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool gets the gps_rescue_initial_climb parameter, describing it as 'Altitude to climb from current position before heading home.' It provides a specific verb+resource pairing and distinguishes itself from sibling tools by explaining the parameter's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by advising to set 'high enough to clear local obstacles,' which suggests the tool is used to read the current value for evaluation. However, it does not explicitly state when to use this tool versus alternatives like set_gps_rescue_initial_climb or other getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the burden of behavioral disclosure. It clarifies that this is a read operation (Get), explains the OSD behavior ('RESCUE N/A if below this'), and specifies the parameter type/range/default ([UINT8, 5–50, default: 8]). No side effects or permissions are mentioned, but for a simple getter this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the purpose in the first clause, then adds the OSD note and parameter spec efficiently. Every element earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this tool has no parameters and no output schema, the description is complete: it explains what the tool does, what the value means, how it manifests in OSD, and the valid range/default. There are no missing pieces for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (schema coverage 100%), and the description adds value by explaining the meaning of the returned value, its effect on OSD, and its constraints. Baseline for zero parameters is 4, and the description meets that by providing context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the tool gets 'gps_rescue_min_sats' and defines it as the 'minimum satellite count required to arm with GPS rescue configured'. This is specific and differentiates it from the many other 'get_*' sibling tools (e.g., get_gps_auto_baud, get_gps_rescue_return_alt) by naming the exact parameter and its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
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 other related tools like get_gps_rescue_allow_arming_without_fix or set_gps_rescue_min_sats. It implies usage for reading this specific parameter but does not frame it in context of alternatives or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It reveals the unit, range (50-3000), default (125), and trade-off (longer = more accurate). However, it does not explicitly state read-only behavior or safety implications. A score of 3 reflects adequate but incomplete behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with an inline type spec. Front-loaded with the key information (verb, resource, unit, example, trade-off). Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description fully explains the returned value: unit, valid range, default, and implication of longer duration. For a simple getter with no parameters, this is complete enough for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100% (empty schema). The description adds context about the meaning of the returned value (unit, range, default, accuracy trade-off), which is useful beyond the schema. Baseline for 0 parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the specific resource 'gyro_calib_duration'. It explains the unit (0.1s steps) and provides example (125 = 12.5s), making the tool's purpose unambiguous. Among many get_* siblings, this uniquely identifies a single parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit 'when to use' or 'when not to use' guidance is given. However, the nature of a simple getter (no parameters) and the presence of set_gyro_calib_duration sibling make usage obvious. The description implies use for reading gyro calibration duration but lacks explicit alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must convey behavioral traits. It discloses the value range (1-4) and default (2), and explains the impact on CPU load and accuracy. However, it does not mention that this is a read-only operation or any potential side effects, which is standard for getters but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: two sentences plus a technical specification in brackets. It efficiently conveys the purpose, meaning, range, default, and trade-off. One sentence could be slightly more polished, but overall well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter retrieval tool with no parameters and no output schema, the description is complete. It covers what the value is, its range, default, and practical implications. No additional information is needed for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, so the description provides all necessary semantic context. It explains what the retrieved value represents, its units (relative divisor), and its effect. This fully compensates for the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'imu_process_denom' parameter and explains its purpose: IMU attitude update rate divisor relative to gyro task rate. The verb 'Get' and resource are explicit, and the description distinguishes it from other getters by providing the specific parameter meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by explaining the trade-off between CPU load and attitude accuracy, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. Given that this is a simple getter with no sibling read alternatives for the same parameter, the guidance is adequate but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the effect of low and high values (drift vs slow wobble), providing insight into the behavior of the parameter. However, as a getter, it is inherently read-only, and the description does not explicitly state that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a compact type/default note. Every sentence serves purpose: naming, functional explanation, consequence of wrong values, and technical specification.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no parameters or output schema, the description fully covers what the tool returns (roll I gain) and the implications of its value. An agent has enough information to decide to use this tool and interpret the result.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist in the schema, so the baseline is 4. The description adds value by specifying the type (UINT8) and default (80), which helps the agent understand the expected value range even though no parameters are needed to retrieve it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets the Roll I gain, explains its function (corrects accumulated angle error, maintains attitude), and gives consequences of improper values. Distinguishes from sibling getters like get_p_roll or get_d_roll by naming the specific gain component.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this vs alternatives. The description implies it is for tuning the I-gain on roll axis, but doesn't mention when to adjust it relative to other PID gains.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the return type (UINT8) and default value (RP), which is useful. However, it does not explicitly state it is a simple read-only query, but that is implied by 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with essential clarifications (RP/RPY, data type, default). No redundant words, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description fully explains the configuration meaning, possible values, and default. Complete for an agent to understand its use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters, so schema coverage is trivially 100%. The description adds no parameter-specific meaning, but baseline 3 is appropriate given the schema already covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the axes on which I-term relaxation (anti-windup) is active. It explains abbreviations RP and RPY, distinguishing it from sibling tools like get_iterm_relax_cutoff and get_iterm_relax_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description implies it is for reading the current setting, but lacks context like 'use this before adjusting with set_iterm_relax' or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description effectively discloses this is a read-only getter with no side effects. It specifies the value type (UINT8) and default state, giving the agent relevant behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with essential details (purpose, type, default). Every word adds value; no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and default but omits explicit return value details (e.g., possible values are ON/OFF). For a simple getter with no output schema, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%. The description adds meaningful context by explaining what the retrieved value represents, going beyond mere parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the 'prearm_allow_rearm' setting and explains its purpose (allow re-arm without toggling prearm switch). It uses a specific verb-resource pair and distinguishes from siblings like 'set_prearm_allow_rearm'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context (checking current re-arm setting) but provides no explicit guidance on when to use vs avoid, nor contrasts with the sibling 'set_prearm_allow_rearm'. Guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It explicitly says 'Get', implying a read-only operation, and gives the value, range, and default. This is transparent for a simple getter, though it could mention that it does not modify any state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the purpose, and includes all essential details (type, range, default) without extra words. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description is nearly complete. It covers what the tool does, the data type, range, and default. It could be improved by explicitly stating the return format, but it is already effective.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds meaning by explaining what the tool retrieves and the expected value characteristics (type, range, default). This goes beyond the schema and is fully helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets 'scheduler_relax_osd' and explains it is 'Scheduler relaxation time for OSD task'. It also provides the data type (UINT16) and range (0–500) with default value, distinguishing it from siblings like get_scheduler_relax_rx by specifying 'for OSD task'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. With siblings like get_scheduler_relax_rx, the description does not help an agent decide which to use. It lacks any usage context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It indicates this is a read operation (non-destructive) but does not detail other behaviors like data flow or side effects. The description is adequate for a straightforward retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, but the first sentence is largely redundant with the tool name. The rest provides useful context and type info. Could be slightly more efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description sufficiently explains what the tool returns (the serial RX protocol) and its importance (must match receiver's output). It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description adds value by specifying the data type [UINT8] and default value [CRSF], which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get' and the resource 'serialrx_provider', defining it as the Serial RX protocol. This distinguishes it from sibling tools like 'set_serialrx_provider' and other 'get_' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by stating the value must match the receiver's output format, guiding the agent to use this tool to read the current protocol setting. It does not explicitly mention when not to use it, but the context is clear for a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates the tool is a getter returning a UINT16 value with a default. It lacks details on side effects, read-only nature, or communication overhead, but for a simple parameter getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise line that includes the purpose, prerequisite, and data type. It slightly redundantly repeats the tool name but is otherwise well-structured and free of unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters, no output schema, and no nested objects, the description provides essential information (return type, default, requirement). It is complete for this simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds context about the return type and default, which is useful. With zero parameters, a baseline of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the maximum thrust in grams for the advanced speed TPA physics model, with a specific prerequisite (USE_WING) and data type (UINT16). This distinguishes it from related siblings like get_tpa_speed_basic_delay.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly mentions the requirement `USE_WING`, guiding the agent on when to use this tool. It does not provide when-not-to-use or compare to alternatives, but the requirement is a clear usage condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description states it retrieves a voltage threshold but does not explicitly declare it as read-only, non-destructive, or disclose any permissions or side effects. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with embedded format information. Extremely concise and front-loaded with the key purpose. Every element serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value: the voltage threshold, its unit (0.01V per cell), range, and default. Complete for this simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The description adds value by explaining the scaling ('×0.01V per cell') and range ('0–2000, default: 300'), which informs understanding of the return value. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves the voltage threshold for battery connection detection. The verb 'Get' and the specific parameter name distinguish it from sibling get_vbat_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like other get_vbat_* tools. The description implies it is for reading the detection threshold but lacks usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the meaning, default value, and behavior (lower values mean faster response). This is sufficient for a read-only tool with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an explanatory phrase. It is front-loaded with the purpose and includes minimal, essential information with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a trivial getter with no parameters and no output schema, the description is complete. It explains what the value is and how it affects behavior, leaving no important gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% vacuously. The description adds useful context about the returned value (type, default, effect), but since there are no input parameters, the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the LPF period for battery sag compensation voltage measurement. The action 'Get' and resource are explicit, and the explanation of the value's effect distinguishes it from other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a simple getter with no parameters. However, no explicit guidance on when to use this versus alternatives like the set counterpart is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry behavioral disclosure. It mentions a behavioral requirement for SERIAL ('high baud rate required') but does not disclose persistence, reboot requirements, or side effects. This is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two brief lines to define purpose, valid values, default, and data type. Every sentence is necessary and adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description covers the essential semantics. However, it lacks information on whether the change is persistent, requires a reboot, or has any runtime implications. Slightly incomplete but functional.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only describes the parameter as 'Value for blackbox_device (UINT8)' without enumerating values. The description significantly adds meaning by listing the three possible values and their real-world mapping, exceeding the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set blackbox_device: Logging destination.' It lists the specific valid values (SPIFLASH, SDCARD, SERIAL) and their meanings, distinguishing it from sibling set_* tools that modify other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by naming valid options but provides no explicit guidance on when to use this tool versus alternatives or when not to use it. It does not mention any prerequisites or conflicts with other settings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the parameter's effect and safe range, but omits any side effects, persistence, or whether a reboot is required. With no annotations, more detail would be beneficial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise at two sentences, front-loads the core purpose, and includes key defaults and limits without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature and 100% schema coverage, the description is fairly complete. Lacks return value info, but acceptable for a setter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant meaning beyond the schema: explains the value represents stage 1 guard duration, default (15 = 1.5s), and minimum safe (2 = 200ms), providing crucial context the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the failsafe delay, describing it as Stage 1 guard duration from signal loss to Stage 2 activation. This is specific and distinct from the many sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on default and minimum safe values but does not explicitly guide when to use this tool vs alternatives like get_failsafe_delay or other failsafe parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the effect (acceleration component) and symptoms to address, but does not disclose whether changes are persistent or require a reboot. This is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a parenthetical with value info. It is well-structured, front-loads the purpose, and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description is complete: it explains what it does, how to tune it, and the valid range. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already describes the parameter as 'Value for feedforward_boost (UINT8, 0–50)'. The description adds the default value (15) and context about the value range, but this is largely redundant. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a feedforward boost parameter that adds an acceleration component to FF. It distinguishes itself from many sibling set_* tools by specifying the exact parameter and its function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit tuning guidance: 'Increase if gyro lags... Decrease if gyro overshoots...' This tells the agent when to adjust the value. No alternative tools are mentioned, but the context is clear for a specific parameter setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that higher values increase smoothing, and gives the valid range and default. However, it does not describe potential side effects, impact on flight characteristics, or any prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical specification bracket. It is extremely concise, front-loads the purpose, and contains no filler. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter, the description covers the parameter's purpose, effect, range, and default. No output schema is needed. Context is complete for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with the 'value' parameter already described. The description adds meaning by explaining the role of feedforward_smooth_factor and the effect of higher values, plus explicitly stating the default (65), which goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'feedforward_smooth_factor'. It explains the purpose as 'Additional smoothing applied to the FF signal' and describes the effect: 'Higher = smoother FF output'. The range and default values are provided, making it highly specific and distinguishing it from other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives such as set_feedforward_jitter_factor or set_feedforward_boost. It implies usage for adjusting smoothing, but lacks when-not-to-use or comparative context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It states the action, requirement, and default but omits crucial details like persistence (whether change survives reboot), immediate effect vs. reboot required, and bounds (schema range contradicts UINT16 type). This leaves ambiguity for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, packing essential information (action, resource, unit, requirement, data type, default) into two short phrases with no superfluous content. Every piece contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers basic semantics but lacks completeness for operational context: no mention of whether the setting takes effect immediately or after reboot, no validation details (despite schema range v. UINT16 discrepancy), and no indication of return behavior (silent success or error). For a setter with no output schema, these gaps hinder agent confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a basic description. The tool description adds meaningful value: unit (kHz), default (800), and data type (UINT16), which enhance understanding beyond the schema alone. The requirement note also provides context for the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool sets the clock speed of I2C bus 2 in kHz. It uniquely identifies the resource and action, distinguishing it from sibling tools like get_i2c2_clockspeed_khz and set_i2c1_clockspeed_khz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite (USE_I2C_DEVICE_2) and provides default value and unit, offering implicit context for when to use. However, it does not explicitly contrast with alternative tools (e.g., getter) or specify when to prefer this over other I2C clock speed setters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it enables pull-ups, requires a compile option, and mentions a default value 'OFF'. However, it does not describe side effects (e.g., persistence, reboot required) or the valid range of the UINT8 value. Without annotations, the description carries the burden but provides only basic info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence with a parenthetical note and a type/default hint. No wasted words; information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the core function, prerequisite, and default. However, it lacks clarifications on accepted input values (e.g., is 0 off? any non-zero on?) and behavioral details like whether changes are persisted immediately or require reboot. For a simple set tool, this is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond the input schema. The schema description is 'Value for i2c3_pullup (UINT8)' which is vague. The description clarifies the semantic purpose ('enable internal pull-up resistors') and notes the default value, compensating for the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action: 'Enable internal pull-up resistors on I2C bus 3.' The verb 'Enable' and resource 'I2C bus 3' are specific, and the bus number distinguishes it from siblings like set_i2c1_pullup and set_i2c2_pullup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions a prerequisite: 'Requires: USE_I2C_DEVICE_3', which informs when the tool is applicable. However, it does not explicitly list alternatives or state when not to use it beyond the missing compile-time option.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes that it suppresses I accumulation in percent, which clarifies behavior. However, no annotations exist, and the description does not mention side effects, persistence, or safety implications. Reasonable for a simple parameter set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus bracket spec. Every sentence provides essential information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter set tool, the description fully explains the parameter's purpose, range, and default. No output schema is needed. Complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but lacks default value; description adds the default of 80 and explains the meaning of the parameter value (suppresses I accumulation). Adds meaningful context beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Set' with the resource 'iterm_windup' and explains the function: suppresses I accumulation when motors are near saturation. This distinguishes it from sibling tools like set_iterm_relax.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicitly suggests using the default 80 as sensible but no explicit guidance on when to use this tool versus alternatives or when not to use it. Adequate but lacks explicit usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It notes that DSHOT600 at 3.2kHz is marginal, but does not describe other behavioral traits such as whether a reboot is required, immediate effect, or potential risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two sentences that front-load the purpose and immediately provide critical value recommendations and default. No extraneous information is included.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter without an output schema, the description covers the purpose and parameter semantics thoroughly. It lacks only minor context such as error conditions or prerequisites, but overall is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema by listing specific protocol options and their recommended use cases, and by stating the default value. The schema only describes the parameter as a string, making the description essential for proper usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the motor PWM protocol (ESC communication protocol). It provides specific value recommendations (DSHOT600, DSHOT300) and a default, distinguishing it from sibling get/set tools for other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives usage guidance for which value to choose based on gyro hardware and loop frequency, but it does not explicitly state when to use this tool versus alternatives, nor does it mention when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the burden. It explains the effect (reducing delay at idle) but does not disclose side effects like whether changes take effect immediately, require a reboot, or impact other settings. The statement is helpful but incomplete for 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with appended type info. It is front-loaded, contains no filler, and all information is relevant. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a set-parameter tool with a single integer parameter and no output schema, the description is complete. It explains the parameter's purpose, default, and constraints. The agent can understand what this tool does and how to use it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of the parameter description (type, range, constraints). The tool description adds functional meaning: explaining what the fade range does (frequency band for notch fade-in at low throttle) and includes the default value (50). This goes beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Set' and the target resource 'rpm_filter_fade_range_hz'. It explains the parameter's function: 'Frequency band over which notches fade in at low throttle, reducing delay at idle.' This is specific and distinguishes it from sibling tools like set_rpm_filter_harmonics or set_rpm_filter_q.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('at low throttle, reducing delay at idle') but does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. The context is clear but lacks definitive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the data type (INT8) and default (OFF), but does not mention if the change is persistent, requires reboot, or has side effects. The behavior is simple but could be more transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short sentences and a brief technical detail. It is front-loaded with the tool name and immediate purpose, with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no annotations), the description provides all necessary context: what it does, why, data type, and default. It is complete for a parameter-setting tool in a large set of similar tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described simply as 'Value for rssi_invert (INT8)'. The description adds value by specifying the default ('default: OFF') and the purpose of the parameter (inverting the signal), going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set rssi_invert: Invert the RSSI signal'), explains the rationale ('some receivers send inverted RSSI'), and specifies the data type and default. It is distinct from sibling tools like set_rssi_channel and set_rssi_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when a receiver sends inverted RSSI, but it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusion criteria or prerequisites. Lacks guidance on when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the effect of each value on PID terms, names the prerequisite (`USE_WING`), and states the default (OFF per profile). This gives sufficient insight for a simple parameter setter, though it omits whether changes persist across reboots or have side effects on other systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that front-load the purpose and immediately provide essential details through an inline list. Every word contributes value (purpose, value explanations, requirement, default). There is no redundancy or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description is mostly adequate. However, it fails to explain the `USE_WING` prerequisite (what it is or how to enable it) and the type annotation (UINT8) contradicts the schema's string type, which could confuse the agent. Additional context about persistence or side effects would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'value' parameter only as 'Value for spa_roll_mode (UINT8)', which is minimal. The tool description expands this by listing the three allowed values and their meanings, thereby adding meaningful context that the schema lacks. While the data type note (UINT8 vs schema's string) introduces minor confusion, the description compensates for the schema's brevity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the 'spa_roll_mode' parameter for roll in SPA mode. It enumerates the three possible values ('I', 'PID', 'PDI_FREEZE') and explains their distinct effects, leaving no ambiguity about the tool's function. This stands out among many 'set_' sibling tools by being explicit about the resource and operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes that setting this parameter requires the `USE_WING` feature to be enabled, which is a prerequisite. However, it provides no guidance on when to use this tool versus alternative tools in the same domain (e.g., other SPA parameter setters like set_spa_roll_center) or when to choose one value over another. The agent would benefit from explicit context on selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description carries the burden well. It discloses that this is a setter for a configuration parameter, specifies the valid range and default, and notes the activation condition. It does not mention persistence or side effects, but the tool is straightforward and the description is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a qualifier and bracket-enclosed details. It is concise and front-loaded, but could be slightly more structured (e.g., separating the dependency). Still, every part earns its place with minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description is largely complete. It covers the action, the dependency, and value constraints. It does not explain the return value (likely void or success), but that is acceptable without an output schema. The sibling getter exists, so the pair is well-documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description adds value by contextualizing the parameter as the 'maximum throttle percentage' and specifying the condition (when throttle_limit_type is active), which goes beyond the schema's basic description of the value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the 'Maximum throttle percentage when throttle_limit_type is active', using the verb 'Set' and specifying the resource. It includes the data type, range, and default value, which distinguishes it from sibling tools like get_throttle_limit_percent and set_throttle_limit_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when setting the throttle limit percentage, but does not explicitly state when to use this tool versus alternatives. It mentions the dependency on throttle_limit_type being active, but provides no guidance on when not to use it or which alternatives exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the user action required (rotate flight controller through all orientations when prompted) and warns about MSP/CLI session ordering. However, it does not disclose side effects (e.g., overwriting previous calibration, internal state changes), and no annotations exist to fill this gap. Some additional behavioral context would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences. The first sentence states the purpose, and the second provides critical usage notes. Every word earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is largely sufficient. It covers the action and the crucial sequencing requirement. However, it omits any mention of return values (success/failure) or duration, which an agent might need to gauge next steps. Still, for a simple calibration with no params, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (empty schema). Per calibration, baseline is 4 for 0 parameters. No further parameter information is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool calibrates the magnetometer (compass), a specific resource. The verb 'calibrate' is action-oriented. Although sibling 'calibrate_accelerometer' exists, the resource type (magnetometer vs. accelerometer) naturally distinguishes them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises calling this tool before any CLI tools in the same session, noting that MSP cannot be used after CLI mode. This provides important sequencing context. It does not, however, mention when not to use it or alternatives, but the guidance is clear for the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it switches to source before copying and need for cli_save. No annotations, but description covers key behavioral aspects adequately.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero waste. Purpose first, then behavioral detail. Highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple copy tool with 2 required params and no output schema, description covers the action, switching behavior, and persistence requirement. Complete enough for agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already has 100% coverage with descriptions for both parameters (source and destination, 0-based index). Description adds no further semantic value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Copy a PID profile to another slot' using specific verb and resource. Distinguishes from siblings like set_pid_profile which sets current profile.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit post-condition: 'Call cli_save afterwards to persist.' Lack of when-not-to-use or alternatives, but clear context for copy operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds value by specifying the data type and range beyond the name. However, it does not explicitly state that the tool returns the current trim value, which would be helpful for a parameterless getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence containing all essential information—purpose, data type, range, default—without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description adequately covers the tool's purpose, type, range, and default. It could explicitly mention that the tool returns the current value, but the context is clear enough for a getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema coverage is 100%. The description adds meaning by detailing the range and default value, which is valuable beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the accelerometer pitch trim for level calibration, specifying the data type and range. It effectively distinguishes from the sibling 'get_acc_trim_roll' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when needing to read the pitch trim value for calibration. While it doesn't explicitly exclude alternatives, the context is clear given the specific purpose of the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the burden. It discloses the data type (UINT16), range (0–2000), and default (0), which are key behavioral traits. It also implies read-only via 'factory calibration'. However, it does not explicitly state it is non-destructive or safe, which would warrant a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the purpose, followed by essential metadata in brackets. No extraneous words—every element is necessary and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and zero parameters, the description is sufficiently complete for a simple getter. It explains what is returned and its constraints. It does not explain the value's use case, but that is acceptable domain knowledge. Minor gap: no mention of whether the value is persistent or requires calibration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%. The description adds value by specifying the return type and range, which are not in the schema. Baseline for 0 parameters is 4, and the description meets this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the ADC temperature sensor calibration value at 110°C, specifying it's factory calibration. The verb 'Get' combined with the resource name makes the purpose unambiguous, and the temperature specification distinguishes it from sibling tool get_adc_tempsensor_calibration30.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidance is provided, but the context is clear: use when you need the factory calibration value for 110°C. The description does not mention when not to use it or alternative tools, so it relies on the agent's domain knowledge. This is acceptable for a simple getter but could be improved.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses value type (UINT16), range (10–5000), default (100), and meaning. No annotations to contradict. Lacks mention of side effects but appropriate for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with bracketed specs; front-loaded name; minimal waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers value characteristics adequately for a simple getter. No output schema, but return format is likely the scalar value. Slightly incomplete without output description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4. Description adds meaning about the value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the low-pass filter cutoff for altitude derivative (vertical speed), with type and range. Distinct from sibling get_altitude_lpf.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implied usage as a getter for a specific parameter, but no explicit when-to-use or when-not-to-use compared to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It explains that the value controls logging frequency and that finer rates increase log size, which is helpful behavioral context. However, it does not explicitly state that it's a read-only operation with no side effects, though that is implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a compact example and default notation. Every word adds value, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is remarkably complete. It defines the parameter, gives defaults, examples, and notes the trade-off. It does not describe the return type explicitly, but that is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description cannot add parameter meaning. It compensates by explaining the value's meaning, default ('1/4'), and providing examples of rate calculations. This adds value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the blackbox_sample_rate parameter, defines it as 'Fraction of PID loop iterations logged', and provides examples to illustrate. It distinguishes itself from the sibling 'set_blackbox_sample_rate' by being a getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use for reading the current sample rate setting, but does not explicitly mention when to use it versus alternatives like 'set_blackbox_sample_rate' or other getters. No guidance on when not to use is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It discloses the return value type (UINT16), range (0–500), and default (0 per profile). However, it omits behavioral details like read-only nature (implied by 'get') and whether the value is per-profile or global, leaving minor ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus bracketed constraints. Front-loaded with the tool name and explanation, no wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value and its context well. Missing explicit units (likely milliseconds), but range and purpose provide sufficient completeness for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0 parameters and 100% schema coverage, baseline is 4. The description adds meaning by explaining the return value's purpose and constraints, exceeding the schema's empty definition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's verb ('Get'), resource ('crash_delay'), and explains its meaning as 'Delay after arm before crash detection is armed.' It provides range and default, distinguishing it from other crash-related getters like get_crash_dthreshold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
For a simple getter, usage is implied but no explicit guidance on when to use vs. alternatives (e.g., set_crash_delay). The description lacks exclusions or context about when this tool is appropriate, earning a mid-range score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data type (UINT16), valid range (100-2000), and default value (400 per profile). The 'Get' verb implies read-only, but does not explicitly state safety or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise sentence with essential details. No wasted words, and critical info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description covers the key aspects: what it returns, its type, range, and default. Minor gap: could explicitly state the return format, but adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema, so baseline is 4. Description adds value constraints (type, range, default) which, while not parameter-related, provide useful context for the returned value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves the gyro rate threshold for crash detection, with units (deg/s). Effectively distinguishes from siblings like get_crash_dthreshold and set_crash_gthreshold.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance. While it's a simple getter, the description does not mention alternatives or prerequisites, leaving the agent to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not explicitly state that the tool is read-only or requires no authorization. However, as a getter, it is implied to be safe. The description mentions the data type and default value but lacks behavioral details like side effects or permission requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences to convey the purpose, usage context, and default value. Every piece of information is relevant and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the purpose and usage condition. It does not describe the return format, but the return is likely a scalar value, which is obvious from the context. Overall, it is fairly complete for a tool of this simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100%. The description does not need to add parameter information. Baseline 4 is appropriate for a zero-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the static cutoff frequency for the D-term low-pass filter 1, including the data type and default value. It distinguishes from siblings by specifying the condition when this parameter is used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit context on when to use this tool: when `dterm_lpf1_dyn_min_hz == dterm_lpf1_dyn_max_hz`. While it does not list alternatives, the condition helps the agent understand its applicability among many similar getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description reveals the data type (UINT8), valid range (10–255), and default value (150). However, it does not explicitly confirm that this is a read-only operation with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the purpose, no redundant information. Every word serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple getter with no output schema. The description provides the meaning, units, range, and default, but lacks context about how this parameter fits into the dynamic idle controller system.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds value by explaining what the returned value represents (maximum throttle increase, units, range, default). Baseline 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get dyn_idle_max_increase' with a specific verb and resource, and explains it is the maximum throttle increase commanded by the dynamic idle controller. This distinguishes it from other getters for different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like the setter 'set_dyn_idle_max_increase' or other getters. The read-only nature is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the read-only nature ('Get'), precise value constraints (UINT8, 0-75, default 15), and that it is per-profile. For a simple parameter retrieval, this is transparent and sufficient. Missing mention of connection state or side effects is acceptable for such a narrow tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the action ('Get ez_landing_limit') and immediately provides essential details (type, range, default). Every word adds value; no redundancy. Ideal conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains what the tool returns (the limit value) but does not specify the response format (e.g., integer, string). However, the data type hint 'UINT8' implicitly suggests a numeric return. For a simple getter, this is nearly complete; minor omission of explicit output description keeps it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters with 100% schema coverage (empty schema). Baseline is 4, and the description correctly adds no param info since none exist. No improvement needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'ez_landing_limit' parameter, defines it as 'minimum throttle floor enforced by EZ landing (%)', and provides data type, range, and default. This is specific and unambiguous, distinguishing it from sibling getters like get_ez_landing_speed or get_ez_landing_threshold through unique parameter identity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or avoid this tool vs. alternatives. As a simple getter for a specific parameter, usage is implied: use when needing the current EZ landing limit value. No comparisons to siblings or exclusions are provided, but the niche scope makes this adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral context. It explains the parameter's role, default (15 = 1.5 s), minimum safe value (2 = 200 ms), and unit (UINT8). This adds significant context beyond a simple 'get failsafe_delay' but does not describe return format or connection requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, directly states the tool's purpose, and provides key values (default, minimum) without fluff. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description compensates by explaining the value's meaning, units, and constraints. It could be more complete by stating the expected return format (e.g., raw uint8 or converted seconds), but the provided context is sufficient for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so schema coverage is 100%. The description adds semantic meaning by explaining the parameter's purpose, default, and safe range, which goes beyond the empty schema. For a zero-parameter tool, this is strong context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the failsafe_delay parameter, defining it as 'Stage 1 guard duration — time from confirmed signal loss to Stage 2 activation'. This specific verb and resource combined with the parameter explanation distinguishes it from sibling tools like get_failsafe_landing_time.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides meaning and safe values but does not explicitly state when to use this tool versus alternatives like set_failsafe_delay or other get_failsafe_* tools. There is no 'when to use' or 'when not to use' guidance, only a description of the parameter itself.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description explains the behavioral context: it applies in Landing Mode Stage 2, as Stage 1 fallback, and has a specific requirement for GPS Rescue. It also states the default value (1000 = motors off). This goes beyond a simple 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the purpose and adds critical usage details without fluff. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description covers the key aspects: roles, default, and GPS Rescue implication. It could mention whether the value is read from hardware or config, but overall it is sufficiently complete for a simple uint16 parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage), so the description does not need parameter details. However, it still adds value by specifying the return type and default in brackets [UINT16, default: 1000], which aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the failsafe throttle value and specifies its roles in Landing Mode Stage 2 and as Stage 1 fallback. It also includes domain-specific context like GPS Rescue implications, distinguishing it from other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied from the context (failsafe, landing, GPS Rescue), but no explicit guidance on when to use this tool versus alternatives (e.g., get_failsafe_throttle_low_delay) is provided. The description does not exclude other scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses behavioral context: smoothing effect, possible settings (OFF, 4_POINT, default 2_POINT), and the trade-off between snappiness and smoothing. No annotations exist, so the description provides useful transparency beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: three short segments covering purpose, effect description, value enumeration, and default. Front-loaded with the action and purpose. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter-free getter with no output schema or annotations, the description covers purpose, effect, values, and default. It doesn't specify the exact return format, but the options are clearly listed, making it functionally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100% trivial. The description adds value by explaining the meaning and options of the returned value, which is effectively the 'parameter' being queried.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the feedforward averaging setting, explains its purpose (smoothing RC link quantization), and lists possible values with effects. Distinguishes from sibling tools by focusing on this specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes the effect of each value (snappiest vs. heaviest smoothing) but does not explicitly guide when to use this tool over other get_feedforward_* siblings or when to choose a particular value.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses the return type (UINT8), valid range (10–250), and default value (100), providing transparency about the data returned. No annotations exist, so the description adequately covers behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the tool name and purpose, then concise details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema, but description reports type, range, and default. Lacks precision info (e.g., step size) but is sufficient for understanding what the tool returns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. The description adds no parameter info because none is needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the duration (ms) of the yaw feedforward hold after stick release. It specifies the exact parameter name and its function, distinguishing it from sibling getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidelines on when to use this tool versus alternatives. The name implies a getter for the 'feedforward_yaw_hold_time' parameter, and a setter sibling exists, but no contextual advice is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description adds context about the default value ('default: ON') and data type ('UINT8'), but does not explicitly state that this is a read-only operation. However, the 'get_' prefix strongly implies read-only, so the lack of explicit safety info is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a compact bracketed note. Every word adds value: the action, the setting's purpose, usage advice, and default value. No waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description adequately explains the setting's role and default. It could optionally mention the valid range (e.g., 0 or 1) or the return value format, but this is not essential for selection.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema covers 100% of them. The description does not need to add parameter details. According to calibration rules, baseline score for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the GPS auto-config setting for UBlox modules. It explains what the setting does (configure baud rate, update rate, message types) and distinguishes it from other GPS-related tools like get_gps_auto_baud or set_gps_auto_config.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a clear guideline: 'Leave ON unless you pre-configure the module with uCenter.' This helps the agent understand when to keep the setting enabled. No explicit alternatives are needed since it's a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses that the return is a UINT8 with a default of UBLOX. It does not explicitly state that it is a read-only operation, but the context implies it. Slightly above minimal for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracketed note. It is front-loaded with the action and resource, and every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and the simplicity of the tool (a simple getter), the description is sufficiently complete. It explains the purpose, the type, and gives a usage hint. Missing only explicit list of possible values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds meaning by explaining what the return value represents (protocol type) and its default, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the GPS protocol setting (gps_provider) and provides context about UBLOX vs NMEA. It distinguishes from numerous sibling get_ and set_ tools by specifying the exact resource and providing a recommendation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends preferring UBLOX for UBlox modules, which guides the agent on which value to set or check. However, it does not explicitly indicate when to use this tool over alternatives; the guidance is about the value itself, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It discloses that enabling this allows arming without GPS fix but makes GPS rescue unavailable, and OSD shows 'RESCUE OFF'. It also notes type and default, providing good behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a type/default tag. Front-loaded with the name and core purpose. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the key behavioral impact and data type. It could mention that it returns the current value, but that is implicit. Overall complete enough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No input parameters, so schema coverage is 100%. The description adds meaning by explaining what the value represents (arming without fix, rescue unavailable) and includes type and default info, which is helpful beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the gps_rescue_allow_arming_without_fix setting and explains what it does: 'Allow arming without a GPS fix.' This is specific and distinguishes it from sibling getters for other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool or when not to. It implies reading the parameter value, but does not mention alternatives (e.g., set counterpart). For a simple getter, this is adequate but lacks explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavioral consequence of the parameter (disarm and drop if too close), which goes beyond a simple parameter description and adds valuable context for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bracket note. It front-loads the key information and contains no filler or redundant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the parameter and its effect. It implies the tool returns the current value. Could explicitly mention that it returns the current value, but the meaning is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, so schema coverage is 100% (trivially). The description adds type, range, and default value in brackets, which provides meaningful context beyond the empty schema. Baseline for 0 params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the gps_rescue_min_start_dist parameter and explains its purpose as the minimum distance from home to activate rescue. It distinguishes itself from other get_gps_rescue_* tools by specifying this particular parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the behavior of the parameter (closer than this leads to disarm) but does not explicitly state when to use this tool versus alternatives like the set_gps_rescue_min_start_dist or other get_gps_rescue_* tools. Usage context is implied but not directly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses an important behavioral trait: the quad maintains current altitude if already above the target. This adds value beyond a simple 'get' by explaining how the value is used. However, it does not mention that this is a read-only operation (implied by 'get') or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of a single clear sentence followed by a compact type/range/default annotation. Every word serves a purpose, with no redundancy. The key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description is largely complete. It explains the value's meaning and a behavioral nuance. A minor gap is that it doesn't explicitly state what the tool returns (the current value of the setting), but that is implied. Overall, it sufficiently covers the tool's behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description adds semantic context by specifying the data type ('UINT16'), valid range (5–1000), and default value (30). This information, though embedded in the description rather than the schema, aids the agent in understanding what the retrieved value represents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as getting the target return cruise altitude for GPS rescue, with a specific verb ('Get') and resource ('gps_rescue_return_alt'). It also includes behavioral detail ('If the quad is already above this, it maintains current altitude'), distinguishing it from other getters. Among many sibling getters, this description uniquely specifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (to retrieve the return altitude setting), but does not explicitly mention when not to use or suggest alternatives like the corresponding setter (set_gps_rescue_return_alt). No guidance on context or prerequisites is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes the tool as a getter and includes constraints (UINT8, 0–200, default 20). It does not explain return format but for a simple read operation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical and bracketed specs. It is concise, front-loaded, and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description adequately covers purpose and value constraints for a simple getter with no parameters. It could mention that it returns the current value, but the context is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so baseline is 4. The description adds value by specifying the data type, range, and default of the value being retrieved, which is relevant context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get', the resource 'gps_rescue_yaw_p', and provides context: 'Yaw P gain during rescue (heading correction)'. It also includes data type and range in brackets, distinguishing it from sibling tools like the setter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, the naming convention and presence of a setter imply it is for reading the current value. Usage context is implied but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It correctly indicates a read operation with no side effects, and mentions the type and default. For a parameterless getter, this is transparent enough, though it could note that it simply returns the current setting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with a colon separating the action from the detail. It is front-loaded with the core purpose and includes type/default info without any fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description adequately explains what the return value represents (the dynamic model for fix acquisition) and its type/default. It lacks a list of possible values, but for a simple getter this is acceptable and provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the description does not need to add parameter information. The baseline score of 4 is appropriate as no further semantics are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the UBlox dynamic model used during GPS fix acquisition. It specifies the data type (UINT8) and default value (STATIONARY), distinguishing it from sibling tools like get_gps_ublox_flight_model. This makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for reading a configuration value, but it does not explicitly state when to use it instead of similar getters (e.g., get_gps_ublox_flight_model) or when to prefer the setter counterpart. No context for decision-making is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It correctly implies a read operation (no side effects) by using 'Get'. It adds context about the parameter type and default value, but does not explicitly guarantee no state changes or describe return format beyond type hint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with additional bracketed info. No wasted words, front-loaded with the tool's purpose, and efficiently conveys key details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description is adequately complete for a simple getter. It identifies the setting, its type, and default. However, it lacks explanation of possible values or their meanings, which could be helpful.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist (0 params, schema coverage 100%), so the description need not document them. It still provides useful info about the returned value (UINT8, default AUTO), which adds semantic value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the GPS UBlox UTC time standard setting, with specific verb 'get' and resource 'gps_ublox_utc_standard'. It distinguishes from sibling get_gps_* tools by naming the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The name implies a read operation, and the presence of a set_gps_ublox_utc_standard sibling provides implicit usage context, but no direct comparison or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the behavioral effect of the parameter (calibration restarts if movement exceeds the threshold) and offers actionable advice. It clearly indicates a read operation via 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, fitting in a single sentence with a dense format. It front-loads the purpose and includes key details in brackets. Slightly more structured formatting could improve readability, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is provided, so the description should explain the return value. It mentions the range and type [UINT8, 0–200, default: 48], implying the return format, but it does not explicitly state that the tool returns the current setting as a numeric value. This omission slightly reduces completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the schema, so the baseline is 4. The description adds meaning by explaining the parameter's role and including the valid range and default in brackets, which compensates for the lack of parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the gyro calibration noise limit, explains its meaning as a noise threshold during calibration, and specifies the consequence when exceeded. It distinguishes itself from siblings like get_gyro_calib_duration and the corresponding set_ tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a practical usage hint: 'Increase if it won't calibrate in a noisy environment.' It implies the tool is used for troubleshooting calibration issues. No explicit alternatives or exclusions, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read operation ('Get') and adds behavioral context: the returned value is a UINT16 with a default of 0 and must be less than gyro_notch1_hz. This is sufficient for a simple parameter retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a type/default hint, both front-loaded. No wasted words; every part is informative and necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description covers the key points: what is retrieved, its constraint, type, and default. It could be more explicit about the acceptable range (0-65535) and return format, but these are minor omissions for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema is empty (0 parameters), so schema coverage is trivial. The description adds meaning by explaining the parameter's purpose (bandwidth), its constraint, and its type/default. This adds value beyond the schema for an agent understanding the tool's function.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the bandwidth of gyro notch 1, includes a constraint (must be less than gyro_notch1_hz), and specifies the type and default. It distinguishes from siblings like get_gyro_notch1_hz (frequency) and set_gyro_notch1_cutoff (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives. It implies usage when needing the bandwidth value, but no exclusions or alternative suggestions are provided. The constraint hints at relationship with gyro_notch1_hz but doesn't fully guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that 0 disables the notch and notes the parameter type (UINT16) and default value. However, it does not mention any side effects, read-only nature, or error conditions, which are important for a mutation-free getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence followed by a brief usage hint and type/default annotation. Every part is informative and no words are wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While there is no output schema, the description explains what the tool returns (the centre frequency) and its significance (0 = disabled, for persistent resonances). It is mostly complete for a simple getter, though it could explicitly state the unit (Hz) which is implied by the name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description is not required to add parameter meaning. The baseline for zero parameters is 4, and the description includes the type and default (UINT16, default 0) which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb 'Get' and the resource 'gyro_notch1_hz', explaining it is the centre frequency of static gyro notch 1, with 0 meaning disabled. This distinguishes it among many sibling getter tools for different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises 'Use for specific persistent resonances not handled by dynamic notch', providing clear context on when to apply this tool. However, it does not explicitly list alternatives or when not to use it, leaving some ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses the read-only nature via 'get', explains the meaning of 0 (disabled), and specifies the data type and default, which provides important behavioral context beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional info in brackets. It is front-loaded with the purpose and contains no extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the purpose, data type, default, and range meaning. It could mention the corresponding setter or clarify that it is a configuration parameter, but it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so per the rule baseline is 4. The description does not need to add parameter information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the centre frequency of static gyro notch 2, distinguishes from siblings like get_gyro_notch1_hz and get_gyro_notch2_cutoff by specifying 'notch2' and 'centre frequency', and includes the data type and default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance or alternatives are provided. The name implies it is for reading the notch 2 frequency, and the setter sibling suggests the counterpart. However, among many similar getters, explicit guidance could help an agent differentiate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It indicates a read operation via 'Get' and specifies the value range, but it does not explicitly state that the call is non-destructive or idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise – a single line with purpose, prerequisite, and format – with no wasted information. It is front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the essential aspects: what it retrieves, the prerequisite, and the data format. It is fully adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and the schema coverage is 100%. The description adds value by specifying the return value format, range, and default, which is more than a baseline of 4 for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get ibatv_scale: Virtual current sensor scale.' It uses a specific verb ('Get') and resource, and includes the data type, range, and default, which distinguishes it from other getter tools like get_ibata_scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes a required prerequisite ('Requires: USE_VIRTUAL_CURRENT_METER') but does not provide explicit guidance on when to use this tool versus alternatives, such as other current sensor scale getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description implies a safe read operation but does not explicitly state that the tool is non-destructive or has no side effects. Adequate but could be more precise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: defines the parameter, explains its effect, notes default suitability, and provides constraints. No redundancy, efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a parameterless getter; covers purpose, typical use, and value constraints. Could mention return format (single uint16) but not essential given simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%; description adds relevant type, range, and default value, which compensates for the absence of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves the complementary filter proportional gain, explains its role in blending accelerometer data with gyro integration, and distinguishes it from sibling tools like get_imu_dcm_ki.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Notes that the default is suitable for normal use, implying a read operation; does not explicitly mention when to adjust via the setter, but context is clear for a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adequately discloses the tool's behavior: it returns the current setting of a configuration parameter. It explains the two possible values and the default, providing sufficient context for a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded, but starts with a redundant repetition of the tool name ('Get iterm_relax_type:'). Could be slightly more efficient by omitting that prefix.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description fully explains what the tool returns and the significance of the values, making it complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds value by explaining the meaning of the returned value (the type and default), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'iterm_relax_type' parameter and explains its purpose (signal for fast move detection) and possible values (SETPOINT vs GYRO). This distinguishes it from other get_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives (e.g., set_iterm_relax_type or other get_* tools). Usage is implied by the 'Get' verb and parameter explanation, but no direct guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly states this is a read operation ('Get'), lists all possible values with descriptions, and specifies data type (UINT8) and default (LEGACY). This sufficiently discloses behavior for a simple parameter retrieval.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating the purpose, followed by a compact list of value definitions. Every sentence adds necessary information with no redundancy. It is front-loaded with the core explanation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately explains the return value and its possible modes. It covers the key aspects: what the tool retrieves, the meaning of each value, and the default. It could mention that it's read-only, but 'Get' implies that. Overall complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema coverage is 100% (empty). The description adds value by explaining the return value's semantics (the possible mixer type values and their meanings), which is helpful beyond the empty schema. Baseline for zero params is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the mixer_type parameter and explains its purpose as 'Motor mixer output mode'. It lists the possible values with brief meanings, distinguishing it from other getter tools like get_mixer or get_motor_idle by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a simple read operation to retrieve the current mixer type. It does not explicitly state when to use this tool versus alternatives, but given its specificity, usage is clear. No guidance on when not to use is provided, but it's adequate for a straightforward getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden. It explains that the tool retrieves a value sent to ESCs when armed, implying a read-only operation. However, it does not explicitly state that it is safe or has no side effects, nor does it mention any required permissions or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence plus a bracketed specification. Every element serves a purpose: name, purpose, role, and technical constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description effectively communicates what the tool returns and its context. It includes the value's role, units note, and constraints. It could be slightly more explicit about it being a read-only operation, but overall it is sufficient for understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the schema imposes no burden. The description adds significant value by explaining what the returned value represents (idle throttle), its units caveat, and its range and default. This helps an agent understand the semantics of the output beyond just the name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the idle throttle value sent to ESCs when armed, specifying it is the minimum non-zero motor command. It also provides the data type, range, and default. This distinguishes it from the sibling 'set_motor_idle' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates when to use this tool (to read the idle throttle value), but does not explicitly state when not to use it or provide alternatives. Given there are no other readers for this specific value, the context is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses consequence of wrong value ('filters tracking wrong frequencies'). Includes default and type info. Adds behavioral context beyond schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with front-loaded purpose, followed by context and warning. No extraneous text; earns every word.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a parameterless read-only tool. Covers purpose, default, and criticality. Could mention pairing with setter, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (schema coverage 100%). Description adds value by stating default value and type '[UINT8, default: 14]' which is not in schema. Justified for 0-param tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it gets the number of magnetic poles. Specifies 'magnet count, not stator count', resolving common ambiguity. Distinguishes from sibling 'set_motor_poles' by being the getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explains importance for RPM filter accuracy and advises verifying on specific motors. Implicit usage context but lacks explicit when-not-to-use or alternatives. Adequate for a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description adequately explains the behavior: it retrieves a setting that keeps PIDs active at idle. The type and default are noted. However, it does not explicitly state that the operation is read-only, though this is inferred from 'Get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a single sentence plus technical details in brackets. It front-loads the purpose and includes no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple 0-parameter getter, the description covers the setting's role, importance, and default value. It does not enumerate possible values (e.g., 0/1) but the context 'normally left ON' and type 'UINT8' imply the range. Overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; baseline is 4. The description adds value by explaining the purpose and default of the setting, which is sufficient context for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies this as a getter for the pid_at_min_throttle setting, explains its function (keeps PIDs active at idle), and distinguishes it from the 'set_pid_at_min_throttle' sibling. The verb 'Get' and resource name make the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidance is provided. The description gives context ('Required for airmode to function correctly; normally left ON') but does not compare with alternatives or specify scenarios. Usage is implied but not directed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description correctly characterizes this as a read-only operation ('get') that returns float values. It explains the meaning of the pids_mode field, adding transparency. However, it does not disclose any potential side effects or error conditions, which is acceptable for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three sentences, each conveying essential information: purpose, return format, and pids_mode explanation. No unnecessary words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description adequately explains what is returned and the meaning of the values. It does not list all possible slider values but provides enough context for an agent to interpret the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and schema coverage is 100%. The description adds value by explaining the return values (float positions, default 1.0) and the pids_mode enum, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely states the tool retrieves 'current Betaflight simplified filter and tuning slider values' and explains the return format (float positions) and pids_mode enumeration. This clearly distinguishes it from other get_ tools by targeting a specific set of parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this tool versus alternatives. While it explains the return values, it lacks information about the context or prerequisites for retrieval, leaving the agent to infer applicability from the name and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the output format and default values, adding value beyond the schema. It discloses the operation is read-only with no side effects mentioned, which is appropriate for a getter. No annotations exist to contradict.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two-sentence description is concise and front-loaded: first sentence states purpose, second provides technical details (default and disabled meaning). No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description adequately defines the return format (4 UINT8 values) and semantics. It is complete for a simple getter but could mention response structure (e.g., array) for clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so baseline is 4. The description adds meaning about the output (4 UINT8 values, default 255), compensating for the lack of output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves pinio_box assignments, specifying 'AUX box assignments for the 4 PINIO outputs' and explaining the meaning of 255 as disabled. This is specific and distinguishes it from sibling tools like set_pinio_box.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage as a getter (verb 'Get') but does not explicitly state when to use it versus alternatives. Since it's a simple read, the implicit context is adequate but not proactive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, but the description provides data type and default value. It implicitly indicates read-only behavior by being a getter. Could mention it does not modify state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise with one sentence plus type/default note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description provides enough context to understand the tool's function and return value. Could be more explicit about returning the current value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so schema coverage is 100%. The description adds meaning by specifying the data type (UINT8) and default (ON), which helps interpret the returned value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the rc_smoothing setting and explains its purpose (RC input interpolation and smoothing between frames). It is distinct from siblings like get_rc_smoothing_auto_factor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use or alternatives. For a simple getter, it's acceptable but could be improved by stating it's for checking the current setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Explicitly states it is a read operation ('Get') and provides default values and data type (UINT8). Does not mention side effects, but no side effects are expected. Slightly improved by including default and type info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single paragraph with purpose, examples, tuning advice, and data type. Efficiently packed but tuning advice could be seen as extraneous for a getter. However, overall concise and front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Provides default and type but does not specify the number of values returned (array length). With no output schema, agent must infer from default that there are three values. Could be more explicit about the array structure or that it depends on harmonic configuration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters (0 params), baseline 4 per guidelines. Description adds context by explaining the return values represent per-harmonic notch depth percentages, which adds meaning beyond the schema's empty parameter list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it retrieves RPM filter weights as per-harmonic notch depth percentages. Provides concrete examples for different prop types, distinguishing it from set_rpm_filter_weights. Verb 'Get' plus resource 'rpm_filter_weights' makes purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific tuning examples for tri-blade and bi-blade props, implicitly guiding when to use certain values. Advises to lower each value until noise disappears, which is a tuning procedure. However, does not explicitly compare to sibling tools like get_rpm_filter_harmonics or state when this tool should be chosen over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description effectively discloses read-only behavior and explains the effect of the value (higher = smoother but slower response). It also notes the type and default, adding useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences. First sentence defines purpose, second adds behavioral detail. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only parameter with no inputs, the description covers the return value (LPF period), type, default, and effect. Lacks explicit units (e.g., milliseconds), but generally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has no parameters (100% coverage), so baseline is 3. The description adds value by providing the default value (125) and type (UINT8) not present in the schema, plus explanatory details about the parameter's effect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the LPF period for RSSI smoothing, a specific resource. It distinguishes from the sibling set_rssi_smoothing and other RSSI-related getters by focusing on the smoothing period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a getter use case but lacks explicit guidance on when to use this tool vs alternatives like get_rssi_channel or set_rssi_smoothing. No context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses the value type, range, and default, but does not explicitly state that the tool is read-only or side-effect-free. The name implies a get operation, but a direct statement would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracketed spec. It is front-loaded with the purpose and includes essential details without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers meaning, type, range, and default. It is sufficient for the agent to understand and select the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100%), so the description adds meaning by explaining the return value's semantics: a UINT16 from 100 to 1000 with a default of 500. This is useful context beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'runaway_takeoff_deactivate_delay' parameter, defines it as 'Time after arming before runaway takeoff protection stops monitoring,' and includes type, range, and default. The name and description distinguish it from siblings like 'get_runaway_takeoff_deactivate_throttle_percent'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: to read the current delay value. It does not explicitly say when not to use it or mention alternatives, but as a specific getter in a config toolset, the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It mentions the data type (UINT8, default 0) and that it's new, but does not explicitly state read-only behavior or what happens if USE_WING is not enabled (likely error or default returned).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence plus metadata. Key information is front-loaded with no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description covers purpose, requirement, and return type. It could be improved by explaining 'additional stability control' or potential error cases, but overall is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema coverage 100% empty), so the description adds value by specifying the return type 'UINT8, default: 0', helping the agent understand the output format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get s_roll: S-term (stability term) for roll.' The verb 'Get' and resource 's_roll' are specific, and mentioning 'roll' distinguishes it from siblings like get_s_pitch and get_s_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The requirement 'Requires: USE_WING' provides clear context for when this tool is applicable. For a simple parameterless getter, this is sufficient guidance; no explicit alternatives are needed as the purpose is straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description discloses the data type (UINT8), valid range (0–100), and default value (50). This provides sufficient behavioral context for a simple read operation. It does not mention side effects or authentication, but none are expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence stating purpose and a parenthetical with type info. No unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential information: what is retrieved and its constraints. It could hint at the exact output format, but the type specification suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description adds value beyond the schema by specifying the nature of the returned value (throttle at 50% stick) and its constraints, which helps the agent interpret the output.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the throttle curve mid-point value that sets thrust at 50% stick. It uses specific verb ('Get') and resource ('thr_mid'), and distinguishes from the sibling set_thr_mid tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The purpose is implied by the name and description, but there is no statement of when not to use it or comparison to other getter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates it is a read operation with no side effects and provides the data type, range, and default. This is sufficient for a simple getter, though it lacks details like whether calling it multiple times has any impact.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence followed by a terse inline specification. It front-loads the action ('Get throttle_boost') and wastes no words. Every part serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is adequate. It explains the parameter's effect and expected value. However, it could mention the relationship with set_throttle_boost and get_throttle_boost_cutoff for completeness, but that is not strictly necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is 100% (empty). The description adds value by specifying the expected return value format (UINT8, 0-100, default 5), which helps the agent understand the output even though no input parameters exist. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the throttle_boost parameter, which transiently boosts throttle output on fast stick changes. The verb 'Get' and resource 'throttle_boost' are explicit, and the purpose distinguishes it from sibling set_throttle_boost and get_throttle_boost_cutoff.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied as a read operation for the throttle_boost parameter, but there is no explicit guidance on when to use it vs. alternatives like set_throttle_boost or get_throttle_boost_cutoff. The description could mention that this tool is for inspecting the current setting, not modifying it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explains that the tool retrieves a numeric value and specifies its range (25–100) and default (100). This is sufficient for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two short sentences to convey the tool's purpose, the value's meaning, and its constraints. Every word is necessary and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers the essential information: what the tool gets, the meaning, and the data constraints. It could be considered complete for a getter of a single parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description adds meaning by explaining what the returned value represents (maximum throttle when throttle_limit_type is active) and the valid range, which goes beyond the schema's structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the throttle_limit_percent, which is the maximum throttle percentage when throttle_limit_type is active. It provides the data type, range, and default value. This distinguishes it from sibling tools like set_throttle_limit_percent (write) and get_throttle_limit_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidelines are provided; the description does not specify when to use this tool versus others. However, the purpose is clear enough that an agent can infer it should be used to read the current throttle limit percent setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It adds useful context: the scale (1000-2000), the behavior that attenuation is proportional from this point to full throttle, the data type (UINT16), and the default value (1350). However, it does not disclose error conditions or whether the operation is purely read-only (though 'get' implies that).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only three sentences—yet conveys the essential information: what the tool does, the scale, the behavior, and the default. It is front-loaded and every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description adequately explains the returned parameter, its scale, default, and effect. It is complete for a simple read operation, though it could briefly mention that it returns the current setting or note that it's a read-only retrieval.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema description coverage is 100%. The description provides additional detail by specifying the scale and default value, which adds meaning beyond the empty schema. The baseline for 0 parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the tpa_breakpoint value, explains that it is a throttle level on a 1000-2000 scale where TPA begins, and mentions the default value. This distinguishes it from many sibling 'get_' tools by providing specific meaning.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage (to get the TPA breakpoint setting) but does not provide explicit guidance on when to use this tool over alternatives, such as other get_ tools or related set_tpa_breakpoint. No prerequisites or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the requirement (USE_ADVANCED_TPA), data type (INT8), default value (20), and the effect of the parameter on throttle attenuation. Since no annotations are provided, the description carries the full burden effectively.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with one sentence plus parenthetical metadata. It slightly redundantly repeats the tool name at the start but is otherwise efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter getter with no parameters, no output schema, and a single sibling setter, the description is complete: it explains the purpose, effect, requirement, and type/default.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the description covers the key semantics of the parameter (the expo value and its effect). Baseline score of 4 for no parameters is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the expo value applied to the TPA curve, explains the effect of negative and positive values, and differentiates from sibling getters by specifying the exact parameter name and behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used to read the TPA curve expo parameter but does not explicitly state when to use it versus alternatives like set_tpa_curve_expo or other getters. It provides the requirement (USE_ADVANCED_TPA) but lacks clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the burden. It discloses the unit (×0.1%), default value (200 = 20%), and a required feature flag (USE_ADVANCED_TPA). This adds behavioral context beyond a simple 'get'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences front-loaded with purpose, then unit, default, requirement, and type. Every part earns its place with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, the description provides essential context (unit, default, requirement). It lacks info about the return format but is sufficient for a single-value read.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters, so no parameter documentation needed. Baseline for 0 params is 4, and the description adds relevant output context without needing to explain parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the PID value at zero throttle for the TPA curve, with a specific verb and resource. It distinguishes from siblings like get_tpa_curve_pid_thr100 by noting 'at zero throttle'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a requirement (USE_ADVANCED_TPA) but does not explicitly state when to use this tool versus alternatives like the setter or other getters. Implicit usage is clear but no explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It states the return type (UINT8) and default (30), implying it is a read query. It does not explicitly confirm safety or side effects, but the 'get_' prefix and parameter-less schema strongly suggest no destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that packs the action, resource, meaning, prerequisite, type, and default value. No redundant words; every token adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity (0 params, no output schema, no annotations), the description covers the core purpose, application domain, prerequisite, and data format. It could hint at read-only behavior, but that is implicit. Overall, it provides sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, and the schema coverage is 100% (empty object). Per guidelines, baseline for 0 parameters is 4. The description adds no parameter info because none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get'), the resource ('tpa_curve_stall_throttle'), and explains the meaning ('Throttle % below which the craft is considered stalled for wing/fixed-wing TPA'). It fully distinguishes this from the many other get_ siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies the prerequisite constant 'USE_ADVANCED_TPA' and the context ('for wing/fixed-wing TPA'), giving clear guidance on when to use. It does not explicitly mention when not to use or offer alternatives, but the context provided is sufficient for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the requirement (USE_WING), the data type (UINT16), and the default value (1000). This provides useful behavioral context beyond a simple name repetition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence with the name, explanation, requirement in parentheses, and type/default in brackets. Every part is essential, and the key info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and no parameters, the description covers the essential aspects: what is retrieved, the prerequisite, and the value type/default. It lacks details on failure modes or return format, but such details are minimally necessary for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (0 params, schema coverage 100%), so no parameter descriptions are needed. The description adds value by stating the type and default of the value being retrieved, which is beyond what the empty schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'tpa_speed_adv_drag_k', specifying it as the aerodynamic drag coefficient for the advanced speed TPA physics model. Among many sibling getter tools, it distinguishes itself by naming the specific coefficient and model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite: 'Requires: USE_WING', indicating when this tool is applicable. However, it does not explicitly contrast with alternative tools or state when not to use it. The context is implied but not fully developed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavior. It clearly states that this is a read operation (Get), describes the value's purpose, and includes data type (UINT16) and default (50). There is no indication of destructive side effects, and the description is consistent with a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining the tool's purpose, followed by a note on requirements and the type/default. No unnecessary words; all information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description adequately explains the meaning and effect of the returned value. It also notes a prerequisite (USE_WING). It could mention range or typical values, but it is largely complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (schema coverage 100%), so the description does not need to explain parameters. However, it adds value by explaining what the returned value represents (gravity factor affecting TPA response curve). This goes beyond the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving a 'gravity factor for BASIC speed TPA' and explains its role in affecting the TPA response curve vs airspeed. This distinguishes it from related tools like get_tpa_speed_adv_drag_k or other get_tpa_* tools, which deal with different TPA parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions that the tool requires USE_WING, providing a prerequisite. However, it does not explicitly state when to use this tool versus alternatives (e.g., get_tpa_speed_basic_delay or set_tpa_speed_basic_gravity). Given the large number of sibling tools, more guidance would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses read-only nature, data type (UINT8), default value (30), and states it does not affect alarm thresholds. This is good behavioral context for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Key information front-loaded: purpose, effect, type, default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential aspects: purpose, type, default, and key behavioral constraint. Could add valid range (0-255) for UINT8, but still adequate for a 0-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100%. Description adds value by specifying type and default, which are not in the empty schema, earning above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the LPF period for voltage on OSD, with specific verb and resource. Distinguishes from siblings (e.g., get_vbat_sag_lpf_period) by clarifying it smooths display flickering and does not affect alarm thresholds.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. The note about not affecting alarm thresholds implies it's for display only, but no direct comparison to get_vbat_sag_lpf_period or other related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description correctly indicates this is a read-only operation retrieving a UINT8 value with a default of 110. No annotations exist to contradict, but the description adds minimal behavioral detail beyond the tool name and type info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus type information. It conveys the essential purpose and usage without any extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers the core function, calibration context, and type/default info. It lacks details about the exact return format or integration with other calibration steps, but remains sufficient for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is complete. The description does not need to explain parameters; the baseline score of 4 applies as it adds no confusion.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the vbat_scale voltage divider calibration value. It explicitly states the purpose is for calibration ('Adjust until reported voltage matches a multimeter'), and the name and context distinguish it from set_vbat_scale and other battery-related get tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that this tool is used in a calibration workflow, encouraging iterative check-and-adjust. However, it does not explicitly exclude alternative tools like get_vbat_divider or get_vbat_multiplier, though the calibration context differentiates it sufficiently.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose behavioral traits like side effects, permissions, or return format, but the behavior is simple and read-only.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description is sufficient, though it could mention the return type for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the description adds no parameter info; baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Betaflight firmware version and build information, effectively distinguishing it from siblings that retrieve specific settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is straightforward and implies when to use it, but there is no explicit guidance on when not to use or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description explains the setting's effect ('reverse yaw PID output sign') and includes data type [INT8, default: OFF]. However, it does not confirm idempotency or that it is a read-only operation (though 'get' implies it).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence with action, one with usage, and a type hint. Front-loaded with the key purpose. No superfluous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description covers purpose, usage, and data type. Lacks explicit mention of return value, but it's implied. Sufficient for decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. The description adds value by annotating the data type and default value, which are absent from the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description specifies verb 'Get', resource 'yaw_motors_reversed', and explains it reads the reverse yaw PID output sign setting. It distinguishes from sibling 'set_yaw_motors_reversed' by name and usage context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
States 'Use when motor spin direction is swapped from normal', providing a clear scenario. Does not explicitly list when not to use or alternatives, but the sibling setter is implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read-only operation (list) but does not disclose any potential behavioral traits such as system dependencies, required permissions, or performance implications. With no annotations, the description is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary information. Every word contributes to understanding the tool's function and usage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless tool, the description is sufficient. It explains the purpose and usage context. However, without an output schema, a brief note on the return format (e.g., a list of port identifiers) would enhance completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters are defined, and the schema is fully covered. The description adds no parameter details, but since there are none, this is appropriate. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the action (list) and the resource (serial ports) and provides context (on this system). It also specifies the use case (find flight controller port), which differentiates it from sibling tools that focus on getting/setting parameters or calibration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells the user to use this tool to find the flight controller's port, providing clear guidance on when to use it. Although it does not explicitly mention when not to use it, the simplicity of the tool makes this less critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It mentions using MSP and lists checked items, but does not disclose side effects, return format, or whether it is read-only. Moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: one for purpose, one for usage instruction. Both are front-loaded and concise with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and many sibling individual-parameter tools, the description explains what is checked and ordering context, but lacks details on output format (e.g., what constitutes a pass/fail) and does not explain the 'MSP' acronym.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, and schema coverage is 100%. The description adds value by listing the specific checks performed, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Run a comprehensive preflight safety check' and lists specific items (arming readiness, battery voltage, GPS lock status, CPU load). This distinguishes it from sibling tools that retrieve individual parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'call this before any CLI tools in the same session (uses MSP)' provides explicit ordering context and suggests a prerequisite relationship. No explicit alternatives or when-not-to-use, but the guidance is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses one key behavior ('Will disconnect any existing session first') but does not mention failure scenarios, whether it is a destructive operation, or any required permissions. The description adds some value but lacks full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the primary action, followed by a use-case example and a behavioral note. Every sentence earns its place with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and no annotations, the description covers the essentials: what it does, when to use it, and a key behavior. It lacks details on what happens if there is no previous connection or on failure, but is otherwise complete for a simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4. The description explains that the tool uses the last connected port and baud rate, adding meaning beyond the empty input schema. It does not need to explain parameters, but the behavioral context is helpful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Reconnect to the last connected flight controller using the same port and baud rate.' It specifies the verb 'reconnect' and the resource 'flight controller,' and distinguishes itself from siblings like 'connect_flight_controller' by emphasizing it uses stored credentials and disconnects any existing session.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear use case: 'Useful after a reboot (e.g. following cli_save or reboot_flight_controller).' It also warns that it will disconnect any existing session, but does not explicitly state when not to use it or name alternative tools. However, the context is sufficient for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavior. It explains what the setting does but does not mention persistence, reboot requirements, or immediate effect. It is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with supplementary details in brackets. It is front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers purpose, parameter range, and usage mode. It lacks mention of the corresponding getter or side effects, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a basic description, but the tool description adds meaning by stating '0 = no limit' and provides the default and type in brackets, enhancing understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a limit on accelerometer correction in angle/horizon mode, with the parameter impact explained. It distinguishes from sibling setters by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use in angle/horizon mode and explains the meaning of 0, but does not explicitly compare to related tools like set_acc_limit_yaw or get_acc_limit. Still, context is clear enough for a typical setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that 0 means 'no limit', and provides value range and default. However, does not mention persistence or side effects like requiring reboot or immediate effect. With no annotations, more behavioral detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two short sentences with no redundant words. Purpose, sibling reference, special value, and format are all front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately describes a simple setter with one parameter. Covers purpose, range, default, and special value. Could mention effect timing, but given the tool's simplicity and lack of output schema, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage but description adds '0 = no limit' and default value, which are not in schema. Provides meaningful extra context beyond the schema's brief description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Set' and resource 'acc_limit_yaw'. References the sibling tool 'acc_limit' to distinguish the yaw axis variant. Provides value range and default. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly compares to 'acc_limit', indicating when to use this tool (yaw axis) vs its sibling. However, it does not mention any alternative tools or provide 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It explains that higher values cause motors to idle before airmode engages, which is useful behavioral insight. It also provides type, range, and default, adding transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with three sentences: purpose, behavioral effect, and constraints/range. No redundant information; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a single-parameter setter with no output schema, the description covers purpose, behavioral effect, and constraints. It could mention prerequisites or side effects, but for a simple parameter write, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the parameter's role (throttle threshold for airmode) and the effect of higher values. The default value is also stated, which is not in the schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the throttle percentage at which airmode activates. It specifies the verb 'Set' and resource 'airmode_start_throttle_percent', and the function is distinct from sibling get/set tools for other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for configuring airmode behavior but does not provide explicit when-to-use or when-not-to-use guidance. It lacks comparison with sibling tools like other set_ functions, so the agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses unit (tenths of degrees), requirement (USE_WING), and default value (0). Lacks mention of immediate vs persistent effect or side effects, but for a simple setter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: one sentence with purpose, followed by requirement and type/default in parentheses. Every part is essential, no wasted words, and front-loaded with the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (single parameter, setter), the description covers purpose, usage context, requirement, and parameter semantics. Only minor missing detail is whether the change takes effect immediately or after reboot, but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with parameter description 'Value for angle_pitch_offset (INT16)'. The description adds crucial semantic details: unit (tenths of degrees), purpose (pitch trim offset), and default (0), which enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set angle_pitch_offset' and explains it is a pitch trim offset in tenths of degrees for angle mode, used to adjust the level hover point. Distinguishes from sibling getter tool 'get_angle_pitch_offset'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use ('adjust the level hover point without reflying') and requires USE_WING feature. Does not explicitly state when not to use, but context is clear given no similar setter exists among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it's a set operation (mutation) but doesn't disclose side effects, permissions, or state changes. For a simple parameter setter, this is adequate but not exceptional.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a compact type/range/default note. All information is front-loaded and every part adds value. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description is sufficiently complete. It explains the purpose, parameter semantics, and tuning guidance. No obvious gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, but description adds meaningful context: explains what the parameter controls (LPF cutoff for throttle derivative) and its effect on response time. Also provides range and default in text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets a LPF cutoff for throttle derivative used by anti-gravity, with specific verb 'Set' and resource 'anti_gravity_cutoff_hz'. It distinguishes from sibling get_ and set_ tools for other anti-gravity parameters by specifying the exact parameter being set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides tuning guidance: adjust for very large or small builds, with direction of effect (larger = faster response). Lacks explicit when-not-to-use or alternatives, but the context of adjustment is clear given the single parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the behavioral effect (prevents yaw/pitch dip) and tuning symptom (wobbles). Annotations are absent, so the description carries full burden. It lacks mention of whether changes persist after reboot or require additional steps, which is a gap for a setter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus a metadata tag. Front-loaded purpose with no filler. Every word contributes to understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one param, the description covers purpose, effect, tuning guidance, and default. Does not explain persistence or relationship to other anti_gravity parameters, but still sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (one parameter with description). The description adds the default value (80) and reiterates the UINT8 type, which adds value beyond the schema. Baseline is 3, plus 1 for the extra default info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets anti_gravity_gain, explains its effect (boosts I-term to prevent dip on punch), and distinguishes from get_anti_gravity_gain. Among many set_* siblings, this is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit tuning advice ('Reduce if throttle-punch wobbles appear'), indicating when to lower the value. Does not mention alternatives like set_anti_gravity_cutoff_hz or set_anti_gravity_p_gain, but gives enough context for the typical use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the burden. It states the parameter type (UINT8) and default (0), but does not disclose side effects like requiring a reboot or recalibration. Adequate for a configuration setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single concise line with inline annotations for requirement, type, and default. No wasted words; front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one input, the description covers purpose, parameter meaning, requirement, and default. No output schema, but return values are implied. Complete enough for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes value as 'Value for baro_i2c_address (UINT8)'. Description adds 'I2C address override for barometer (0 = default auto-detect)' and default, providing meaning beyond schema. With 100% schema coverage, baseline is 3, but additional context raises it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set baro_i2c_address: I2C address override for barometer', distinguishing it from the sibling get_baro_i2c_address. The verb and resource are specific, and the description of 0 as auto-detect adds clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Specifies a prerequisite (Requires: USE_BARO) and explains the meaning of value 0 as auto-detect. While it doesn't explicitly contrast with alternatives like set_baro_i2c_device, the context is sufficient for a simple parameter setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains that the tool excludes servo data from logs, which is a simple toggle. The description does not mention side effects, persistence, or whether changes take effect immediately or after reboot. Given the simplicity, it is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a parenthetical requirement note. It is front-loaded with the action and includes only necessary information. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean configuration tool with no output schema, the description is nearly complete. It covers the purpose, parameter, and a key requirement. It might miss that the setting affects only future logs, but that is a minor gap. Overall, it provides sufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'value' (enum OFF/ON). The description adds a default value ('OFF') and the data type ('UINT32'), which are not in the schema description. This extra context helps the agent understand the parameter beyond the enum.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and specifies the resource and action: 'Exclude servo output data from logs'. This distinguishes it from sibling tools like set_blackbox_disable_acc or set_blackbox_disable_gyro by focusing on servos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes a requirement: 'Requires: USE_SERVOS'. This tells the agent when the tool is applicable. It does not explicitly state when not to use or suggest alternatives, but the requirement provides clear usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the effect on logging rate and size, but the parameter type is ambiguous: the schema expects a string, yet the description says '[UINT8, default: 1/4]', which could confuse an agent about the exact format required. It also does not clarify whether the change is persistent or immediate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with only three sentences. It front-loads the purpose, provides examples, and notes the default and type information. Every sentence is informative and earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and lack of output schema, the description covers the core aspects: purpose, parameter effect, and examples. It does not explain persistence or immediate effect, but that is common for such settings. The type ambiguity is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a basic description, but the tool description adds significant value by explaining the fraction concept, giving concrete examples with gyro rate, and stating the default. However, the UINT8/string inconsistency slightly detracts from clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set blackbox_sample_rate: Fraction of PID loop iterations logged.' It uses a specific verb ('Set') and resource ('blackbox_sample_rate'), and distinguishes from the many other set_* tools by focusing on the sampling rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage guidance by explaining the trade-off between log rate and size ('Finer rates = larger logs'), helping the agent understand when to use finer or coarser rates. However, it does not explicitly compare to other blackbox-related settings like mode or device.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that 0 disables motors and >0 enables, recommends 100. It also specifies data type and range. However, it does not mention side effects, persistence, or conditions for effectiveness (e.g., active crash flip mode).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus range info. It front-loads the purpose and provides all essential information without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter without output schema, the description covers purpose, parameter semantics, default behavior, and recommended value. It does not mention instant effects or restart requirements, but these are minor for such a tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a basic description. The tool description adds significant value by explaining the effect of different values (0 vs >0) and recommending 100, which goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the motor output percentage during crash flip/turtle mode. It explains the effect of 0 (disabled) and >0 (enabled, recommending 100). This distinguishes it from sibling set_ tools, each for different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: when to use (to enable/disable flip thrust). It recommends 100 for enabling. However, it does not explicitly state when not to use or list alternatives, but since each set_ tool targets a unique parameter, no direct alternative exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the parameter type (UINT8), default (40), and constraint (≥ d_roll). However, it does not specify side effects, persistence, or validation behavior on constraint violation. For a simple parameter setter, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences with no wasted words. It front-loads the action ('Set d_max_roll') then provides the explanation and constraints efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description covers purpose, type, default, and a key constraint. It does not mention error handling if the constraint is violated, but overall it is sufficiently complete for a parameter-setting tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds significant meaning: explains the parameter as a dynamic damping ceiling for fast moves, specifies the default value (40), and imposes a constraint (≥ d_roll). This goes beyond the schema's generic 'Value for d_max_roll (UINT8)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Set d_max_roll' (verb+resource) and explains it as 'Dynamic damping ceiling — D value used during fast moves.' This clearly distinguishes it from siblings like set_d_roll (regular damping) and set_d_max_pitch/yaw (different axes) by specifying the dynamic context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use this tool: 'during fast moves' and provides a crucial constraint 'Must be ≥ d_roll'. While it does not explicitly state when not to use or mention alternatives, the purpose is clear enough for an AI agent to select it appropriately among similar set commands.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates mutation ('Set') and gives a default value, but does not disclose side effects, persistence, or whether a reboot is needed. This is adequate but minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences, front-loading the purpose, then the condition, then the type/default. Every part is necessary and efficiently presented.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of a single-parameter setter with full schema coverage, the description provides adequate context for an agent to use it correctly. No output schema exists but is not needed for a setter. Minor gap: no mention of immediate effect or requirement to save/reboot.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the parameter with a description, but the description adds the default value (75) and emphasizes that the value is an INT16, which the schema lacks. This extra info improves semantics beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'dterm_lpf1_static_hz', explaining it as the 'Static cutoff for D-term LPF1'. This distinguishes it from sibling tools like set_dterm_lpf1_dyn_hz by specifying when it's used.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the condition for use: 'Used when dterm_lpf1_dyn_min_hz == dterm_lpf1_dyn_max_hz'. This implies that otherwise one should use dynamic variants, though it does not name them explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds context (enable by non-zero, target by prop size) but lacks details on persistence, side effects, or state requirements. Adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, front-loaded with the parameter name, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description explains the parameter, enable condition, and selection method. It could explicitly state that zero disables, but it's largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds the default value and targeting guidance beyond the schema's basic type and range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set dyn_idle_min_rpm' and explains its function as 'Minimum motor RPM maintained by dynamic idle'. It distinguishes from siblings by naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides guidance on when to enable ('Set non-zero to enable') and how to target the value ('Target by prop size'), but does not explicitly exclude other tools or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the effect (enable/disable stick arming) and notes the default is OFF. However, it does not disclose if changes take immediate effect or require reboot, which would be useful for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a parenthetical note, no wasted words. It front-loads the action and provides essential context immediately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setting tool with one input and no output schema, the description adequately explains the parameter's purpose and default. It could mention if the value expects 'ON'/'OFF' or numeric, but the schema and description together suffice for basic use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single parameter. The description adds value by explaining the UINT8 type, default OFF, and the meaning of enabling vs disabling. This goes beyond the schema's generic 'Value for enable_stick_arming (UINT8)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets enable_stick_arming, explaining it enables stick-combination arming (throttle-down/yaw-right). The verb 'Set' and resource 'enable_stick_arming' are specific, and the explanation distinguishes it from sibling set_ functions for other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance: enable for stick arming, disable if using a dedicated arm switch. This tells the agent when to use each option, but does not explicitly list alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It correctly states that the tool sets a threshold value and includes valid range and default. However, it does not disclose whether the change is persistent or requires a reboot, which would be helpful for a configuration parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: it starts with the tool name, gives a functional definition, provides usage instructions, and ends with metadata. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter config tool with no output schema, the description provides complete context: what the parameter does, its valid range, default, and when to use it. It could mention persistence or immediate effect, but it is sufficiently complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant value beyond the schema: it explains that the value represents degrees from center, its role in failsafe recovery, and provides the default. This complements the schema's type/range information and makes parameter semantics clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the verb (Set), resource (failsafe_stick_threshold), and provides context: it is the stick deflection required to exit GPS Rescue Stage 2 after signal recovery. This distinguishes it from the many other set_* tools by linking to a specific failsafe behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when to use it ('Move sticks to this threshold once video returns and RXLOSS clears'), providing clear operational context. It does not explicitly state when not to use it or list alternatives, but the scenario-based guidance is sufficient for proper invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the dual-role behavior in failsafe stages, the default meaning, and the critical consequence for GPS Rescue if set incorrectly. This is good transparency for a numeric setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences. First defines purpose and scope, second gives default, third adds critical consequence. No redundancy, well front-loaded, every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description explains the throttle's role in failsafe stages and GPS Rescue. Missing output schema is acceptable for a setter. Provides sufficient completeness given the tool's simplicity and lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds value beyond schema by specifying default (1000) and contextual meaning (motors off, hover throttle for GPS Rescue). The schema already indicates UINT16, so description complements rather than replaces.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the failsafe_throttle value, specifies where it applies (Landing Mode Stage 2 and Stage 1 fallback), and provides critical context (default, GPS Rescue). It distinguishes itself from many sibling set_ tools by its specific resource and behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives context on when the throttle is applied and a crucial GPS Rescue requirement, but does not explicitly state when to use this tool versus alternatives like other failsafe settings or get_failsafe_throttle. No when-not guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the core behavioral effect (suppressing FF on slow/jittery inputs) and the tuning impact. However, it omits details like persistence, whether a reboot is required, or any side effects. The description is adequate but not fully transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence plus a concise range/default note. Every part adds value: the purpose, behavioral effect, tuning guidance, and parameter constraints. It is front-loaded and efficiently communicates all essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter with no output schema, the description covers the parameter's effect, tuning trade-offs, range, and default. It does not discuss persistence or side effects, but these are less critical for a basic configuration tool. The description is largely complete for its simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema coverage is 100%, but the description adds the default value (7) and the type hint (UINT8), which are not in the schema. It also gives context for parameter tuning. This adds meaningful value beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'feedforward_jitter_factor'. It explains the effect: suppresses feedforward on very slow or jittery stick inputs. It provides tuning guidance for different flying styles (freestyle/HD vs racing), making the purpose highly specific and actionable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives implicit usage guidance by linking higher values to smoother center feel (suitable for freestyle/HD) and lower values to snappier response (for racing). It does not explicitly mention when not to use or alternatives, but the context of flying style helps agents decide when to adjust this parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It discloses the key behavioral effect (arming allowed without fix) and a visible consequence (OSD shows 'RESCUE OFF'), plus the data type and default. It lacks persistence or reboot requirements, but the main behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bracketed note. Every sentence adds value by stating the function, the consequence, and the parameter format. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description covers purpose, behavior, and parameter details. However, it omits whether the setting is persistent or requires a reboot, and does not describe the return value (likely success/failure). Given no output schema, these are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a generic schema description. The description adds value by specifying the default value ('OFF'), the type (UINT8), and the behavioral context (effect on arming and GPS rescue). This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'gps_rescue_allow_arming_without_fix'. It explains the purpose: allow arming without a GPS fix, and notes the consequence that GPS rescue is unavailable. This effectively distinguishes it from other GPS rescue parameter setters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage is for allowing arming without a GPS fix, but does not provide explicit guidance on when to use this vs. alternatives (e.g., leaving it OFF for safety). No when-not or alternative tools are mentioned, placing it at a mid-level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It indicates a write operation ('Set') but does not disclose side effects, persistence, or validation details beyond the schema's min/max. The behavior is adequate for a simple parameter setter, but lacks added behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (one sentence plus a parenthetical), front-loads the purpose, and contains no fluff. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers the purpose, parameter meaning, range, default, and a usage tip. It could mention that this is for the GPS rescue feature, but that is implied by the name. Overall, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by providing a real-world conversion (750 ≈ 27 km/h) and a usage tip (reduce for wind). This goes beyond the schema's description of 'Value for gps_rescue_ground_speed (UINT16, 0–3000)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the gps_rescue_ground_speed parameter and defines it as 'Forward speed during return (cm/s)'. It provides a conversion example (750 ≈ 27 km/h) and a usage hint. The naming and context distinguish it from sibling tools like set_gps_rescue_ascend_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: 'Reduce for reliability in windy conditions.' It implies when to use (when adjusting GPS rescue speed) but does not explicitly state when not to use or compare to alternatives. However, the tool name and sibling context make its purpose clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the parameter's purpose and constraints (range, default) but lacks details on side effects (e.g., persistence, whether changes take effect immediately or require a reboot). The description is adequate but not comprehensive for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences plus a range note. Every sentence adds value: purpose, usage guidance, and constraints. No redundant or extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is largely complete. It covers what the parameter does, how to set it, and its limits. It lacks mention of related parameters or persistence behavior, but these are minor omissions for this tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% but merely repeats the type and range. The description adds meaning by explaining the role of the altitude ('climb from current position before heading home') and the advisory to clear obstacles, which enhances the agent's understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the initial climb altitude for GPS rescue, with a specific verb ('Set') and resource ('gps_rescue_initial_climb'). It explains the purpose: climbing from current position before heading home, and distinguishes itself from numerous sibling 'set_' tools through its specific naming and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical guidance on choosing the value ('Set high enough to clear local obstacles'), which helps agents decide on an appropriate parameter. However, it does not explicitly contrast with related tools like set_gps_rescue_return_alt or set_gps_rescue_alt_mode, nor does it state when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond schema: explains CPU load impact and potential to enable 8k8k on some boards. However, does not disclose persistence, side effects on other GPS settings, or whether a reboot is required. With no annotations, these gaps are notable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a compact note with range/default. All information is essential, no redundancy. Front-loaded with key purpose and recommendation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers purpose, usage scenarios, and value recommendations. It does not explain return behavior, but with no output schema, the agent can infer no return value. Minor gap: no mention of persistence or immediate effect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with basic description, but the tool description adds meaning by explaining the rationale behind different values (10 Hz for GPS rescue, low Hz for CPU savings). This helps the agent choose appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets the GPS update rate, with specific recommendations for different use cases (GPS rescue vs not). Distinguishes itself from numerous sibling set_* tools by being uniquely about gps_update_rate_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance on when to use 10 Hz (GPS rescue) versus 1-2 Hz (otherwise, to reduce CPU load). Lacks explicit 'when not to use' statements but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must fully convey behavioral traits. It states that calibration restarts if movement exceeds the threshold, which is key. However, it fails to mention whether the setting is persistent, if a save is required, or if it takes effect immediately. More context would improve transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a parenthetical with range and default. Every word adds value. The purpose is front-loaded, making it easy for the agent to quickly understand the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is reasonably complete. It explains the parameter, its effect, and usage advice. However, it lacks mention of related tools (e.g., get_gyro_calib_noise_limit) or any confirmation step, which would be helpful for full autonomy.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (the single 'value' parameter is described). The description adds practical guidance on when to increase the value, going beyond the schema's type and range. This helps the agent determine the correct parameter value in context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting the gyro calibration noise threshold, which affects calibration behavior. It explains that if movement exceeds this threshold, calibration restarts, and provides guidance for noisy environments. This distinguishes it from many sibling set_* tools by specifying the exact resource (gyro_calib_noise_limit) and its effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a practical usage guideline: 'Increase if it won't calibrate in a noisy environment.' This tells the agent when to adjust the parameter. However, it does not explicitly state when not to use the tool or mention alternatives (e.g., using the getter first). Nevertheless, for a simple setter, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that this is a write operation, provides a constraint, and mentions the default value (0) and type (UINT16). However, it does not specify the valid range (0-65535 for UINT16), or what happens if the constraint is violated, or side effects on flight behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, includes the constraint, type, and default. Every part is necessary and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description covers the essential elements: what is set, the constraint, type, and default. However, it could be improved by explicitly stating the units (Hz) and briefly noting the effect on gyro filtering.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema covers 100% of parameters but only gives type and description 'Value for gyro_notch1_cutoff (UINT16)'. The description adds meaning: 'Bandwidth of gyro notch 1', the constraint relative to gyro_notch1_hz, and the default value. This provides significant added value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'gyro_notch1_cutoff' with the meaning 'Bandwidth of gyro notch 1'. It distinguishes this tool from siblings like set_gyro_notch1_hz by specifying cutoff vs. frequency and notch 1 vs. notch 2.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the constraint 'Must be less than gyro_notch1_hz', which is crucial for correct usage. However, it does not provide explicit guidance on when to use this tool vs. alternatives (e.g., other filter settings) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Describes write operation implicitly, but no details on side effects, persistence, or system impact. Adequate for simple parameter setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with key info front-loaded. No redundant words. Bracketed type and default add useful detail without clutter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-param setter with no output schema, description covers purpose, special value, and use case. Lacks explicit unit (Hz) but inferred from name. Reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema: '0 = disabled', 'centre frequency', default value. Schema only provides type and range; description explains special behavior.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it sets centre frequency of static gyro notch 1, with special value 0 for disable. Distinguishes from dynamic notch and other gyro filters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use for specific persistent resonances not handled by dynamic notch', providing context for when to use. Lacks explicit when-not-to-use or alternatives, but gives clear indication.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description provides unit (tenths of degrees/s), range (-1000 to 1000), default 0, and data type (INT16). It explains the effect on yaw drift, but does not disclose whether changes take effect immediately, require reboot, or are persistent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence followed by a parenthetical with technical details. It is front-loaded with the purpose and has no superfluous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, full schema coverage, and no output schema, the description adequately covers purpose, usage, and parameter details. It could mention persistence behavior but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already describes the parameter fully (100% coverage). The description adds context by explaining the parameter's role in correcting drift and reiterating the range and default, providing additional meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set', the resource 'gyro_offset_yaw', and explains it as 'Manual yaw gyro trim (tenths of degrees/s)'. It distinguishes from siblings like set_acc_trim_* by specifying it's for yaw drift when trim sticks or acc trim are insufficient.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use: 'Use to correct persistent yaw drift if trim sticks or acc trim are not sufficient.' It implies alternatives are considered first, but does not name sibling tools explicitly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the effect of the parameter value on behavior, but omits operational details such as whether the setting is immediately applied, requires a reboot, or is persistent. This is a gap for a write operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single dense sentence that packs purpose, effects, and default. It is front-loaded with the tool name and zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (1 parameter, no output schema). The description explains the parameter's effect and default, but does not mention return value or persistence behavior. This is mostly complete for an experienced user, but an agent might benefit from knowing the set operation is acknowledged.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% description coverage for the single parameter, providing baseline 3. The description adds the default value (80) and the tuning implications (drift/wobble), which go beyond the schema's 'Value for i_roll (UINT8)'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the roll I gain, correcting accumulated angle error and maintaining attitude. It distinguishes itself from sibling tools like set_i_pitch by specifying 'Roll I gain' and providing unique tuning consequences (drift vs. wobble).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides tuning guidance (too low → drift, too high → slow post-flip wobble) and mentions the default value 80. However, it does not explicitly compare to alternatives like set_i_pitch or set_d_roll, leaving the decision when to use this tool vs. others somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description fully bears the responsibility. It explains the behavioral effect (holding angle setpoint vs. actively leveling) and mentions data type (UINT8) and default (OFF). Minor omission: prerequisite of being in angle mode not stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with essential notes, front-loaded with the key behavior, and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setting tool with no output schema, the description covers behavior, parameter type, and default effectively. It lacks mention of prerequisites (e.g., needing to be in angle mode) but is otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (one parameter). The description adds context about data type and default beyond the schema's description, but does not significantly enhance understanding of the parameter's acceptable values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'level_race_mode', and explains its effect: 'holds the current angle as the setpoint rather than actively leveling' for racing use. This distinguishes it from other settings among many sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for racing scenarios where holding the angle setpoint is desired. However, it does not explicitly state when not to use or mention alternatives, but given the simple nature of the toggle, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries burden. States it sets a value (mutation), gives range and default. Lacks details on side effects or reboot needs, but adequate for a simple parameter set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence with purpose, URL, prerequisite, and inline parameter details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers purpose, source for value, prerequisite, and parameter constraints. Lacks mention of when this should be done (e.g., per location), but sufficient for operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage with description, but description adds context: 'Value for mag_declination (INT16, -300–300)' and default, enhancing schema info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Starts with 'Set mag_declination' – a specific verb+resource. Explains it's for magnetic declination correction for your location, distinguishing it from get_mag_declination and calibrate_magnetometer.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides a URL to find the correct value and notes the prerequisite 'USE_MAG' requirement. Clear context for usage, though does not explicitly contrast with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description adds range, default, and type information. However, does not disclose whether changes are persisted, require reboot, or affect other parameters. For a simple setter, this is adequate but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences and a format block. Front-loaded with 'Set mid_rc: RC mid-point.' Every word earns its place. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with full schema coverage and no output schema, the description covers purpose, range, default, and a practical example. Missing info on persistence or side effects, but adequate for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes the parameter. Description adds practical meaning: 'RC mid-point' and a real-world use case (Futaba 1520), enhancing understanding beyond schema alone. Schema coverage is 100%, baseline 3, but context lifts it to 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the RC mid-point (mid_rc) to match transmitter stick center, with example for Futaba and range. Distinguishes from numerous sibling set_ tools by specifying this unique parameter's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear guidance to match transmitter stick center and a specific example (Futaba 1520). Does not explicitly state when not to use or mention alternatives, but the context is obvious given the parameter name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It reveals that the value is used in internal calculations and affects RPM limit and dynamic idle, offering moderate transparency. However, it does not specify whether changes take effect immediately or require a reboot, nor does it mention any side effects or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using two sentences plus a compact range/default notation. Every word adds value, and the structure is front-loaded with the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description adequately covers the tool's purpose, parameter details, and impact. It lacks only minor behavioral details like effect timing or error handling, but overall it is sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The description adds the default value (1960) and explains the importance of setting the correct value for accurate features, which supplements the schema's range and description. The bracket notation succinctly conveys type and range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the motor KV rating and explains its role in internal calculations. The verb 'Set' combined with resource 'motor_kv' is unambiguous, and the range/default are provided, making it easy to distinguish from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises setting to actual motor KV for accurate RPM limit and dynamic idle, providing clear context for when to use the tool. However, it does not explicitly state when not to use it or mention alternative tools, which would be helpful given the large number of set_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses the parameter range and default but does not mention effects after setting (e.g., immediate effect or reboot needed) or prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a bracketed note. Every word is functional, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one parameter and no output schema, the description is largely complete. It lacks explanation of what happens after invocation (e.g., immediate effect or reboot), but for a simple setter, it covers the essential aspects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds meaning by specifying the type (UINT16) and default value (480) beyond the schema's min/max/description. This helps the agent understand the expected value format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool sets the PWM frequency for brushed motor mode. It explicitly distinguishes it from DSHOT protocols, which is a key differentiator among the many sibling set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates it is for brushed motor mode and not relevant for DSHOT protocols, giving context on when to use. However, it does not explicitly mention when alternatives like motor_set or other set tools might be preferred, though the specificity helps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explains the divisor effect and gives examples, but does not disclose whether changes take effect immediately, require reboot, or any side effects. This is adequate for a simple parameter setter but lacks 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: four sentences that cover the definition, an example, target rates, and the parameter type/default. Every sentence adds value, and the most critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description provides sufficient context through examples and target values. It could mention persistence or saving behavior, but given the nature of similar tools, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes the 'value' parameter as 'UINT8' with a default, but the description adds significant meaning by explaining how the divisor works and providing target configurations. With 100% schema coverage, baseline is 3, but the description elevates it by offering practical context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the PID loop rate divisor and explains the relationship with gyro rate and examples. The name and description together make the purpose unambiguous, and it distinguishes itself from sibling set_* tools by providing specific context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes target gyro rates for specific sensor types (BMI270, ICM-42688P, MPU-6000), providing implicit guidance on when to use certain values. However, it does not explicitly state when to not use this tool or alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full behavioral disclosure burden. It adds two key traits: the index is 0-based and the change requires an explicit cli_save to persist. This is valuable context beyond the input schema, though it could mention what 'active' means or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence states the primary action, and the second provides a critical follow-up step. Information is front-loaded and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is largely complete: it explains the main action, the 0-based indexing, and the persistence requirement. It lacks a brief explanation of what a rate profile is, but the tool name and domain make it reasonably clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (the 'index' parameter already documented as '0-based, typically 0–5'). The description reinforces '0-indexed' but adds no new semantic meaning beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Switch the active rate profile') and specifies it is 0-indexed. It distinguishes this tool from other 'set_*' sibling tools by focusing specifically on rate profiles, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
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 switch the active rate profile) and provides a follow-up instruction to call cli_save to persist. It does not explicitly exclude alternatives or provide when-not-to-use guidance, but the clear verb and resource make usage context obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It states that setting this changes the reboot trigger character and gives the valid range and default, but it does not specify whether changes take effect immediately or require a reboot, nor does it mention any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: two short sentences with no filler. It efficiently conveys purpose, parameter details, and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description covers the essential information. It lacks explicit details on return value or persistence, but these are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description, but the tool description adds significant context: it explains the parameter's role (ASCII reboot trigger), includes the default value (82), and reinforces the range. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set reboot_character'), explains the resource (ASCII character triggering reboot), and specifies the valid range and default. It distinguishes itself from sibling set_* tools by naming the specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool (to configure the reboot trigger character) and the parameter constraints. It does not explicitly mention when not to use or provide alternatives, but the purpose is clear given the context of sibling tools like get_reboot_character.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must stand alone. It explains the effect (notch depth) and hints at motor noise as a consequence of over-lowering. However, it does not mention whether changes take effect immediately, require reboot, or if there are any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences pack purpose, examples, tuning guidance, and format/default. No fluff; every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter with no output schema, the description adequately covers what, how, and best practices. Missing validation info, but that's typically handled by the schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description is minimal (just 'Value for rpm_filter_weights (UINT8)'). Description adds significant meaning: explains comma-separated format, default value, and provides examples. Completely compensates for schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets per-harmonic notch depth percentage for RPM filter. Distinguishes from other set_ tools by specifying the exact parameter. Examples for tri-blade and bi-blade props further clarify usage.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific tuning advice: lower each value as far as possible without motor noise. Recommends values for different prop types. No explicit exclusion of alternatives, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description mentions value type (INT8) and default (OFF) but does not disclose persistence, immediate vs. reboot effect, or side effects. Basic transparency but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parenthetical requirement, efficiently front-loads action and constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter without output schema or annotations, description covers purpose, requirement, value type, default. Lacks details on immediate vs. reboot effect but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema describes value parameter as string (100% coverage). Description adds meaning by specifying expected INT8 type and default value, enhancing clarity beyond schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it enables per-motor RPM limit, with verb 'Set' and specific resource 'rpm_limit'. It distinguishes from sibling tools like get_rpm_limit (get) and set_rpm_limit_* (tuning parameters).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides prerequisite (USE_RPM_LIMIT required), but lacks explicit comparison with alternatives or when-not-to-use. However, the tool's simple nature makes usage fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the data type (UINT16), default value (18000), and prerequisite. However, it does not specify whether the value persists across reboots, what happens if the required feature is disabled, or any validation beyond the schema's min/max. Adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with a parenthetical for requirements and defaults. It is front-loaded with the main purpose, and every phrase adds value—no fluff. Exceptionally concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter, the description covers the purpose, parameter semantics, default, and prerequisite. It could briefly mention the relationship with set_rpm_limit (the feature toggle) for full context, but the provided information is sufficient for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the parameter with a description and type, but the description adds the default value of 18000 and the unit context (RPM), which are not in the schema. This additional information helps the agent understand the expected value beyond the schema's generic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: setting the maximum motor RPM when `rpm_limit` is ON. It includes the specific resource (rpm_limit_value) and verb (Set), distinguishing it from siblings like set_rpm_limit (which likely enables/disables the feature) and other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: it notes that this setting applies 'when rpm_limit is ON' and explicitly lists the prerequisite `Requires: USE_RPM_LIMIT`. While it doesn't explicitly say when not to use it or name alternatives, the condition is sufficient for an agent to decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the effect (scales P,I,D,Dmax) and default, but does not mention persistence, live application, or side effects. With no annotations, more behavioral detail would be helpful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with key info front-loaded. No wasted words, includes range hint and default.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple setter with one parameter. Explains what the parameter does and its default. Lacks mention of whether changes take effect immediately or require reboot, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but description adds significant context: master gain slider, scales all PID, default 100, equivalent to PIDtoolbox Master Multiplier. This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states it sets the simplified master multiplier, a master gain that scales all P, I, D, and D_max together. Distinguishes from sibling tools like set_simplified_d_gain by indicating it's a global scale.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use when you want to scale all PID gains uniformly, and default of 100 indicates neutral value. But does not explicitly state when to prefer this over individual gain setters or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the default value and type, but does not mention persistence, side effects, or validation behavior beyond schema constraints.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with essential details (purpose, requirement, type, default) and no filler. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description is complete: it covers purpose, parameter semantics, requirement, and default. The schema handles range constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema describes the parameter. The description adds meaning by explaining the parameter as 'Setpoint centre value at which no attenuation is applied (roll)' and notes default and type, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the roll center value for attenuation, distinguishes from siblings like set_spa_roll_mode and set_spa_roll_width by specifying 'roll' and the concept of center vs mode/width.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite `USE_WING`, providing context for when the tool is applicable. However, it does not explicitly state when to use versus alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the effect (linearises thrust curve, improves low-throttle authority) and notes 'no effect above mid-throttle'. However, it does not disclose whether the change is persistent across reboots or takes effect immediately, which are relevant behavioral traits for a set tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a parenthetical constraint. The description is front-loaded with the action and resource. Every word provides value without redundancy. No unnecessary details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has a single parameter and no output schema. The description explains the parameter's purpose, typical usage, and range. It is sufficient for an agent to use the tool correctly, though a note on persistence or side effects would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema: it explains that the parameter linearises the thrust curve and suggests typical values (20–40%). This additional context helps the agent understand the parameter's role and appropriate range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Set thrust_linear', clearly indicating the verb and resource. It explains the purpose: 'Linearises the thrust curve at low throttle' and states benefits. Among many set_* siblings, this one is distinguished by its unique parameter and effect description.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use: 'especially for whoops and 48kHz ESCs', and typical range '20–40% is typically enough'. It does not explicitly state when not to use or mention alternatives, but the guidance is clear and helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses scaling, default value, and prerequisite feature. Does not mention side effects or persistence, but provides useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence plus a note and type annotation. Every element is necessary; no fluff or redundancy. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficient for a simple setter with one parameter. Covers purpose, scaling, default, and prerequisite. Lacks mention of possible side effects or interaction with other TPA settings, but overall complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage of parameter 'value' with type and range. Description adds scaling factor (×0.1%), default interpretation (70=7%), and unit context, adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the PID value at full throttle for the TPA curve, with scaling (×0.1%) and default. It distinguishes from siblings like set_tpa_curve_pid_thr0 by specifying full throttle context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions the prerequisite USE_ADVANCED_TPA feature but does not explicitly contrast with sibling tools (e.g., set_tpa_curve_pid_thr0) or provide when-to-use vs when-not-to-use guidance. Adequate but lacks exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the effect (unsynchronized PWM) and specifies the data type (UINT8) and default (OFF). While it doesn't detail side effects or permissions, it adds meaningful context beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single sentence that front-loads the purpose. Every phrase is informative and there is no redundant or unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, the description provides adequate context: the action, the effect, primary use case, data type, and default. It could be improved by specifying the range of acceptable values, but overall it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so baseline is 3. The tool's description adds context that the parameter is for unsynchronized PWM with a default of OFF, but it does not clarify valid values beyond the type. This adds some meaning but not substantial new parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set use_unsynced_pwm' and explains it sends motor PWM unsynchronized to the PID loop, primarily for brushed motors. This distinguishes it from other setter tools by specifying its unique function and target use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes 'Primarily for brushed motors,' giving a clear context for when to use this tool. However, it does not explicitly state when not to use it or provide alternatives among the many sibling setter tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description discloses key behavioral details: sets a period, default value 30, does not affect alarm thresholds, and provides the data type (UINT8). It could further clarify if any side effects exist or if a confirmation is returned, but for a simple parameter setter, this is good.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences plus inline spec—with no redundant or unnecessary words. Every sentence serves a clear purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a straightforward setter with one parameter and no output schema, the description provides adequate context: purpose, effect, what it doesn't affect, type, and default. Could mention acceptable range or if there's a confirmation, but overall sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (parameter described). The description adds value by specifying the default value (30), data type (UINT8), and the purpose (smooths display flickering). This goes beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool's function: setting the LPF period for voltage displayed on OSD to smooth flickering. It distinguishes itself from sibling tools like 'get_vbat_display_lpf_period' (read) and other vbat-related setters by stating 'Does not affect alarm thresholds'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for smoothing OSD voltage flickering and clarifies it does not affect alarms. However, it lacks explicit guidance on when to choose this tool over alternatives (e.g., other vbat settings) or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description carries full burden; it explains the purpose (prevent flicker), unit (×0.01V), range, and default, but doesn't mention persistence or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with parenthetical and bracketed notes; no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Simple one-parameter setter with full schema coverage; description covers purpose, parameter semantics, and use context sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds significant value beyond schema: explains meaning (hysteresis value), scaling, default value; schema only describes range.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Set vbat_hysteresis' (verb+resource) and explains it controls 'Hysteresis on voltage warnings to prevent flicker', distinguishing it from many sibling set_vbat_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use or avoid this tool; no mention of prerequisites or alternatives among the many voltage-related siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It notes the requirement for cell voltage monitoring and a low-voltage warning, but does not disclose whether the change is persistent, if it takes effect immediately, or if it could cause issues mid-flight. The behavioral disclosure is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is brief (3-4 sentences) and front-loads the core purpose. It efficiently includes the range, default, and a recommended value without extraneous information. Every sentence serves a clear function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter and no output schema, the description covers the parameter's meaning, range, default, and practical usage context (need for cell voltage monitoring). It does not detail what happens after setting (e.g., persistence, immediate effect), but it is fairly complete for a setter in a well-known domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already describes the parameter (integer, 0-150, default 0), so the baseline is 3. The description adds semantic value by explaining that the value represents a percentage target (90% recommended) and its purpose (consistent PID authority). This goes beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: compensating for battery voltage sag to maintain consistent PID authority and throttle output. It also provides a recommended target (90%) and the range, effectively distinguishing it from related tools like get_vbat_sag_compensation or set_vbat_sag_lpf_period.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a recommended value (90%) and prerequisite (cell voltage monitoring) as well as a caution to configure a low-voltage OSD warning. However, it does not explicitly exclude alternative tools or specify when not to use this setting, leaving some room for ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly states that the tool sets a low-pass filter on the final yaw PID output, reducing noise. It also discloses the valid range and default. While it does not mention side effects or prerequisites, the behavior is well-explained for a simple setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each serving a distinct purpose: defining the tool, explaining its effect, and providing a usage tip. No redundant or irrelevant information. It is efficiently front-loaded with the most important information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that the tool is a simple one-parameter setter with no output schema and no annotations, the description covers the purpose, effect, range, default, and special behavior. It does not mention persistence or reboot requirements, but for a straightforward parameter setter, this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by specifying the default value (100) and the special meaning of 0 (disable), which goes beyond the schema's range and description. This helps the agent select appropriate values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Set yaw_lowpass_hz' with a clear explanation of the filter's location and effect: 'Low-pass filter applied to the final yaw PID output (post-summation). Reduces yaw noise feeding into motors.' It uniquely identifies the resource and action, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one usage guideline: 'Set to 0 to disable for maximum yaw responsiveness.' However, it does not specify when to use this tool vs. alternative filter settings or when not to use it. The guidance is minimal and not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses destructive behavior (erase all settings), connection closure, and reboot. With no annotations, this is good transparency. Could mention that the connection must be reestablished, but the advice to save after reconnecting covers that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, each essential: action and warning/follow-up. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, description fully explains the effect (reset, erase, reboot, disconnect) and recommended post-action (save after reconnect). Complete for its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds no meaning beyond schema. Schema coverage is 100% (empty), baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it resets to factory defaults and reboots. The verb 'reset' is specific to 'flight controller configuration', distinguishing it from siblings like cli_save (save) and cli_diff (compare).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Warns about erasing all settings and closing connection, and advises using cli_save after reconnecting. Does not explicitly compare to individual set_ commands for partial resets, but the warning implies appropriate use for full reset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description directly discloses the behavioral effect (prevents dip on punch), the consequence of reducing it (wobbles), and includes type and default. This is sufficient for a simple parameter getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining function, one sentence of tuning guidance, and the type/default. Every part is useful and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with zero parameters and no output schema, the description fully captures what the tool does, why it matters, and how to interpret changes. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100% trivially. The description does not need to explain parameters; it adds value by explaining the parameter's purpose and effect beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's purpose clearly: retrieving the anti_gravity_gain parameter and explains its function (boosts I-term on rapid throttle changes to prevent yaw/pitch dip). It also distinguishes from countless sibling getters by giving specific behavioral context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or when-not-to-use guidelines are provided. The description includes tuning advice ('reduce if throttle-punch wobbles appear') which indirectly hints at usage but does not compare with alternatives or give comprehensive direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates a read operation ('Get') and discloses the data type, range, and default. For a simple parameter retrieval, this is sufficient behavioral disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—a single sentence with embedded technical details. It is front-loaded with the tool's name and purpose, wasting no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is complete: it explains what the tool does, the semantics of the output value, the valid range, and the default. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description adds value by explaining the meaning of the value being retrieved (seconds, disabled state, range, default), even though it doesn't pertain to parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'auto_disarm_delay' parameter, explains its meaning (seconds of throttle-zero before auto-disarm), and includes the valid range and default value. It effectively distinguishes from the sibling tool 'set_auto_disarm_delay'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool vs alternatives. Among hundreds of similar getter siblings, the tool's purpose is obvious from its name and description, but there's no mention of when not to use it or contextual prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains the meaning of each possible return value and the default, which adds value beyond a simple 'Get blackbox_mode'. It is transparent about the read-only nature and the enum semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the purpose and provides necessary details (values, type, default) without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a getter with no parameters and no output schema, the description covers everything needed: what it does, what values it can return, and the default. It is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds meaning by explaining the return value semantics (enum meanings and default), which is not provided by the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with 'Get blackbox_mode' clearly indicating the tool retrieves the current blackbox mode. It lists the possible values (NORMAL, ALWAYS, MOTOR_TEST) and specifies the data type and default, distinguishing it from sibling tools like set_blackbox_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, as a simple getter, its usage is implied. The counterpart set_blackbox_mode exists, but no when-to-use or when-not-to-use advice is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses data type, valid range, default, and per-profile scope, which is informative for a read operation. No side effects are expected, and none are misrepresented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence efficiently conveys purpose, units, type, range, default, and profile context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameter getter with no output schema, the description fully specifies return value semantics, constraints, and defaults. Agent can correctly interpret the response without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100%. Baseline 4 is appropriate as description adds no parameter info (none needed).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the crash_recovery_angle parameter, specifies units (degrees), data type (UINT8), range (5–30), and default (10 per profile). Distinguishes from siblings like get_crash_recovery and get_crash_recovery_rate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative guidance, but as a simple getter with no parameters, usage context is inherent among the many getter siblings. The existence of set_crash_recovery_angle implies the corresponding getter's role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the data type (UINT16), range (1-200), default value (5, equivalent to 0.5 s), and the parameter's behavioral context (duration for signal stability). While it doesn't explicitly state that this is a read-only operation, the nature of a 'get' tool implies it, and the details given are sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose, the parameter's meaning, and its constraints. Every part is informative with no redundancy or unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero input parameters and no output schema, the description fully explains the return value and its context. It covers the parameter's purpose, range, default, and unit, making it complete for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage by default). The description adds meaning beyond the schema by explaining the output parameter's semantics, valid range, default value, and unit. This is above the baseline of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the failsafe_recovery_delay parameter. It explains what the parameter represents (duration the signal must be stable after Stage 2) and distinguishes its role in two contexts (re-arming and GPS Rescue stick input assessment). This specificity differentiates it from other getter tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing to know the recovery delay for failsafe recovery. However, it does not explicitly state when to use this tool versus other failsafe-related getters (e.g., get_failsafe_delay) or when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses the data type, range, and default value, which are behavioral aspects of the returned parameter. However, it does not state whether this is a read-only operation or any other traits like idempotency. The lack of such info is acceptable for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bracket note. It front-loads the tool name and key definition, then provides contextual usage. Every sentence adds necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers all needed information: what the tool returns, the meaning, the range, and the context of use. It is complete and leaves no gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the schema is fully covered. The description adds value by explaining the meaning of the threshold (degrees from center) and its range/default, which goes beyond the empty schema. Baseline for zero parameters is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the failsafe_stick_threshold value, defines it as stick deflection required to exit GPS Rescue Stage 2, and provides actionable context (move sticks to this threshold after signal recovery). It is distinct from many sibling getter tools by specifying the exact parameter and its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly says when to use: to obtain the threshold needed for exiting GPS Rescue Stage 2. It does not explicitly mention alternatives or when not to use, but the usage is self-evident for a getter. The contextual instruction 'Move sticks to this threshold...' adds practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It discloses that the tool retrieves a parameter (read-only implied), and gives semantic context. No side effects or destructive actions are indicated, which is appropriate for a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is a single concise sentence that front-loads the purpose and includes essential constraints. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters, no output schema, and no annotations, the description is fully complete. It provides the parameter name, its meaning, data type, valid range, and default value.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters, and schema coverage is 100%. The description adds value by explaining the parameter's meaning and constraints (type, range, default), which exceeds the baseline of 4 for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the gps_rescue_descend_rate parameter and explains it is the descent rate when approaching home. It distinguishes from sibling get_gps_rescue_ascend_rate by specifying descent, and provides type, range, and default.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use vs alternatives. Usage is implied from the tool name and description; it is a getter for a specific parameter. No exclusion criteria or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the tool retrieves a value with type and range [UINT16, 5–500, default: 20]. This adds useful behavioral context beyond the tool name, though it does not mention side effects (which are likely none).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with the type and range in brackets. No unnecessary information, and every part is informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter getter with no input parameters and no output schema, the description is complete. It explains what is retrieved and its valid range, which is sufficient for an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description adds value by specifying the output type, range, and default, which helps the agent understand what the tool returns.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'gps_rescue_descent_dist', and explains what it represents: 'Distance from home at which descent begins'. This is specific and distinguishes it from other get_* tools which retrieve different parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as set_gps_rescue_descent_dist. However, as a simple getter for a single parameter, the context implies it should be used when reading the current value of that parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the data type range [UINT16, 0–3000], default value 750, and a real-world conversion (750 ≈ 27 km/h). No annotations provided, so description carries full burden; it adds useful behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Four brief pieces of information in a compact format. Could be slightly more structured, but no wasted sentences. Efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Sufficiently complete for a simple parameter getter. Includes purpose, units, default, range, conversion, and usage tip. No output schema, but return value is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, schema coverage is 100% for the empty schema. The description adds value with unit conversion and range notes, meeting the baseline for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool gets the forward speed during return with units (cm/s). Distinguishes from the sibling set_gps_rescue_ground_speed as the getter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific advice to reduce for reliability in windy conditions, but does not explicitly state when not to use or compare with alternatives. Since it's a simple getter, the guidance is helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description explains the behavioral effect: 'Delays return-to-level for a more acro-like feel.' This adds context beyond just reading a value. No side effects or permissions mentioned, but not critical for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracketed note. No redundant information. Every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is complete. It explains the purpose, the parameter's effect, and the expected value type and range.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema is empty (no parameters), so schema coverage is 100%. The description adds value by specifying the expected return type and range: '[UINT16, 10–5000, default: 500]', which helps the agent interpret the result.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets 'horizon_delay_ms' and explains what it is: 'Time (ms) before horizon mode re-applies leveling after sticks return to center.' It also distinguishes from siblings by specifying the exact parameter name and effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. However, as a simple getter with no parameters, the need for guidelines is minimal. The agent can infer usage from the name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the data type (UINT8), valid range (10–200), default value (75), and the semantic meaning ('gives full acro authority'). With no annotations, this provides adequate behavioral context for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with embedded technical details in brackets. It contains no redundant information and efficiently conveys the tool's purpose and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description fully covers the necessary information: what is retrieved, its type, range, default, and interpretation. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters and schema coverage is 100%. The description adds value by explaining what the returned value represents, which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get horizon_limit_sticks' and explains what it returns: 'Stick deflection (%) at which horizon mode gives full acro authority'. This distinguishes it from sibling tools like get_horizon_limit_degrees and set_horizon_limit_sticks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage to read the stick deflection threshold, but does not explicitly state when to prefer it over alternatives like get_horizon_limit_degrees or set_horizon_limit_sticks. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States it reads a value ('Get'), notes requirement 'USE_I2C_DEVICE_3', and specifies type/range. For a simple getter, this offers good behavioral context beyond 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single line with title, explanation, requirement, and default. No wasted words; every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool is simple with no params and no output schema. Description covers what is read, the requirement, and the type/default. Complete for a getter among many similar siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, so no param info needed. Description adds type hint and default value, which is useful but not about parameters. Baseline 4 for 0-param tool with 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb 'Get' and specific resource 'i2c3_clockspeed_khz' with explicit unit 'kHz'. Distinguishes from siblings like get_i2c1_clockspeed_khz and get_i2c2_clockspeed_khz by specifying bus 3.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description implies use for reading I2C bus 3 clock speed, but no explicit guidance on when to use over alternative buses or related tools like get_i2c3_pullup. Context is clear but lacks decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It accurately describes a read operation with type, range, and default, and mentions calibration context. No side effects or destructive behavior implied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with no waste: purpose, calibration hint, data type/range/default. Every sentence earns its place and is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers all essential aspects: what it returns, unit, scaling, calibration guidance, and value constraints. Complete and self-sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema is empty (0 parameters). Baseline for 0 params is 4. Description does not need to add param info since none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the ADC current sensor scale factor with units (mV/A × 10), adding value beyond the name. It distinguishes from sibling 'set_ibata_scale' and includes calibration context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage during calibration ('Calibrate against a known load') but does not explicitly state when to use this tool versus other getters or when not to use it. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It accurately describes the tool as a read operation (non-destructive), explains the parameter's role, and provides data type/range ('[UINT16, 0–32000, default: 0]'). It does not describe return format, but the explanation of the parameter value is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise, using three sentences to convey the name, purpose, effect, usage frequency, and data format. Every sentence is informative with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a simple getter: it explains the parameter's meaning and value range. It lacks explicit error scenarios or return format, but given no output schema and the tool's simplicity, the information is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, but the description adds significant value by explaining what the retrieved value represents (integral gain, acc-based yaw correction) and its valid range. This exceeds the baseline expectation for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the imu_dcm_ki parameter, defines it as 'Complementary filter integral gain', and explains its effect ('Non-zero allows slow acc-based yaw correction'). It distinguishes from siblings like set_imu_dcm_ki and get_imu_dcm_kp by being a getter for a specific parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes it is 'Rarely changed,' which implies infrequent use, but does not explicitly state when to use this tool versus alternatives like get_imu_dcm_kp or set_imu_dcm_ki. Usage is implied but not explicitly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the functionality but does not disclose behavioral traits such as side effects or permissions. Since no annotations are provided, the description carries the full burden; it adequately conveys that this is a read operation (implied by 'Get'), but lacks explicit assurance of safety or non-destructiveness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a technical note and format hint. It is front-loaded with the purpose and contains no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations or output schema, the description covers the essential aspects: what the tool does, when it is used, and the nature of the value (INT8, default OFF). For a simple getter with no parameters, it is sufficiently complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and the schema coverage is 100%. The description adds meaning by specifying the data type (INT8) and default value (OFF), which adds value beyond the schema. Baseline for 0 parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the input_filtering_mode setting, explains it enables hardware-level RC input filtering, and distinguishes it by mentioning its relevance to F1 targets versus modern hardware. This provides a specific verb-resource relationship.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on when to use the mode: required on some F1 targets, leave OFF on modern hardware. While it doesn't explicitly list alternatives or exclude situations, it gives clear guidance on the setting's typical application.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description indicates this is a read operation ('Get iterm_windup'). It discloses the parameter's function (suppressing I accumulation) and its sensible default, providing sufficient behavioral context beyond the bare fact of being a getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a parenthetical data type and range. Every word is informative, and it is front-loaded with the tool's purpose. No unnecessary text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is complete. It explains what the tool does, the meaning of the returned value, and its sensible default, leaving no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema description coverage is 100%. The description adds value by explaining the parameter's meaning, range, and default, which helps the agent understand what value will be returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the iterm_windup parameter, explaining that it suppresses I accumulation when motors are near saturation. It provides the default value (80) and range (20–100, UINT8), making the purpose specific and distinct among many get_* sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like set_iterm_windup or other get_* tools. However, from the name and context, it's clear this is for reading the parameter. No exclusions or alternative guidance are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description adds value by disclosing the return type (UINT8), default value (DSHOT600), and sensor-specific recommendations. It does not contradict any annotations (none provided).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with a parenthetical note, containing all essential information without extraneous text. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description explains the return value adequately (type, default, sensor recommendations). It could list all possible protocol values, but for a simple getter, it is reasonably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so baseline is 4 (as per rules for 0 params). The description adds meaning by explaining the return value's significance, including default and sensor-specific details, exceeding the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the motor PWM protocol (ESC communication protocol) and provides specific protocol values for different gyro configurations, distinguishing it from other get_* tools that retrieve different settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking the current motor protocol but does not explicitly mention when to use it versus set_motor_pwm_protocol or other related tools. It provides context on sensor-specific defaults but no direct guidance on alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the parameter's effect (divisor relative to gyro rate), gives calculation examples, and notes target values. It does not explicitly state read-only behavior, but 'get' implies it. Overall, sufficient transparency for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, front-loading the definition, then providing examples and target information. No redundant or irrelevant content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool (no parameters, no output schema), the description provides complete context: what the divisor is, how to interpret values, and practical tuning guidance. No gaps identified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%, so the description is not required to add parameter details. However, it provides context about the parameter's meaning and default value, which is useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly defines the tool as getting the PID loop rate divisor, provides concrete examples (denom=2 for 4kHz PID rate), and mentions target gyro rates for specific sensors. It distinguishes itself from sibling tools through the specific parameter name and context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for reading the current PID rate divisor but does not explicitly state when to use this tool over alternatives like get_imu_process_denom or the corresponding setter. No guidance on prerequisites or preferred scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the behavioral effect of the parameter (higher expo = slower center, faster edges) and notes the data type and default. For a simple read operation, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one explanatory sentence and a technical note. No fluff, front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description fully explains what the tool does and what the returned value represents. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description's mention of UINT8 and default 0 adds value. It explains the parameter's meaning beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as retrieving the roll expo parameter and explains its purpose: controlling the transition between center sensitivity and max rate. It distinguishes itself from other getters by specifying the exact parameter and its effect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this versus other getters is provided. Usage is implied (to read roll expo), but no alternative tools or conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. It explains the meaning, range (0–1000), and default (50). As a read-only getter, no side effects are implied, but the description does not explicitly state it is non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The type, range, and default are provided in a compact bracket notation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description fully covers what the tool returns and its purpose. No gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is irrelevant. The description adds value by explaining the return value's semantics (frequency band, unit, range, default).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'rpm_filter_fade_range_hz' parameter and explains its function (frequency band for notch fade at low throttle). This is specific and distinguishes it from sibling getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. As a getter, usage is inferred, but no comparisons to related getters (e.g., get_rpm_filter_harmonics) are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description adds behavioral context: the parameter controls a threshold below which notches are not applied, and includes a tuning recommendation for larger quads. This goes beyond the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, consisting of two short sentences plus a specification block in brackets. It is front-loaded with the key meaning and then provides a tuning hint.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is complete. It explains what the value represents, its range, default, and practical tuning advice.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description includes the type (UINT8), range (30–200), and default (100), which adds extra value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the rpm_filter_min_hz parameter and explains its meaning: 'Below this frequency, notches are not applied.' It also provides a tuning hint, distinguishing it from sibling get/set tools for other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when or when not to use this tool. However, since it is a simple getter with no parameters, the usage context is implicit. No alternatives are discussed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description fully explains the value's meaning, range, and effect of higher/lower Q. It is transparent about the parameter's behavior, but does not mention any side effects (though unlikely for a getter).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the purpose, and includes tuning advice in a single paragraph. It is efficient but could be more structured for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters or output schema, the description covers the value's meaning, range, default, and tuning context. It is complete enough for an AI agent to understand the tool's function and returned data.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the description sufficiently explains the returned value (Q factor) with its range and default. It adds meaning beyond the empty schema by providing tuning context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the RPM filter Q factor (notch sharpness). The name 'get_rpm_filter_q' combined with the first sentence specifies the verb and resource, and it is distinct from the sibling 'set_rpm_filter_q'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes tuning guidance (target 1000, default 500) and conditions to adjust, but does not explicitly state when to use this getter versus alternatives. As a getter, usage is implied, but explicit context would improve clarity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the value is meaningful only when rpm_limit is ON and requires the USE_RPM_LIMIT feature. However, it does not mention whether the operation is safe or has side effects, though it is implied to be a read. Additional details like error conditions or behavior when the feature is off would improve score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of a single line that includes the tool's purpose, prerequisite, data type, and default. Every element serves a clear function with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no input parameters and no output schema, the description provides all necessary information: what it retrieves, when it applies, the type, and default. No gaps exist for an agent to misuse the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema coverage is 100%, so baseline is 3. The description adds value by stating the return type (UINT16) and default value, which provides context beyond the schema. This compensates for the lack of parameters, so a 4 is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the maximum motor RPM when rpm_limit is ON. It specifies the feature requirement (USE_RPM_LIMIT), data type (UINT16), and default value (18000). This distinguishes it from sibling tools like get_rpm_limit (likely a boolean enable) and set_rpm_limit_value.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states the requirement for USE_RPM_LIMIT feature, guiding when this tool is applicable. It implies it should be used when the rpm_limit feature is enabled. While it does not list alternatives or exclusions, the context of many get_* tools makes its usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden for behavioral disclosure. It correctly implies a read-only operation (via 'Get') and includes the data type and default value ([INT8, default: 20]). The description is clear and does not contradict any annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence plus a bracketed technical detail. Every word serves a purpose, and it is front-loaded with the purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description covers the essential purpose and effect. It could briefly mention the range of the return value, but the INT8 type implies a common range. Overall sufficient for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline is 4. The description goes beyond by annotating the returned value's type and default (INT8, default: 20), which adds valuable context for the agent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the tpa_low_rate, defines it as 'D attenuation at minimum throttle (TPA Low)', and explains its effect ('Reduces D-term shaking during throttle chops.'). This distinguishes it from other TPA-related tools like get_tpa_rate or get_tpa_breakpoint.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is used to read the TPA low setting, but does not explicitly state when to use it versus alternatives. There is no mention of when not to use it or comparisons to sibling get_tpa_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides behavioral context: it mentions a prerequisite (USE_WING), data type (UINT16), and default value (370). This adds value beyond the schema, though it could detail side effects or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with supplementary info in parentheses, conveying all necessary information without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no params, no output schema), the description covers the purpose, units, prerequisite, type, and default, making it fully informative for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description adds meaning by clarifying the value type and default. This compensates for the lack of schema details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool retrieves propeller pitch for the advanced speed TPA physics model, including units (mm) and a prerequisite (USE_WING). It clearly distinguishes itself from other get_* tools by specifying the exact parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it notes a required feature (USE_WING), it does not explicitly guide when to use this tool versus other tpa_speed_* getters or how it fits into the broader workflow. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the data type (UINT8) and default value (OFF), adding transparency. As a read operation, no side effects need disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one explanatory sentence plus bracketed metadata. It is front-loaded with the tool name and action, with no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is complete. It explains the setting, when it is needed, and the value type/default, leaving no ambiguity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (100% coverage vacuously). The description adds semantic value by specifying the return type and default in brackets, which is beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the USB HID CDC setting, using a specific verb+resource pattern. It explains the setting's purpose (combined HID+CDC vs pure CDC) and distinguishes it from the sibling 'set_usb_hid_cdc' tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions 'Required for some OTG hosts', providing context on when the setting is relevant, but does not explicitly state when to use this getter versus alternatives like 'set_usb_hid_cdc'. The usage is implied rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully explains behavior: compensatory effect, recommended target, and required setup. For a read-only tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise 3-sentence description that efficiently conveys purpose, recommendation, and requirements. Could be structured more but is well-sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema or annotations, the description provides enough context: what it does, the meaning of the value, a recommended setting, and prerequisites. Completely covers a simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters in schema (100% coverage). The description adds value by noting the returned value type, range (0-150), and default (0), which goes beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the vbat_sag_compensation setting, explaining its function of compensating for battery voltage sag to maintain PID authority and throttle output. It distinguishes from the sibling set_vbat_sag_compensation tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides context on when to use (to check the setting), recommends a target value of 90%, and notes prerequisites like cell voltage monitoring and OSD warning configuration. No explicit alternative getter exists, so guidance is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It clearly describes that the operation retrieves a low-pass filter value, reducing yaw noise. It does not mention side effects or permissions, but as a 'get' operation, it is implicitly read-only and safe. The description adds value by explaining the filter's role and range.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining function, one usage tip, and a compact range/default notation. Every sentence adds value with no redundancy. It is front-loaded with the key purpose and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description fully explains what the value represents, its effect, range, and default. It is complete for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100% (trivially). The description adds meaning by explaining the parameter's role, range [0-500], default 100, and unit (Hz implicit in range). This compensates for the lack of param info in schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the yaw_lowpass_hz value, which is a low-pass filter applied to the final yaw PID output. The verb 'Get' and the resource are unambiguous, and the context distinguishes it from other getter tools by specifying the exact parameter and its role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly guide when to use this getter versus alternatives. It includes a usage tip for the setter ('Set to 0 to disable...'), but for the getter itself, no situational guidance is provided. The purpose is clear from the name, but no sibling differentiation or context for selection is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the actual D is boosted toward d_max_pitch on fast moves, revealing behavioral dynamics beyond a simple parameter set.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four concise sentences, front-loaded with purpose, and includes a data type hint. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter set tool, the description provides essential behavioral context and references related parameter (d_max_pitch). It lacks prerequisites or side effects but is largely complete for a simple PID adjustment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds rich context: the value is a UINT8 with default 34, and explains its effect during smooth and fast flight, which is far beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the base D gain for pitch, active in smooth flight and boosted during fast moves. It distinguishes itself from siblings like get_d_pitch and set_d_max_pitch by specifying the axis and the boosting behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for setting base D pitch) but does not explicitly state when not to use or provide alternatives. Usage is inferred from purpose, lacking explicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description is the sole source. It adds the default value and tuning effect, but does not disclose side effects, immediate application, or failure modes beyond schema range checks. Adequate for a simple parameter setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences plus a format hint. It front-loads the purpose and immediately provides actionable defaults and benefits, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description fully explains what the tool does, the effect of the parameter, and offers a default recommendation. No additional context is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents type, range, and description. The description adds value by stating the default (600) and explaining the rationale for narrowing (improved resolution), which helps the agent understand when to deviate from the default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'dyn_notch_max_hz', defines it as 'Maximum frequency any notch will track', and contrasts with min_hz siblings by specifying 'max'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides default advice ('Default 600 is fine for most builds') and tuning benefit ('Narrowing the range improves notch resolution'), guiding when to reduce the value, but lacks explicit exclusions or comparison to alternatives like set_dyn_notch_min_hz.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds the default value of UBLOX in brackets, which is not in the schema. However, it does not disclose any other behavioral traits (e.g., whether the change persists, requires reboot, or affects other settings). No annotations are provided to fill this gap, but the tool is simple enough that the omission is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using one sentence plus a recommendation and a default note in brackets. It is well front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is fully complete. It tells the agent what the tool does, what values to use, and the default. No output schema is needed, and the parameter semantics are fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema describes the 'value' parameter as 'Value for gps_provider (UINT8)', but the description adds crucial semantics: it specifies the allowable values (UBLOX and NMEA) and the default (UBLOX). This significantly enhances understanding beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the GPS provider protocol (gps_provider). It identifies the resource (gps_provider) and the action (set), and it distinguishes from sibling tools like set_gps_auto_baud by specifying the exact parameter being set.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends using UBLOX for UBlox modules, calling it 'significantly more reliable than NMEA'. This gives clear guidance on value selection, but does not specify when not to use the tool or mention alternative approaches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that setting this parameter affects rescue abort behavior, details the abort conditions, and states the default value. This is sufficient for a setter tool without hidden side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence followed by a list of conditions and a type/default note. It is concise and front-loaded with key info, though could be slightly better structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter setter, the description covers the tool's effect, recommended value, and abort conditions. It does not explain return values or prerequisites, but given the simplicity, it is fairly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing baseline of 3. The description adds value by recommending a specific value (RESCUE_SANITY_ON) and noting the default (RESCUE_SANITY_FS_ONLY), aiding the agent in selecting the correct parameter value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The tool name and description clearly indicate it sets the gps_rescue_sanity_checks parameter. The description explains the purpose: it controls aborting rescue under specific conditions. It distinguishes from sibling tools like get_gps_rescue_sanity_checks and other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly recommends RESCUE_SANITY_ON and lists conditions that cause abort, giving clear guidance on when to use the tool. However, it does not provide explicit exclusions or compare to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description discloses the effect (sets the relax type signal) but does not elaborate on side effects, permissions, or warnings. Adequate for a simple setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, efficient and front-loaded with the purpose. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given one parameter, no output schema, and simple functionality, the description fully covers what the tool does and the value choices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond the schema by explaining the two allowed values (SETPOINT and GYRO) and their functional difference, plus the default. Schema coverage is 100% but description enriches understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Set' and resource 'iterm_relax_type', explains the two modes (SETPOINT vs GYRO), and distinguishes from the many sibling set/get tools by specifying exactly what it configures.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Indicates that SETPOINT is the default and works well for most cases, implying when to use it, but does not explicitly state when not to use GYRO or provide alternatives beyond the sibling get_iterm_relax_type.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses that this is a write operation, explains the effect of the parameter, mentions the data type (UINT8) and default value (30). This is good transparency for a simple setter, though it does not cover potential side effects or persistence.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences and a bracketed note, front-loaded with the purpose, followed by effect and type/default. Every sentence earns its place, no waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description covers the essential aspects: purpose, effect, type, and default. It does not discuss persistence or save requirements, but these are not critical for a basic set operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds significant value by explaining the meaning of the parameter ('higher = smoother but more lag'), specifying the actual constraint as UINT8 (correcting the misleading schema bounds), and stating the default value. This is crucial for correct tool invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it sets 'rc_smoothing_auto_factor' and explains what that parameter is ('Auto-smoothing aggressiveness for setpoint channels'). It also distinguishes from siblings by referencing 'setpoint channels' and noting the effect of higher values, which is not present in other set_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description hints at usage with 'Higher = smoother but more lag' and 'Preset applies the correct value for your RC link', but does not explicitly state when to use this tool versus alternatives like set_rc_smoothing or get_rc_smoothing. No when-not-to-use or comparison with siblings is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses parameter range (0-3), type (UINT8), default (3), and value semantics. However, does not mention if the change takes effect immediately or requires a reboot/rearm, which would be useful. No annotations provided, so description carries full burden; overall good but not complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with purpose, followed by concise value explanation. No filler, front-loaded with key information. Every word contributes meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter and no output schema, description covers parameter semantics and range. Lacks mention of immediate effect or reboot requirement, but overall adequate for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (baseline 3), but description adds significant meaning beyond schema: explains that 3 covers fundamental+2nd+3rd harmonics, 0 disables filtering, and provides type/range/default. This helps an agent interpret the integer value correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states verb 'Set' and resource 'rpm_filter_harmonics', explains the parameter meaning (number of harmonics to filter per motor), and distinguishes from its get_ sibling. Gives specific value semantics (3 = fundamental+2nd+3rd, 0 disables).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through the parameter description but does not explicitly state when to use this tool versus other filter-related tools (e.g., set_rpm_filter_lpf_hz) or provide context like 'use this to configure harmonic notch filters'. No alternative tool names or conditions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the two curve shapes and mentions a default value, but does not describe side effects, error conditions, or what happens if the prerequisite is not met. The discrepancy between the description mentioning 'UINT8' and the schema defining the parameter as a string is not explained.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: one sentence for purpose, a brief list of values, a prerequisite note, and a default indication. Every sentence adds value; no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one parameter and no output schema, the description covers all key aspects: purpose, valid values, prerequisite, and default. No significant gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning beyond the schema's generic 'Value for tpa_curve_type (UINT8)' by explicitly listing the two valid values (CLASSIC, HYPERBOLIC) and explaining their behavioral impact. This compensates for the schema's lack of enum specification.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set tpa_curve_type: TPA curve shape.' It uses a specific verb ('Set') and resource ('tpa_curve_type'). The two possible values (CLASSIC, HYPERBOLIC) and their meanings are explained, distinguishing this tool from many similar 'set_tpa_*' sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description notes the prerequisite '_(Requires: `USE_ADVANCED_TPA`)_', providing a clear condition for when this tool can be used. However, it does not explicitly state when not to use it or suggest alternatives among the many sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description discloses the behavioral effect (attenuating specific terms) and lists all possible values and default. Lacks mention of side effects or safety implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences with front-loaded verb and resource, followed by a clear bullet-like list of options. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple single-parameter tool, description is nearly complete. Could mention that tpa_mode affects PID behavior or safety considerations, but not strictly necessary among siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but schema description is minimal ('Value for tpa_mode (UINT8)'). Description adds significant meaning by mapping enum values to actual term attenuation and specifying default, which the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'Set' and resource 'tpa_mode', defines what tpa_mode does (which terms TPA attenuates), and distinguishes from siblings like set_tpa_rate by naming specific values D, PD, PDS.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives; usage is implied by the context of configuring TPA mode, but no guidance compared to other set_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the automatic 'simplified_tuning apply' after simplified_* commands. However, it does not mention that arbitrary CLI commands can modify system state, which would improve transparency for a general exec tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first sentence states the core purpose, second sentence provides crucial usage guidance. No wasted words, well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, usage guidelines, and a key behavioral quirk. It does not document return format or error handling, but those are implicit for CLI output. Slightly above adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (command param described with example). The description adds little beyond the schema; it mostly restates the purpose. The note about simplified_* commands is the only additional semantic, but it's not about the parameter itself. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Execute an arbitrary CLI command on the flight controller and return the output,' specifying a verb and resource. It distinguishes itself from siblings like cli_dump or cli_help by being the general-purpose execution tool, and the note about set_pid_sliders further clarifies its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'prefer the set_pid_sliders tool' for simplified_* commands, and explains the automatic behavior if used anyway. This tells the agent when to use this tool versus an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses irreversibility and duration (up to 30 seconds). Since no annotations are provided, the description carries the full burden and provides key behavioral traits beyond the tool's name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with front-loaded purpose and critical behavioral notes. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, destructive tool, the description covers purpose, irreversibility, timing, and ordering. Minor improvement could add confirmation or undo information, but it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is 100%. The description need not add parameter details; baseline 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'erase', the resource 'blackbox logs', and the location 'onboard flash memory'. It uniquely identifies the tool's action among many sibling tools that are get/set operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Includes a specific usage note: 'call this before any CLI tools in the same session', which provides actionable context. Does not explicitly state when not to use, but the note is clear and directional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses data type (INT16), range (-180–360), and default (0), giving the agent a clear understanding of the expected value. No side effects are mentioned, but as a read operation, this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single line containing all essential information: purpose, data type, range, default, and usage context. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and no parameters, the description adequately covers the tool's behavior. It provides the return type and range, which is sufficient for an agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the description does not need to add parameter information. The baseline is 4 for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Board rotation offset in roll (degrees)' and 'For non-standard FC mounting orientations.' This defines the specific parameter and distinguishes it from siblings like get_align_board_pitch and get_align_board_yaw.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'For non-standard FC mounting orientations,' which implies when to use the tool. However, it does not explicitly state when not to use it or mention alternatives, though the context of sibling tools provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description fully carries the burden. It discloses the value range, units (UINT8, 0–100), default (100), and the behavior (returns the current proportion). This covers the essential behavioral traits for a simple read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with additional details in brackets. It is front-loaded with the purpose and provides all necessary information without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and no output schema, the description is quite complete. It covers the purpose, range, default, and a usage recommendation. It could be slightly more explicit about the return value format, but it is implied.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so the baseline is 4. The description does not need to add parameter semantics, as there are none. It correctly describes the return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the proportion of earth-frame reference used in angle mode. It defines the range (0-100) and explains the meaning of the endpoints (0=body frame, 100=full earth frame). This is specific and distinguishes it from other get tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a recommendation ('100 is recommended for GPS rescue compatibility'), which guides the user on choosing the appropriate value contextually. However, it does not explicitly state when to use this get tool versus other tools (e.g., set_angle_earth_ref), though that is implicitly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It explains that the tool gets a setting that excludes servo data from logs, and notes it is a UINT32 with default OFF. This goes beyond the name but could mention that it is read-only and non-destructive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence with a prerequisite note and a type/default note. Every element is necessary and front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently explains what the tool returns (the state of servo exclusion). It could elaborate on the exact meaning of the UINT32 value, but for a simple getter it is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so the description adds value by describing the setting itself (UINT32, default OFF). Since schema coverage is 100% (no params), baseline is 4, and the description meets that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the setting to exclude servo output data from logs. The verb 'get' matches the resource 'blackbox_disable_servos', and it is distinct from siblings like 'get_blackbox_disable_acc' by specifying 'servo output data'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the prerequisite 'Requires: USE_SERVOS', which guides when the tool is applicable. However, it does not explicitly state when to use this tool versus alternatives like 'set_blackbox_disable_servos' or other 'get_blackbox_disable_*' tools, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly explains the parameter's effect on D gain rise behavior and includes its type, range, and default in brackets. It does not mention side effects or permissions, but for a read-only tool this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus a compact bracket notation. Front-loaded with purpose, no unnecessary words. Every sentence provides essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description covers what the parameter does, when to modify it, and its constraints. It could mention if the value is live or cached, but overall is complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero input parameters, so schema coverage is 100%. The description adds value by explaining the meaning and range of the output value (UINT8, 0–100, default 37), which is more than the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the d_max_gain parameter and explains its function: 'Controls how aggressively D rises from base D toward d_max on sharp moves.' It distinguishes itself from sibling tools like get_d_max_pitch or get_d_max_roll by focusing on this specific D gain behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides practical guidance: 'Default is suitable; reduce if D boost causes propwash on move initiation.' This tells when to adjust the value, though it does not explicitly compare to alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the possible values (BIQUAD, PT1) and their implications (sharper roll-off vs less phase), as well as the default and data type. However, it does not explicitly state that this is a read-only operation, though the 'get' prefix implies it.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise—a single sentence plus a brief explanation of the two options and the default. It is front-loaded with the purpose and wastes no words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters or output schema, the description provides enough context: it explains the two options and their behavior. It could be improved by specifying the exact return format (e.g., string vs integer), but it is largely complete for a simple getter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The baseline for 0 parameters is 4. The description does not need to add parameter information, and it does not provide any misleading or unnecessary details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (Get), resource (dterm_lpf1_type), and provides context about what the type represents ('Type for D-term LPF1') and the two possible values (BIQUAD, PT1) with their trade-offs. This distinguishes it from sibling tools like get_dterm_lpf2_type or get_gyro_lpf1_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by explaining what the tool retrieves, but it does not explicitly state when to use this versus other similar get tools or provide alternative guidance. However, the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description adds value by explaining the meaning of the returned number (independently tracked dynamic notches), its default (3), and the effect of different values. It implies this is a read-only retrieval with no side effects, which is appropriate for a getter. However, it does not explicitly state behavioral traits like idempotency or network dependency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using two sentences and a numbered bullet list. Every sentence adds value: it defines the parameter, explains the default, and gives tuning guidance. No fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is fully complete. It covers what the tool returns, its default, and provides tuning context. No missing information for an agent to understand and use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds significant meaning by explaining the return value's semantics, default, and recommended values. This goes well beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get dyn_notch_count: Number of independently tracked dynamic notches.' The verb 'Get' and resource 'dyn_notch_count' are explicitly identified, and the purpose is unambiguous. It distinguishes from the sibling setter tool 'set_dyn_notch_count' by being a getter operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides excellent guidance on interpreting the returned value (recommending counts based on RPM filtering), but it does not explicitly state when to call this tool versus alternatives (e.g., other get_dyn_notch_* tools or the setter). The usage context for the tool itself is implied but not explicitly spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description makes it clear the tool is a read operation ('Get'). It discloses data type (UINT8), range (0-50), default (15), and effect on gyro response. This sufficiently conveys the behavioral traits without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at three sentences, front-loaded with the tool name and purpose. The tuning guidance is appended efficiently. Some minor run-on structure, but overall appropriate for a simple getter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description fully explains the parameter's meaning, range, and tuning context. It implicitly distinguishes from the set tool and other get_* tools by explaining the specific role of feedforward boost.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the baseline is 4. The description goes beyond by adding the data type, valid range, default value, and tuning semantics, which are not present in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves feedforward_boost, explains it as an acceleration component (second derivative of stick), and provides specific tuning guidance (increase if gyro lags, decrease if overshoots). This distinguishes it from other get_* tools which are generic parameter retrievals.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit conditions for increasing or decreasing the value based on gyro behavior (lag vs overshoot). However, it does not explicitly guide when to use this get tool versus its set counterpart (set_feedforward_boost) or other related get tools, though the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It declares it's a read operation ('Get'), and provides value range and default. Though it doesn't mention side effects or prerequisites, for a simple getter with no parameters, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: two sentences plus bracketed type/range. Every word adds value. No redundancy. Front-loaded with key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description covers purpose, usage context, and value constraints. Could briefly explain what 'RC mid-point' means, but it's adequate for the target audience.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so there are no parameters to describe. Schema coverage is 100% vacuously. Baseline for 0 params is 4; description adds value by providing range and default information that would otherwise be missing.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get mid_rc: RC mid-point' which is a specific verb+resource. It distinguishes from sibling set_mid_rc by indicating this is a getter. The Futaba example further clarifies its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides usage context: 'Match to your transmitter's stick center value' and a specific example for Futaba radios. While it doesn't explicitly exclude other uses, the context is clear. Existence of sibling set_mid_rc implies when to use this vs the setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It implies a read operation and specifies the value range and default, but does not explicitly state that the tool is non-destructive or has no side effects, which is a minor gap for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a format note, with no wasted words. It front-loads the purpose and then provides additional context and constraints efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description sufficiently explains the return value (motor KV rating) and its usage context. It also provides the value domain, making the tool fully understandable for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the description still adds value by documenting the type (UINT16), range (1-40000), and default (1960), which goes beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the motor KV rating. It uses a specific verb ('Get') and resource ('motor_kv'), distinguishing it from sibling tools like 'set_motor_kv' and other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains the tool is used for internal calculations and to enable accurate RPM limit and dynamic idle features, but does not explicitly state when not to use it or compare with alternatives beyond the setter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses data type (UINT16), valid range (200-32000), and default value (480), giving the agent clear expectations. No annotations provided, so description carries full burden; it handles it well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first identifies the value, second adds relevance and constraints. No wasted words, front-loaded with the key purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the meaning, range, default, and applicability (brushed motor mode only). Could mention recommended usage scenarios, but for a simple getter this is adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 0 parameters with 100% schema description coverage. Description adds no parameter info, but none is needed. Baseline 4 is appropriate as it adds value about the returned value's constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it gets the PWM frequency for brushed motor mode, explicitly noting irrelevance for DSHOT protocols, distinguishing it from related siblings like get_motor_pwm_protocol.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Not relevant for DSHOT protocols' provides a clear exclusion criteria. However, it does not explicitly state when to use this tool or name alternative tools, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations; the description indicates a read-only get operation. It discloses default value and unit. No side effects mentioned, but none expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise: one sentence with additional details in parentheses. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description explains purpose, default, and requirement. Could mention it's part of TPA curve family, but still complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters; baseline 4. Description adds meaning via default and unit context, beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it gets the PID value at full throttle for the TPA curve, with a specific default. It distinguishes from sibling tools like get_tpa_curve_pid_thr0.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions the requirement USE_ADVANCED_TPA. It could explicitly state when not to use, but the context implies it's a simple getter. No exclusions needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the two modes (BASIC from GPS, ADVANCED from motor/prop model) and the default value, adding behavioral context beyond the empty schema. However, it does not explicitly state that the tool is read-only or detail return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—just two sentences plus a parenthetical—yet covers purpose, mode comparison, prerequisites, and default value. Every word adds value, and the structure is front-loaded with the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter of a single value, the description is largely complete. However, the absence of an output schema means the return value structure is not specified, which might require the agent to infer the expected response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, achieving 100% schema coverage. Per guidelines, baseline is 4 for no parameters. No additional parameter info is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get tpa_speed_type' with an explanation of two possible values (BASIC vs ADVANCED), making the purpose unambiguous. It distinguishes from sibling getter tools by focusing specifically on the speed type parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the prerequisite 'USE_WING' feature, which helps agents know when this tool is applicable. It does not contrast with alternatives, but the context implies it's for reading the current setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. It explains the parameter's behavior (duration for warning alarm) and format (UINT8, 0–150, default: 0), and adds context that it prevents brief-spike false alarms. For a read-only getter, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise: a single sentence covering purpose and behavior, followed by inline format specification. No wasted words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no output schema, the description fully covers the return value meaning, constraints, and purpose. No gaps remain—an agent can correctly interpret and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has no parameters (0). Baseline is 4. The description adds full meaning for the return value: explains what the value represents and its constraints (UINT8, range, default). This is excellent for a param-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description explicitly states the tool retrieves a setting: 'Consecutive tenths-of-seconds the voltage must remain below the warning threshold before the warning alarm fires.' The verb 'Get' and resource 'vbat_duration_for_warning' are clear, and it is distinct from siblings like get_vbat_duration_for_critical.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool vs alternatives. While it's a simple getter, the description lacks 'when to use' or 'when not to use' advice. Useful context is provided about preventing false alarms, but no differentiation from other voltage-related getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description reveals that the tool writes raw calibration offsets and cautions against manual editing, disclosing potential risks. It does not detail side effects or required permissions, but the warning adds meaningful transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, compact sentence with a format hint, containing zero wasted words. It efficiently conveys purpose, behavioral warning, and parameter details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description covers purpose, parameter semantics, and a behavioral warning. It could mention return values or more context about the calibration routine, but it is largely sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides 100% coverage with a basic description, but the description adds significant meaning: the parameter represents raw accelerometer calibration offsets, is INT16 (implying an array of four), and defaults to '0,0,0,0'. This exceeds the baseline and clarifies usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets acc_calibration (raw accelerometer calibration offsets) and distinguishes it from siblings like calibrate_accelerometer and get_acc_calibration by specifying it is written by the calibration routine and should not be edited manually.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly warns not to edit manually, guiding the agent away from direct use and implying that the calibration routine should be used instead. However, it does not explicitly name alternative tools or specify when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It explains the behavioral effect (aggressiveness of D rise), the data type (UINT8), valid range (0–100), and default value (37). This provides good transparency, though it omits whether changes take effect immediately or require reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a compact bracket notation for type/range/default. It is front-loaded with the core function and wastes no words. Every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema) and the presence of type/range/default/tuning advice, the description covers the essential aspects. A minor gap is the lack of information about effect timing (immediate vs. restart), but it is still fairly complete for its complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'value' has 100% schema coverage with a basic description. The tool description adds a default value (37) and tuning advice ('reduce if propwash'), which enriches the schema and helps the agent choose appropriate values. This goes beyond the schema's static range declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool 'Controls how aggressively D rises from base D toward d_max on sharp moves.' It uses a specific verb-resource combination and distinguishes itself from numerous sibling set_* tools by explaining its precise role in D boost behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is given: 'Default is suitable; reduce if D boost causes propwash on move initiation.' This tells the agent when to adjust the parameter and in which direction. No alternatives are mentioned, but the advice is practical and context-aware.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It describes the effect (setting offset in mA), the valid range (0–16000), and default value (0). It does not mention persistence or side effects, but for a parameter setting tool, this is adequate and consistent with sibling set_* tools.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, at two sentences plus a requirement and range notation. It front-loads the action and packs essential information (what, why, prerequisite, range, default) without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that this is a simple single-parameter setter with no output schema, the description covers the tool's purpose, parameter semantics, and a prerequisite. It does not address immediate effects or return value, but that is typical for such tools and the description is complete enough for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the schema documents the parameter type and range. The description adds value by explaining the parameter's purpose ('current offset applied to ESC sensor current reading'), its unit (mA), and its usage for zero-calibration, going beyond the schema's minimal description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the verb 'set' and the resource 'esc_sensor_current_offset'. It explains the tool's function: applying a current offset for zero-calibrating ESC current reporting. This distinguishes it from get_esc_sensor_current_offset and other set_* tools by specifying the exact resource and purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: 'Use to zero-calibrate ESC current reporting.' It also specifies a prerequisite (requires USE_ESC_SENSOR). However, it does not explicitly state when not to use or mention alternative tools, but the given guidance is sufficient for this simple setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the effect (reducing phase delay) and a specific scenario (aliasing condition). It does not detail side effects like increased noise, but for a simple setter this is acceptable. The default value is stated, adding transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences contain all necessary information. Every clause serves a purpose—identifying the parameter, its effect, a tuning hint, and a special condition. No redundant or extraneous text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema, no nested objects), the description is complete. It defines the parameter, explains its effect, provides tuning guidance, and notes a specific use case. No additional context is needed for an agent to understand when and how to use this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the schema only describes the parameter as an integer with bounds. The description adds critical semantics: the purpose (cutoff frequency), how to tune (raise toward 1000 Hz for less phase delay), a special case (set to 0 when gyro rate equals PID rate), and the default value (500). This significantly enhances understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Set gyro_lpf2_static_hz: LPF2 cutoff.' This is a specific verb-resource pair that distinguishes it from sibling getters or other set tools by naming the exact parameter. The additional details about reducing phase delay and the aliasing condition further clarify its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides practical guidance: raising toward 1000 Hz reduces phase delay, and setting to 0 is appropriate when gyro rate equals PID rate to avoid aliasing. However, it does not explicitly state when NOT to use this tool or offer alternatives, such as adjusting gyro_lpf1 or dynamic filters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses the behavioral trait: ignoring stick input for leveling transition when ON, and that it depends solely on horizon_delay_ms, plus the type and default value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single front-loaded sentence with a compact bracketed note for type/default, no wasted words, highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple boolean setter, the description covers the effect and related parameter; it doesn't discuss safety implications, but that's acceptable for a low-complexity tool without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter described. The description does not add extra semantic detail about the parameter's allowed values beyond 'UINT8' and default, which is adequate but not enriching beyond baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a specific parameter (horizon_ignore_sticks) and explains its effect in horizon mode, distinguishing it from sibling set_horizon_* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when the setting impacts behavior (when ON, in horizon mode) and mentions it is governed only by horizon_delay_ms, providing context for use without explicit comparison to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the data type, range, default, and a required build flag. It does not mention persistence or side effects, but the tool is a simple setter and the details given are adequate for a basic understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with parenthetical additions; it is concise, front-loaded with the action, and every element adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description is fairly complete. It covers purpose, constraints, default, and prerequisite. Missing detail on whether the setting takes effect immediately or requires a reboot, but still adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description adds the default value (0) and the requirement (USE_VIRTUAL_CURRENT_METER), which are not in the schema. This adds meaningful context beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the scale of a virtual current sensor, distinguishing it from siblings like set_ibata_scale (actual current sensor) and set_ibatv_offset (offset).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a prerequisite (USE_VIRTUAL_CURRENT_METER) but does not explicitly exclude alternatives or give when-to-use versus siblings. The name and description imply the context for virtual sensors, which is clear enough for an agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries the full burden. It discloses that higher values reduce CPU load and degrade accuracy, and provides valid range (1-4) and default (2). It does not mention side effects like instant-apply or need for reboot, but for a simple parameter setter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise: two sentences and a format hint. It conveys purpose, behavioral effect, range, and default without any filler. Front-loads the parameter name and its role.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one parameter, the description provides all essential information: what it does, valid range, default, and trade-off. There is no output schema, but that is expected for a setter. Missing details like persistence or reboot requirement are minor for this domain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage for the only parameter ('value'). The description adds meaning beyond the schema by explaining the parameter's function as a rate divisor and its performance trade-off, which the schema's description ('Value for imu_process_denom') does not provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states tool sets the IMU attitude update rate divisor. It explains the parameter's role relative to gyro task rate, distinguishing it from the many other set_* tools in the sibling list. The verb 'Set' and specific resource 'imu_process_denom' provide unambiguous purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description explains effect of higher values (reduce CPU load at cost of attitude accuracy), giving implicit guidance on when to use (need performance vs accuracy trade-off). It does not explicitly state when not to use or mention alternative parameters, but the trade-off context is sufficient for this simple setter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the tool caps per-motor output and provides a default value. Since no annotations exist, it bears full responsibility. However, it does not mention range limits (0-100%), whether changes take effect immediately or require a reboot, or any safety notes. A score of 3 is appropriate—adequate but with gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—two sentences with a clear front-loaded purpose, an example, and type/default info. No filler text; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of this tool (one integer parameter, no output schema), the description is largely complete. It covers what the tool does, when to use it, and the parameter's purpose. It could add the valid range or mention persistence, but overall it is well above minimal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% for the single parameter, so baseline is 3. The description adds value by stating the default value (100) and implicitly indicating the unit (percentage) via context, which enhances understanding beyond the schema's basic type hint.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Caps per-motor output as a percentage.' It provides a concrete example (6S on 4S build) that distinguishes it from other set_ tools, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is given: 'Use when running higher cell count than motors are rated for (e.g. 6S on a 4S build → set to ~66%).' This tells the agent exactly when to invoke the tool, which is rare and highly useful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the FC recalculates PID gains immediately via MSP (equivalent to Configurator sliders) and that pids_mode is automatically enabled if currently disabled unless specified otherwise. These side effects are well communicated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise at 4 sentences, with each sentence adding essential information: purpose, partial update mechanism, immediate effect and persistence requirement, and automatic mode change. No redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (13 parameters, no output schema), the description covers the core behavioral aspects: what it does, how to use partial updates, immediate effect, persistence need, and automatic mode change. It could mention error handling or validation, but overall it is sufficiently complete for effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds critical behavioral context: partial updates are supported (only changed sliders need be provided) and automatic pids_mode behavior. This adds value beyond the schema descriptions of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set Betaflight simplified filter and tuning slider values.' It specifies that it modifies slider values and that only provided sliders are changed. This distinguishes it from sibling tools that set individual parameters or perform other actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage guidance: 'Provide only the sliders you want to change; all others keep their current values.' It also advises to call cli_save afterwards to persist. However, it does not explicitly contrast with alternative tools like set_simplified_* or explain when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses type (UINT8) and default value (100), adding value beyond the schema, but does not mention side effects, persistence, or whether changes take effect immediately; adequate for a simple setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with bracketed type/default, front-loading purpose and critical info with zero filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple parameter setter; covers purpose, type, and default, but could benefit from brief context on how this fits into PID tuning or that it modifies flight controller settings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the parameter; tool description adds the default value, providing additional context beyond the schema, justifying a score above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool sets the simplified I gain, describes it as an 'I scaling slider' and explicitly notes it is 'independent of P,' distinguishing it from related siblings like set_simplified_pi_gain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies usage through 'independent of P,' suggesting this tool adjusts I gain without affecting P, but lacks explicit when-to-use or alternative guidance compared to siblings like set_simplified_pi_gain.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It explains the parameter's role as a pre-arm safety lock and explicitly includes range [UINT8, 0–180, default: 25], which provides behavioral bounds. It does not mention side effects or permissions, but the context is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with no wasted words. It front-loads the purpose, then adds a key use case, and ends with the type/range/default. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter setter, the description covers purpose, range, default, and a critical use case. It does not discuss return values or error scenarios, but given the tool's simplicity, it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of the single parameter. The description adds meaningful context beyond the schema: it explains that the parameter controls the arming tilt angle and specifies the default value (25), which aids understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'small_angle', explaining it as a maximum tilt angle for arming—a pre-arm safety lock. This distinguishes it from sibling 'set_' tools by specifying its role in arming safety.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance for using the value 180 with turtle/crash-flip mode, implying default usage for normal flight. It lacks explicit when-not-to-use or alternatives, but the use case is clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It explains the behavioral effect ('prevents rapid gain changes') and provides the default value. It does not discuss persistence or error conditions, but for a simple parameter setter, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one explanatory sentence, followed by the requirement in parentheses and the type/default in brackets. Every part serves a purpose, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single required parameter, no output schema), the description provides the necessary context: purpose, unit, default, and prerequisite. It could add details about the effect of extreme values, but it is sufficient for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already covers the parameter type and range (100% coverage). The description adds semantic meaning: the unit (ms), the context (delay after speed change), and the default value. This goes beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets a delay (in milliseconds) for speed-based TPA updates after a speed change, and explains the purpose: preventing rapid gain changes during maneuvers. This is specific and distinguishes it from sibling tools like set_tpa_speed_basic_gravity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a prerequisite ('Requires: USE_WING'), which helps agents know when this parameter is applicable. It does not explicitly mention alternatives or when not to use, but the tool name and context among many parameter setters make usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool sets a gravity factor affecting the TPA response curve, specifies the data type (UINT16) and default value (50), and notes the required feature (USE_WING). It does not cover side effects or reversibility, but for a single-parameter setter, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that effectively combines the verb ('Set'), the resource, the purpose, the effect, the requirement, and the parameter metadata. It is front-loaded with the key information and contains no superfluous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description covers the essential aspects: what it does, its effect, prerequisites, and parameter details. It does not explain the broader TPA system, but that is acceptable given the tool's focused role.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, but the schema only generically describes the parameter as 'Value for tpa_speed_basic_gravity (UINT16)'. The description adds meaningful context: it is a gravity factor, affects response curve vs airspeed, and has a default of 50. This goes beyond the schema, raising the score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a gravity factor for BASIC speed TPA and explains its effect on the TPA response curve vs airspeed. The term 'BASIC' distinguishes it from siblings like 'set_tpa_speed_adv_drag_k', making the purpose specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes that USE_WING is required, which guides the agent on a necessary precondition. While it does not explicitly contrast with alternatives, the specification 'BASIC speed TPA' implies usage when basic TPA mode is desired, which is clear given the sibling tools with 'ADV' prefixes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given no annotations, the description provides key behavioral details: it returns a factory calibration value (read-only), with data type UINT16, range 0–2000, and default 0. This is transparent for a simple getter, though it does not explicitly state side-effect-free or read-only nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus a compact bracket specification. It is front-loaded with the action and resource, and every element (type, range, default) earns its place with zero waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters and no output schema, the description fully compensates by specifying the return data type, range, and default. It mentions factory calibration, providing complete context for a simple read operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The description adds value by describing the return value's type and constraints, further aiding understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the ADC temperature sensor calibration value at 30°C, a specific factory calibration. It distinguishes itself from sibling get_adc_tempsensor_calibration110 by specifying the temperature, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The temperature specification in the name and description implicitly tells the agent when to use this tool (for 30°C calibration) versus the 110°C variant. However, it lacks explicit 'when not to use' instructions or alternatives, but the sibling differentiation is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the return type (list) and condition (empty = ready), and advises on session ordering. It could add that the tool is read-only and idempotent, but the current description is largely transparent for a simple getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences: function, return interpretation, and usage note. Every sentence adds value, no wasted words. Well-structured and front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter tool, the description covers the purpose and return interpretation. The note about CLI tools adds practical context. It could optionally describe the format of the flags (e.g., human-readable strings), but the current description is sufficient for an AI agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. The description does not need to add parameter semantics. This is a perfect score for no-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves arming-disable flags and explains what the return value means (empty list = ready). It uses a specific verb+resource pattern and distinguishes itself from many sibling get_* tools by focusing on arming status.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The note 'call this before any CLI tools in the same session' provides clear guidance on when to use this tool relative to other operations. However, it does not explicitly mention when not to use it or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It uses 'Get' implying a read-only operation, and provides the value range and default (UINT8, 0–5, default 0). This is sufficient transparency for a simple getter tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single sentence plus a prerequisite note and type/range info. It is front-loaded with the purpose, and every part adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description fully explains the return value (I2C bus number), its type (UINT8), range (0–5), and default (0). It also includes a prerequisite. This is complete for a simple configuration getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters (schema is empty). Schema coverage is trivially 100%. The description does not need to explain parameters, and the baseline score of 4 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and the resource 'baro_i2c_device' (I2C bus number for barometer). It distinguishes from sibling tools like get_baro_bustype, get_baro_hardware, and get_baro_i2c_address by explicitly mentioning 'I2C bus number'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description mentions a prerequisite (USE_BARO) which provides context for usage. It does not explicitly state when not to use or provide alternatives, but given the specificity of the tool, the usage is clear and distinct from siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It includes the parameter's data type, range, units, and default, which informs the agent about the expected return value. However, it does not disclose potential side effects (none expected) or specific conditions like needing a connection to the flight controller.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that includes all necessary information without redundancy. It is efficiently front-loaded with the parameter name and purpose, followed by concise technical details in brackets.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the zero-parameter input and no output schema, the description provides sufficient contextual completeness. It fully explains what the tool does and the nature of the returned value. The agent can confidently use this tool to read the crash limit yaw parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so schema coverage is trivially 100%. The description adds semantic meaning beyond the schema by specifying units (deg/s), allowed range (0–1000), and default value (200), which helps the agent interpret the returned value correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the 'crash_limit_yaw' parameter, specifying its purpose (yaw rate limit during crash recovery), units (deg/s), data type (UINT16), range (0–1000), and default value (200 per profile). It distinguishes from sibling tools like 'set_crash_limit_yaw' and other get_crash* tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context by naming the parameter and its role in crash recovery. While it does not explicitly state when to use or alternatives, the purpose is straightforward for a getter, and the sibling setter is implicitly the alternative for writing. Lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It clearly indicates this is a read operation to retrieve a parameter value, with no mention of side effects. The type, range, and default are specified in brackets, and it warns about a conflict with another parameter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with no wasted words. It front-loads the main purpose, then adds a warning, and ends with the type/range/default annotation. All sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple getter with no parameters and no output schema. The description fully covers the purpose, behavior, relevant warnings, and value range. It is complete for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters (0 params), so the baseline is 4. The description does not need to add parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool retrieves the feedforward_transition parameter which blends feedforward toward zero near stick center, and provides example values for different use cases. It distinguishes itself from sibling get_* tools by specifying its unique purpose and warns about interaction with feedforward_jitter_factor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes a crucial usage guideline: the parameter must be set to 0 when feedforward_jitter_factor is active. It does not compare usage with the many other get_* tools, but it provides context that helps decide when to use this tool over related set_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description adds value by disclosing the return type (UINT16), default value (800), and required feature. This is sufficient for a simple getter with no side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise single sentence with key details (type, default, requirement). No extraneous information, all sentences earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description covers purpose, return type, default, and prerequisite. No output schema needed. Complete and self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds context about the returned value's type and default, which is helpful despite the schema having 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets the I2C bus 1 clock speed in kHz, specifying the exact resource and distinguishing it from siblings like get_i2c2_clockspeed_khz. The requirement note adds specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Describes when to use via the required feature flag (USE_I2C_DEVICE_1). Contextually clear but does not explicitly mention when not to use or list alternatives beyond the naming pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description explains the value meanings and the dependency on USE_WING. It also provides the default value and type. This adds meaningful behavioral context for a read-only getter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the core purpose. Each part (purpose, value explanations, prerequisite, type/default) earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameterless getter, the description fully covers the tool's purpose, meaning of return values, and a prerequisite. No missing information that would hinder correct use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so schema coverage is 100%. The description adds value by explaining the possible mode values and their meanings, which is helpful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get spa_roll_mode: SPA mode for roll', explaining the purpose and the meaning of each possible value (I, PID, PDI_FREEZE). It distinguishes this tool from sibling tools like set_spa_roll_mode and other getters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description specifies a prerequisite ('Requires: USE_WING'), giving clear guidance on when this tool is applicable. However, it does not explicitly mention when not to use it or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full transparency burden. It adds value by specifying the data type (UINT8), range (0-100), and default (50), which are not evident from the tool name alone. However, it does not mention return format or side effects, but as a read-only getter, this is sufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two clear sentences plus a bracketed type/range summary. It front-loads the essential information without any fluff. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description is complete. It explains what the returned value represents, its range, default, and usage context. No further information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema is fully covered (empty). The description adds meaning by specifying the output range and default, which is extra context beyond the schema. Baseline for zero-parameter tools is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the estimated hover throttle percentage, which is a specific resource. It explains its use in alt-hold and internal calculations, distinguishing it from other getters. No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The context indicates this tool is used for reading a configuration value, but it does not explicitly compare with alternatives like set_thr_hover or specify when not to use it. For a simple getter with no parameters, the guidance is adequate though not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the tool sets a rotation offset, includes the data type, range, and default value. While it does not mention persistence or side effects on attitude calculations, the tool is a simple parameter setter, and the exposed information is sufficient for understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: one sentence explaining the purpose, followed by a compact bracket notation for type, range, and default. Every part is essential, with no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema, no nested objects) and the good schema coverage, the description is complete. It covers what the tool sets, its purpose, acceptable values, and default, leaving no obvious gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the single parameter. The description adds the default value (45) and explicitly mentions degrees, which are not in the schema. This extra context enhances understanding beyond the schema alone, warranting a score above the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and the resource 'align_board_yaw', explaining it as 'Board rotation offset in yaw (degrees)' and specifying the use case 'for non-standard FC mounting orientations.' This effectively distinguishes it from sibling tools like set_align_board_pitch and set_align_board_roll.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description indicates when to use the tool ('For non-standard FC mounting orientations'), providing clear context. It does not explicitly state when not to use it or offer alternatives, but the intended scenario is well-defined, and the sibling tools cover similar cases for other axes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the data type (INT8), valid range (0-100), and default value (100). It explains the behavior of extremes, which is sufficient for a simple setter. It does not cover persistence or side effects, but such detail is not critical here.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is extremely concise with two sentences, front-loading the key information (name, purpose, range, default). Every word is useful with no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter with one integer parameter and no output schema, the description is complete. It covers what the tool does, valid values, default, and meaning of extremes. All essential information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single 'value' parameter described. The description adds semantic value by explaining the meaning of the range endpoints and the default, which goes beyond the schema's basic type and range constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets a weight parameter between barometer and GPS altitude, with explicit range and default. It uses the verb 'Set' and specifies the resource 'altitude_prefer_baro', distinguishing it from the getter sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage by defining the range meaning (0=GPS only, 100=baro only) and default. While it doesn't explicitly say 'use this tool when...', the context is clear for a simple parameter setting, and no alternative setter tool exists for this parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the setting 'can cause premature D oscillation' and is 'rarely beneficial.' It explains the mechanism ('uses feedforward signal'). This is adequate for a simple parameter, though more detail on consequences could be added.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences plus a technical bracket, all adding value: purpose, tuning advice, exploration advice, and spec. No wasted words, well-structured, and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description covers purpose, usage, risks, and default thoroughly. It is complete for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (parameter description in schema). The tool description adds meaning beyond the schema: it explains the feedforward signal timing and provides the default value (20). This adds significant context for parameter selection.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Allows D boost to start before the gyro rate peaks, using feedforward signal.' It uses specific verb+resource and distinguishes this parameter from other D-related settings like set_d_max_gain or set_d_max_pitch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage guidance: 'Set to 0 during baseline tuning' and 'Only explore once the baseline is stable.' It warns that it's 'rarely beneficial and can cause premature D oscillation.' No alternative tool is named, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds transparency by stating the default value (0), that 0 disables the notch, and the data type (UINT16). It does not mention side effects or persistence, but for a simple static setting this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise: three sentences packed with essential information. No redundant words, every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (one parameter, no output schema), the description is complete: it covers purpose, parameter semantics, default, and usage context relative to dynamic notch.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds value by explaining the meaning of 0 ('0 = disabled') and specifying the default value ('default: 0'), which goes beyond the schema's parameter description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Set dterm_notch_hz: Static D-term notch centre frequency.' It differentiates from siblings by noting it is a static notch and contrasting with dynamic notch ('Rarely needed when dynamic notch is active').
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to use this tool vs alternatives: 'Rarely needed when dynamic notch is active.' This implies using dynamic notch when active, but does not explicitly list all alternative tools or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It discloses the effect (adding noise) and notes the default value and data type. For a simple parameter setting tool, this is sufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at two sentences plus a data type annotation. Every word serves a purpose: naming the parameter, explaining its behavior, and providing usage guidance. No fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one required parameter, no output schema), the description provides all necessary information: what it does, the parameter's meaning, default value, and behavioral caution. No missing elements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single parameter with type and constraints (100% coverage). The description adds valuable context: the typical default (0), the rationale for leaving it at 0, and the data type hint. This goes beyond mere schema repetition.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the yaw D gain, a specific PID parameter. The name 'set_d_yaw' directly indicates the action and resource, and the description elaborates with context about yaw being torque-based and slower, distinguishing it from other D gain setters like set_d_pitch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises that d_yaw is 'usually left at 0' and explains why ('yaw is torque-based and inherently slower; D adds noise'), providing clear guidance on when adjustment is inadvisable. It does not explicitly list alternatives but the sibling tools include analogous setters for other axes, making the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that setting to 0 eliminates delay, and explains the notch count impact relative to RPM filtering. It does not mention side effects, reversibility, or permissions, but for a simple setter of an integer, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise paragraph with no filler. It front-loads the core purpose ('Set dyn_notch_count'), then delivers critical usage guidance in a structured manner. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one parameter, no output schema), the description covers the key aspects: purpose, value ranges, default, and operational context. It does not mention return values or confirmation, but for a setter that is not necessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only defines the parameter 'value' as a UINT8 with min/max. The description adds significant meaning: acceptable values (0, 1-2 with RPM, 4-5 without), the default (3), and the reasoning behind each range. This far exceeds the schema's 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Set' and resource 'dyn_notch_count', and explains its function as 'Number of independently tracked dynamic notches'. It distinguishes from sibling tools by specifying this parameter's role, and provides context on usage like disabling with 0.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use specific values: 'Set to 0 to disable... With RPM filtering active, 1–2 notches... Without RPM filtering, use 4–5.' It also mentions the default value (3). While it doesn't compare to alternatives like set_dyn_notch_max_hz, the context is sufficient for correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description explains the behavioral trait: it cuts or reduces FF at a stick travel threshold (e.g., 90% at value 90). It also gives the range and default, but doesn't disclose all possible side effects (e.g., setting to 0 or 200). Still, it adds significant transparency beyond the parameter name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a type/range/default in brackets. Every sentence is informative—purpose, example, tuning tip. No wasted words; well front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter setter with no output schema, the description covers the key aspects: behavior, interpretation, tuning guidance, and valid range. It could optionally note that this is a stick-travel-based reduction, but it's complete enough for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description only provides type and range. The tool description adds rich semantics: it interprets the value as percentage stick travel where FF is cut, and gives tuning advice. This goes well beyond the schema, making the parameter fully understandable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Reduces FF as sticks approach maximum deflection.' It uses a specific verb-resource combination and distinguishes from siblings like set_feedforward_boost by explaining the unique behavior of reducing feedforward near stick limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly guides usage with tuning advice: 'Raise to 92–95 for crisper move entry on responsive builds.' It provides a default and range, but doesn't explicitly state when to avoid or compare to alternatives, though the context of many feedforward siblings makes the behavior distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that the set value is only effective for PWM protocols and is overridden by DSHOT, a key behavioral trait. It also mentions the default value. This adds significant context beyond the schema, though it could note prerequisites (e.g., PWM protocol must be active).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—one sentence that front-loads the name and purpose, then provides essential details (protocols, default). No unnecessary words, every part adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter setter, the description covers the parameter's meaning, default, and protocol-specific behavior. It implicitly defines the valid range (UINT16) despite the schema's wide range. No output schema is needed; the description is complete for agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (param description exists), but the description adds meaning: it defines the parameter as a UINT16 with a default of 1000 and explains what the value represents (PWM when disarmed/zero-throttle). This enriches the bare schema description, earning above baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the 'min_command' parameter, a PWM value for ESCs when disarmed or at zero throttle, specifically for PWM-based protocols. It distinguishes itself from sibling 'set_' tools by naming the exact resource and providing context, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that this setting applies to PWM-based protocols and notes that for DSHOT it is overridden, giving clear usage context. It does not explicitly state when not to use it, but the DSHOT note effectively limits its relevance. No alternatives are mentioned, but given the tool's specificity, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses the parameter type (UINT16), default value (0 per profile), and the required feature (USE_WING), making the tool's behavior transparent for a configuration setter.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus metadata, front-loaded with the tool's purpose and key details. Every part earns its place, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter with one parameter, the description covers the tool's function, the required feature, and parameter type/default. It is sufficiently complete for an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema by explaining the parameter's purpose (setpoint width for yaw SPA attenuation ramp) and its default value, providing useful context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Set' and the resource 'spa_yaw_width', and explains it as 'Setpoint width for yaw SPA attenuation ramp.' This distinguishes it from sibling tools like set_spa_yaw_center, set_spa_yaw_mode, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly specifies a prerequisite condition: 'Requires: USE_WING', which guides the agent on when the tool can be used. However, it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states the data type (UINT16), default value (2520), and the TPA mode context (BASIC speed). The setter behavior is straightforward, and no side effects are omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: a single informative sentence followed by the requirement and type/default in parentheses. Every part adds value, and there is no redundancy or wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of this setter (one parameter, no output schema), the description covers all essential aspects: purpose, required feature, data type, unit, and default value. It is fully adequate for an agent to understand and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage with a description of 'Value for tpa_speed_max_voltage (UINT16)', but the tool description adds the critical unit 'mV×0.1' and the default value, which are not present in the schema. This extra context helps the agent understand the parameter's scale and typical value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the maximum pack voltage parameter used for normalizing motor speed in BASIC speed TPA. It specifies the exact resource and its role, distinguishing it from other tpa-related setters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly lists a prerequisite ('Requires: USE_WING'), providing a clear condition for using the tool. However, it does not offer explicit guidance on when to use this tool versus its siblings or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description discloses the requirement and data range/default. As a read-only operation, no side effects need to be disclosed. The transparency is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single sentence plus structured requirement and type info. No redundant words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter, the description covers purpose, usage context, return format, and constraints. With no output schema needed, it is fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, so schema coverage is 100%. The description adds context by specifying unit (mA), range (0–16000), default value (0), and usage case, which is excellent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the current offset applied to ESC sensor current reading in mA, and includes the purpose of zero-calibration. This distinguishes it from other related tools like set_esc_sensor_current_offset.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says to use for zero-calibrating ESC current reporting and notes the required define USE_ESC_SENSOR. It does not mention when not to use or alternatives, but for a simple getter this is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully explains the behavioral effect of the parameter: it reduces feedforward as sticks approach maximum deflection, with a specific threshold example. It also discloses the valid range (0-200) and default value (90), providing complete behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence followed by a brief tuning note. Every sentence adds value: purpose, behavior, example, range, default, and usage advice. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no input schema, no annotations, and no output schema, the description covers the purpose, parameter meaning, range, default, and a tuning recommendation. It does not explicitly state the return value format, but the context implies it returns a UINT8. Overall adequate for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no input parameters, so schema coverage is 100%. According to the rules, for 0 parameters baseline is 4. The description adds no additional parameter semantics but does explain the meaning of the value that would be returned.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the feedforward_max_rate_limit parameter and explains its function: reducing FF as sticks approach max deflection. It also provides a specific example (90 = cut at 90% travel). This distinguishes it from sibling tools which either set or get other parameters.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a concrete usage scenario: 'Raise to 92–95 for crisper move entry on responsive builds.' While it doesn't explicitly list when not to use or compare to alternatives, the single-purpose nature of the tool makes usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry behavioral info. It discloses the possible return values and default, which is helpful. It does not explicitly state it is read-only, but 'get' implies that. No side effects are mentioned, which is acceptable for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently explains the purpose, possible values, and default. No unnecessary words; every part adds value. Well-structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the tool (no parameters, no output schema), the description fully covers what the agent needs: what the tool retrieves, what the possible values mean, and the default. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so schema coverage is 100%. The description goes beyond by explaining the meaning and default of each return value, which adds significant value since there is no output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the gps_rescue_alt_mode and explains each possible value (MAX_ALT, FIXED_ALT, CURRENT_ALT) with brief definitions. The verb 'get' and resource 'gps_rescue_alt_mode' are explicit, and it distinguishes from related settings like set_gps_rescue_alt_mode.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is straightforward: call to read the current altitude mode. No explicit when-not or alternatives are needed, as the tool has no parameters and is a simple getter. The sibling setter provides clear complement. However, no explicit guidance on when to use vs. other getters, but it's implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses it is a read operation ('Get') and provides the data type and default. No contradictory or misleading information; the tool's behavior as a simple parameter getter is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that includes the core purpose and technical details (type, default) in a compact format. Every part is meaningful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with no parameters and no output schema, the description provides all necessary information: what is retrieved, its type, and default. The agent can invoke it correctly without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the input schema is empty, so no parameter description is needed. The schema coverage is 100%, and the description provides relevant context about the return value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the 'Dynamic LPF1 maximum cutoff (at full throttle)', which is a specific and distinct resource among many getters for gyro and other parameters. It includes type [UINT16] and default value, making it unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like get_gyro_lpf1_dyn_min_hz or get_gyro_lpf1_static_hz. However, the name and brief description imply it is for querying the maximum cutoff, so usage is implied but not explicitly differentiated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It indicates a read operation ('Get') and adds transparency about the value's unit, default, and dependencies. For a simple parameter getter, this is sufficient. The description does not contradict any annotations (none present).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence with additional parenthetical details. It is front-loaded with the tool name and action, followed by the value's description, unit, prerequisite, data type, and default. No redundant words; every element adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema, no annotations), the description is complete. It covers what the tool does, the value's meaning, unit, prerequisite, and default. The agent can correctly invoke this tool without further information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters (input schema empty, coverage 100%), so the description's role is to explain the returned value. It does so thoroughly: meaning (maximum pack voltage), unit (mV×0.1), context (normalize motor speed), and default (2520). This fully compensates for the lack of an output schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource ('maximum pack voltage'), the action ('Get'), and the context ('used to normalize motor speed in BASIC speed TPA'). It distinguishes from sibling tools like get_tpa_speed_type by specifying the parameter name and its role. Additional details such as unit (mV×0.1), prerequisite (USE_WING), and default value (2520) are included, making the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool: when you need to read the maximum pack voltage parameter for TPA. The prerequisite 'Requires: USE_WING' signals a condition for the tool's availability. While it does not explicitly list alternatives or when not to use, the tool's specific name and context (BASIC speed TPA) naturally distinguish it from other parameter getters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It explains the behavior (boosts P-term on rapid throttle changes) and provides a troubleshooting hint. It does not cover persistence or immediate effect, but the parameter range and default are given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences plus a parenthetical. It is front-loaded with the parameter name and purpose, and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple set tool with one parameter and no output schema, the description covers purpose, when to use, parameter details, and troubleshooting. It is fully adequate for an AI agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds significant meaning beyond the schema: it explains the parameter's effect (boosts P-term in addition to I), type (UINT8), range (0-250), and default (100). Schema coverage is 100% and description enriches it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the anti_gravity_p_gain parameter, specifies its function (boosts P-term on rapid throttle changes), and provides a troubleshooting hint. It is distinct from sibling tools like get_anti_gravity_p_gain or set_anti_gravity_gain.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear scenario when to adjust: 'Reduce if punches cause P-induced oscillations.' It does not explicitly mention when not to use it or alternatives, but the context is sufficient for an agent to infer appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It explains the core behavior (blends FF toward zero near stick center), the meaning of different values, and the conflict with feedforward_jitter_factor. No contradictions, and the critical warning adds transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, with essential information front-loaded. Two sentences plus a bracket note cover purpose, behavior, examples, and a critical warning. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single integer parameter, no output schema, no annotations), the description is fully adequate. It explains behavior, provides value guidance, and warns about a sibling conflict, which is the main contextual consideration.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% but the description adds substantial meaning: explains the effect of different values (0=racing, 40=freestyle/HD, 70=cinematic), specifies the range and default, and provides the critical context about combining with jitter factor. This goes well beyond the schema's basic description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the feedforward_transition parameter and explains its behavior (blends FF toward zero near stick center). It gives concrete example values for different flight styles, and distinguishes from siblings by explicitly warning about interaction with feedforward_jitter_factor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to set to 0 (when feedforward_jitter_factor is active), with a warning not to combine them. It also implies usage contexts through value examples (racing, freestyle/HD, cinematic). However, it does not compare directly with other feedforward siblings like averaging or boost.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so description fully carries transparency burden. Discloses range [UINT16, 250–3000, default: 500], explains effect of higher Q (narrower notch, less phase delay), and tuning advice. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with purpose, each earning its place. Includes range in brackets for quick reference. No extraneous words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 1-parameter tool with no output schema, the description covers purpose, effect, recommended usage, and tuning guidance, making it fully actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% coverage for a single parameter but only states range. Description adds critical context: target value, default as starting point, behavioral effect, and when to adjust. Significantly enhances meaning beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states 'Set rpm_filter_q: Q factor (notch sharpness)', establishing the verb and resource. Differentiates from sibling tools like set_rpm_filter_weights by focusing on the Q factor specific to this parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides specific guidance: target 1000 on well-configured 5" builds, default 500 as starting point, and when to back off (if motor noise bleeds through). Does not explicitly exclude alternatives, but the context is clear for this specific parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Despite no annotations, the description fully discloses behavior: it is a read operation, returns a UINT8 value (range 1-250, default 50), and provides tuning advice. This compensates for the lack of output schema and ensures the agent understands the tool's safe, non-destructive nature.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a bracketed specification. No redundant words, and the key information (purpose, data type, range, default, tuning hint) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool with no output schema, the description provides all necessary context: what it does, the value range, default, and when to adjust it. This fully equips an agent to select and invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has no burden to add parameter details. The baseline score of 4 applies since the schema coverage is 100% and no parameters exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves the P gain of the dynamic idle RPM controller, using the verb 'Get'. It specifies the resource and includes a tuning hint ('Reduce if idle causes oscillation'), making the purpose unambiguous and distinct among many sibling 'get_' tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear when-to-use hint ('Reduce if idle causes oscillation'), implying the tool is useful for diagnosing or adjusting idle oscillation. No explicit alternatives or when-not-to-use guidance is given, but the context is sufficient for its simple role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully bears the transparency burden. It discloses that this is a read operation, provides the value's meaning, range, default, and units. No contradictions or omissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise and front-loaded with purpose, then expands with effect, typical ranges, and troubleshooting. Every sentence adds unique value with no redundancy. Appropriate length for the information conveyed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description fully explains the returned value's meaning, typical values, and adjustment guidance. For a simple getter, this is complete and actionable for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description adds value by explaining the returned value's semantics and range. Per calibration, 0 parameters yields baseline 4, and the description meets that by providing contextual information beyond what schema offers.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool retrieves the cutoff frequency for the I-term relax HP filter, explains the effect (higher = faster, lower = smoother), and provides typical ranges for different drone types. This distinguishes it from siblings like get_iterm_relax or get_iterm_relax_type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description gives implicit usage guidance through tuning ranges and a troubleshooting tip (step down if bounce-back persists). However, it does not explicitly state when to use this tool versus alternatives, nor does it list exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It transparently states the return type (UINT16), default value (1000), and the protocol override behavior for DSHOT, which is crucial for correct interpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first defines purpose, second adds important nuance. No wasted words, front-loaded with critical info. Excellent conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless getter with no output schema, the description fully covers what is returned, its type, default, and edge case behavior (DSHOT override). Nothing missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline is 4. The description adds value by specifying the default value and protocol override, which helps understand the meaning beyond an empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies the tool retrieves the 'min_command' parameter, defines it as PWM value for ESCs when disarmed/zero throttle, and distinguishes it from other get_ tools by detailing its specific meaning and protocol behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives, but the context around PWM vs DSHOT protocols implicitly guides usage. As a simple getter with no siblings for the same parameter, explicit guidance is not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the connection closure during reboot, a key behavioral trait. However, it could note prerequisites like disarming, but is still strong for a simple reboot.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with purpose, no waste. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is fully complete: purpose, consequence, and next steps are covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so baseline 4. Description correctly needs no additional param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action ('Reboot') and the resource ('flight controller'), making the purpose clear. Among siblings like reconnect_flight_controller and various set/get tools, this is distinct.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It advises that the connection will close and explicitly suggests using reconnect_flight_controller or connect_flight_controller afterward, providing clear post-reboot guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that tracking low frequencies causes unwanted filtering of PID-relevant signals, a key behavioral consequence. It doesn't mention persistence or required reboot, but for a simple parameter setter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences), front-loaded with the title and purpose, and ends with inline schema info. Every sentence contributes meaning without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, usage, parameter semantics, and behavioral trade-offs. It doesn't mention effect timing (e.g., immediate, after save/reboot), but for a simple setter this is acceptable. Given no output schema and complete siblings, it is nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds significant value: it states the default (100), the range [20–250], the type (UINT16), and provides contextual guidance on recommended value calculation and the trade-off of low values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the minimum frequency for dynamic notch tracking. It uses the verb 'Set' on the resource 'dyn_notch_min_hz' and explains its role as the lower bound for notch frequency. This distinguishes it from siblings like set_dyn_notch_max_hz.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance: set ~25 Hz below the lowest resonance, ideally >=150 Hz unless blackbox shows real resonance below that. It warns against tracking low frequencies to avoid unwanted filtering, giving clear when-to-use and what-to-avoid advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses the behavioral impact: setting a distance threshold that, if violated, causes disarm and drop. This crucial safety context is clearly communicated, along with the data type, range, and default value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. It starts with the tool's purpose, follows with a clear safety note, and ends with the data specification. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple parameter-setting tool with full schema coverage, the description is complete. It covers the parameter's effect, safe usage, and technical constraints. No output schema is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, but the description adds meaning beyond the schema by specifying the value as UINT16 with range 5–30 and a default of 15. This helps the agent understand the expected input format and typical value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool sets the 'gps_rescue_min_start_dist' parameter and explains its purpose: 'Minimum distance from home to activate rescue.' It also describes the consequence ('Closer than this → disarm and drop'). This effectively distinguishes it from sibling tools like get_gps_rescue_min_start_dist and other GPS rescue settings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly explains when to use this tool: to prevent accidental rescue activation near home. It also implies the risk of setting the value too low. However, it does not explicitly state when not to use it or compare with alternatives (e.g., other rescue distance settings).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations were provided, so the description carries the full burden. It discloses the behavioral traits: it sets a UINT8 value, defaults to 14, and warns about consequences of wrong values affecting filter frequency tracking. This goes beyond the input schema by adding type, default, and impact, thus providing excellent transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with three substantive sentences and one brief bracket annotation. It places the most important information first (what it sets and its criticality), followed by practical advice and consequences. No fluff, every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple setter tool with one parameter and no output schema, the description is complete. It covers the purpose, the parameter's meaning, typical usage, and the impact on system behavior. No additional context is needed for an AI agent to use this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter 'value' described as 'Value for motor_poles (UINT8)'. The description adds significant meaning: it explains that the value represents the number of magnetic poles (not stator poles), its criticality for RPM filters, the typical value for common motors, and the consequence of error. This greatly enhances understanding beyond the schema alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool sets the number of magnetic poles on the motor bell, specifically distinguishing magnet count from stator count. It explains the critical importance for RPM filter accuracy. This is a specific verb and resource, and since each set_* tool is for a different parameter, it is sufficiently distinguished from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit guidance on when to use the tool: when configuring motor poles for RPM filter accuracy. It includes a typical value (14 for 5" motors) and a warning about incorrect values leading to wrong filter tracking. Although no direct comparison to alternative tools, the context is sufficient for an AI agent to understand when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![betaflight-mcp MCP server](https://glama.ai/mcp/servers/bvandevliet/betaflight-mcp/badges/card.svg)](https://glama.ai/mcp/servers/bvandevliet/betaflight-mcp)

Score Badge

Copy to your README.md:

[![betaflight-mcp MCP server](https://glama.ai/mcp/servers/bvandevliet/betaflight-mcp/badges/score.svg)](https://glama.ai/mcp/servers/bvandevliet/betaflight-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/bvandevliet/betaflight-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server