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

No annotations exist, so the description must cover behavioral traits. It discloses that pressing triggers actions including transmit, but does not fully detail side effects, error conditions, or permissions beyond 'YOUR OWN TARGETS ONLY.'

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

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

The description is relatively brief with one main sentence plus a warning. It could be more structured (e.g., separating usage notes), but every part adds value.

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

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

Given the tool's advanced and app-specific nature, the description provides basic context but lacks detail on return values (despite having an output schema not shown) and does not differentiate clearly from sibling tools like app_exit or press.

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

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

The schema has 0% description coverage for parameters. The description explains args as 'the button name/index the running app expects,' adding meaning beyond the schema, but lacks examples or constraints (e.g., valid values).

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

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

The description clearly states the tool presses a named in-app button over BLE, including the press-release sequence. It specifies app-specific context (universal IR/Sub-GHz) and warns it's only for own targets, distinguishing it from general press tools.

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

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

The description implies use when an app expects a button press and is advanced ('Advanced + app-specific'), but does not explicitly state when not to use it or provide alternatives like press or press_sequence.

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

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

With no annotations, the description carries full burden. It explains the action is a clean exit and a 'real action' needing approval. Slightly lacking details on error handling or behavior when no app is running, but sufficient overall.

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

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

Two sentences, no wasted words. Purpose is front-loaded, and guidance is immediately actionable. Highly concise.

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

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

Given zero parameters and presence of an output schema, the description covers all necessary behavior: what it does, when to use, and authorization context. 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.

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 no parameter information (not needed) and does not contradict the schema.

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

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

Clearly states the tool exits the currently running app on the Flipper over BLE and returns to desktop/menu. Distinguishes from siblings like app_launch by focusing on exiting.

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

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

Provides explicit usage guidance: 'Use before app_launch if an app is already running.' Also notes that approval is required per call, which helps the agent determine when to invoke.

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

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

The description adds 'Read-only', which aligns with the readOnlyHint annotation. It also explains that the result is a human-readable string obtained over BLE, providing additional context beyond the annotation.

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

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

The description is two sentences long, front-loaded with the tool's purpose, and contains no superfluous words. Every sentence adds value.

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

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

For a tool with no parameters and a clear read-only purpose, the description is sufficiently complete. It mentions the output is a human-readable string, which is adequate given that an output schema exists (though not shown). Could be slightly more precise about error formats, but not necessary.

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

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

The input schema has zero parameters, and schema description coverage is 100% (trivial). According to guidelines, 0 params = baseline 4. The description does not need to add parameter info since there are none.

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

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

The description clearly states the tool reads the last error as a human-readable string over BLE. It uses specific verb 'read' and resource 'running app's last error'. It distinguishes from sibling tools that return status codes, like app_launch, app_button, and transmit.

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

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

The description explicitly says 'Call this when an app_launch / app_button / transmit returns a bare status code, to get the app's own error text.' This provides clear context for when to use the tool, though it lacks explicit when-not or alternative recommendations.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: skips UI navigation, fails on active app or unknown name, args as file path, then_screenshot default. Occasional vagueness ('Real action.') prevents a 5.

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

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

Description is concise (4 sentences) and front-loaded with the main action. The phrase 'Real action.' is slightly redundant but not detrimental. Efficient overall.

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

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

Despite no output schema and 3 parameters, the description covers behavior, constraints, parameter details, and failure modes. It 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.

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

Schema coverage is 0%, so the description compensates fully. It explains 'name' as exact app name with examples, 'args' as optional file path, and 'then_screenshot' defaulting to True. Provides clear semantics beyond the schema.

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

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

The description clearly states the tool's purpose: 'Launch a Flipper app BY NAME over BLE (app_start_request) — skips UI navigation.' It uses a specific verb ('Launch'), resource ('app'), and distinguishes from sibling tools like app_exit and app_button.

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

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

Explicit guidance: 'FAILS if an app is already running (app_exit first) or the name is unknown.' Also advises to get exact names from the app_list, providing clear when-to-use and exclusions.

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

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

No annotations provided, so the description carries full burden. It mentions BLE, request type, and a warning, but does not disclose error handling, potential side effects, or behavior when the app is not running. 'Real action.' 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.

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

Two sentences with a warning symbol. Front-loaded with action and example. No redundant words; each sentence earns its place.

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

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

With an output schema present, return values need not be explained. Description covers BLE transport, prerequisite, and gives a concrete example. However, lacks details on success/error response behavior, which is partly acceptable due to output schema.

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

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

Only one parameter (path) with 0% schema coverage. The description clarifies it's a file path and gives an example extension (.sub), but does not specify format, allowed values, or where to find paths. Adds some meaning but could be more explicit.

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

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

Clearly states the action (open a specific saved file via BLE) and the resource (file in its app). The example '.sub into Sub-GHz' provides concrete context, and the distinction from app_launch is implied by the prerequisite warning.

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

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

Explicitly states the prerequisite that the app must already be running and advises to use app_launch first. This gives clear usage context but does not cover when not to use or alternative tools beyond app_launch.

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

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

Annotations already declare readOnlyHint=true. Description adds 'over BLE' context but no additional behavioral details beyond what annotations provide. No contradiction.

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

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

Single concise sentence with no waste, front-loaded with purpose and usage hint.

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

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

Tool is simple (no params, read-only, has output schema), and description covers purpose and usage adequately without needing further detail.

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

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

Tool has zero parameters; description adds meaning about the check purpose, consistent with baseline 4 for no-param tools.

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

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

Description clearly states the tool checks if an app is running/locking the Flipper via BLE, specifies 'pre-check before app_launch', and distinguishes from sibling tools like desktop_is_locked.

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

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

Explicitly says 'good pre-check before app_launch', providing clear when-to-use guidance relative to the app_launch sibling.

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

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

The description repeats the readOnlyHint annotation by stating 'Read-only,' but adds minimal extra context ('over BLE'). No additional behavioral traits like side effects, permissions, or rate limits are disclosed. Since annotations already cover safety, the description adds little value beyond redundancy.

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

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

The description is a single sentence, front-loaded with the core question, and contains no unnecessary words. It is highly concise and efficient.

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

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

For a simple boolean check tool with no parameters and an output schema, the description is adequate but lacks context about return values or usage scenarios. It does not mention that the output is a boolean or any edge cases, leaving gaps that the output schema likely fills but the description could supplement.

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

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

There are zero parameters, and schema coverage is 100%. The description correctly does not add parameter details since none exist. Baseline 4 is appropriate for no-parameter tools.

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

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

The description clearly states the tool checks if the Flipper's desktop is PIN-locked, using a question format. It includes a 'Read-only' tag aligning with annotations. However, it does not explicitly differentiate from sibling tools like app_lock_status, limiting clarity for selection.

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

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

No guidance is provided on when to use this tool versus alternatives. Sibling tools like app_lock_status and desktop_unlock exist, but the description offers no context for choosing this over them, making it hard for an agent to decide 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.

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

Discloses likely limitation (swipe-lock only, not PIN) and emphasizes it's a real action. With no annotations, adds useful context but lacks details on 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.

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

Two concise sentences, front-loaded with action and target. No wasted words; the note about PIN adds value efficiently.

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

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

For a 0-parameter tool with output schema, the description covers purpose, method, and limitation. Could mention output but output schema covers it. Sufficiently complete.

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

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

No parameters exist, so schema coverage is 100%. Baseline 4 is appropriate; description adds nothing about parameters as there are none.

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

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

Clear action verb (clear), specific resource (desktop lock), method (over BLE), and distinction from PIN unlock. Clearly states what the tool does.

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

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

No explicit guidance on when to use vs alternatives. Implies usage to unlock desktop, but no conditionals or sibling comparisons.

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

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

Annotations already declare readOnlyHint=true; description adds value by specifying wireless BLE, 60+ fields, and return format. 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.

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

Single sentence packed with essential information: what it does, how (wireless BLE), scope (60+ fields), return type. No fluff.

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

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

Given zero parameters and no output schema, description fully covers behavior (read-only, wireless, fields, return format). Adequate for invocation.

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

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

No parameters exist, so baseline of 4 applies. Description correctly notes no arguments needed.

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

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

Clearly states read operation on device_info with specifics (60+ fields, wireless BLE, map return). Does not explicitly differentiate from siblings like healthwatch or power_info, but 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.

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

No guidance on when to use or when not to use. No mention of alternatives or prerequisites. Implicitly for retrieving device info, but lacks context.

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

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

No annotations, so description carries full burden. Discloses it is a real action (noise + light) using system_play_audiovisual_alert, with clear side effects. No hidden 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.

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

One sentence with parenthetical clarifications, front-loaded with purpose. 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.

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 an output schema, the description fully explains the action. Return values are covered by output schema, so completeness is satisfactory.

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

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

No parameters; schema coverage 100%. Description adds value beyond schema by explaining the action's nature and reachable output, earning baseline 4.

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

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

Clearly states the verb 'Make', resource 'Flipper', and output 'beep + flash' for locating over BLE. Distinguishes from CLI-only alternatives, making it distinct from siblings.

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

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

Indicates usage for locating via BLE with audible/visual alert, and contrasts with CLI-only options. Lacks explicit 'when not to use' but provides sufficient context.

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

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

Annotations already provide readOnlyHint=true; description adds behavioral context: communication over BLE and internal function name (system_get_datetime). 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.

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

Two short sentences, front-loaded with action and resource, no superfluous words. Very concise.

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

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

Given zero parameters, readOnlyHint annotation, and presence of output schema (not shown but indicated), the description provides sufficient context. No missing information for agent use.

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

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

No parameters exist (0 parameters, schema coverage 100%). Description does not need to add parameter info. Baseline 4 for zero-parameter tools.

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

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

The description uses a specific verb 'Read' and identifies the resource 'Flipper's real-time clock', clearly distinguishing from sibling 'set_datetime' which writes.

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

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

The description implicitly clarifies when to use (to read the clock) and states 'Read-only', but does not explicitly mention the sibling 'set_datetime' as alternative for writing.

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

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

Annotations declare readOnlyHint=true. Description adds the list of specific pins and corrects a prior note about CLI-only, but does not detail response format, errors, or permissions beyond 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.

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

Two short sentences convey purpose, valid parameters, and correction. No waste; front-loaded with action and resource.

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

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

For a simple 1-param tool with an output schema, the description provides the pin list and read-only context. Return value explanation is delegated to the output schema, so coverage is adequate.

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

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

Schema coverage is 0% (no description for the pin property). The description explicitly enumerates the allowed pin values (PC0, PC1, etc.), which is essential for correct invocation.

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

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

The description clearly states the tool reads a GPIO pin, lists valid pin values, and declares read-only behavior. It distinguishes itself from sibling tools like gpio_write and gpio_set_mode by focusing on reading.

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

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

No explicit guidance on when to use this tool versus alternatives. The 'Read-only' label implies no mutation, but no comparative context or prerequisites are provided.

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

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

No annotations are provided, so the description must carry the full burden. It mentions 'Real action' implying execution, but lacks details on side effects, safety, or destructiveness. Minimal behavioral disclosure.

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

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

The description is extremely concise: one sentence with a clear verb+resource, followed by a succinct enumeration of allowed parameters. No unnecessary words.

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

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

Given that output schema exists, description does not need return value details. It covers the tool's purpose, allowed parameter values, and communication method. Lacks information on prerequisites or side effects, but is largely complete for a simple configuration tool.

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

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

Schema coverage is 0%, so the description compensates by listing specific allowed values for pin and mode (e.g., 'output|input'). This adds meaning beyond the schema's generic string type. However, it does not explain the meaning of each mode.

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

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

The description clearly states the action ('Set a GPIO pin mode'), specifies the resource ('GPIO pin'), and mentions communication method ('over BLE'). It distinguishes from sibling tools like gpio_read and gpio_write by focusing on mode setting.

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

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

The description provides allowed pin and mode values, which helps usage, but does not explicitly state when to use this tool versus alternatives (e.g., gpio_write for setting values). Usage is implied but not contrasted.

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

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

With no annotations, the description must disclose behaviors. It mentions the action is 'Real action' and warns about setting mode, but lacks details on errors, idempotency, 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.

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

Two sentences plus a note, front-loaded with the purpose, every sentence adds value with no waste.

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

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

For a simple write tool with an output schema, the description covers pin options, value, and prerequisite. Could mention error conditions or return value but overall adequate.

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

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

Schema description coverage is 0%, but the description lists all valid pin names (PC0, PC1, etc.) and value range (0/1), fully compensating for the schema's lack of descriptions.

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

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

The description clearly states the action (Set) and resource (GPIO OUTPUT pin over BLE), and distinguishes it from siblings like gpio_read and gpio_set_mode.

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

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

It explicitly tells users to set the pin to OUTPUT first via gpio_set_mode, providing a prerequisite and implying when not to use this tool without that step.

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

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

With no annotations provided, the description fully discloses that the tool is read-only, structurally incapable of transmit/write, and details the schedule, monitoring metrics, and notification behavior. This is comprehensive transparency.

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

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

The description is well-structured with a brief overview followed by a bulleted list of actions. It is slightly verbose but every sentence adds value, and it's front-loaded with the core purpose.

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

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

Given the tool's complexity (including a scheduled job, multiple actions, and output), the description covers purpose, usage, behavior, and parameters comprehensively. The presence of an output schema further reduces burden.

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

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

Despite the input schema having 0% description coverage and no enums, the description exhaustively documents the 'action' parameter, including explanation of each value (status, on, off, run) and their default behavior.

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

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

The description clearly states the tool manages a scheduled read-only health watch for the Flipper, including what it monitors and the actions available. It distinguishes itself from siblings by its specific function as an on/off switch for a monitoring job, which is unique among the sibling tools.

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

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

The description explicitly lists the four actions (status, on, off, run) and explains what each does. It provides guidance on when to use each, though it does not explicitly state when not to use the tool or mention alternatives.

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

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

The annotation already indicates readOnlyHint=true. The description adds valuable behavioral context: it performs a BLE ping with a round-trip echo, which is consistent with read-only operations. No contradiction.

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

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

The description is a single, efficient sentence with no wasted words. It is appropriately sized and front-loaded.

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

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

For a simple tool with no parameters and a clear purpose, the description is complete. Combined with annotations and output schema, the agent has sufficient context to use it correctly.

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

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

There are zero parameters, and schema description coverage is 100%. Baseline for 0 params is 4. The description does not need to add parameter info.

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

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

The description clearly states the tool pings the Flipper over BLE for liveness and round-trip echo check. It is a specific verb-resource pair and distinguishes itself from sibling tools which 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.

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

The description implies usage for connectivity checks but does not explicitly state when to use it versus alternatives or when not to use it. More guidance would be helpful given 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.

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

Annotations already indicate readOnlyHint=true; description adds 'Read-only, no device action' and details returned content, providing context beyond the annotation 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.

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

Description is concise, front-loaded with purpose and usage instruction, 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.

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

Given no parameters, presence of output schema, and annotations, the description fully informs the agent of its use and return contents.

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

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

No parameters exist, and schema coverage is 100%. Per guidelines, baseline is 4. 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.

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

The description explicitly states it is an 'operating manual' that returns control algorithm, menu maps, app-entry recipes, and device behaviors, clearly distinguishing it from sibling action tools.

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

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

Explicitly instructs 'CALL THIS FIRST in a fresh session before navigating the device', providing clear when-to-use guidance.

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

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

The description confirms the read-only nature already indicated by annotations, and adds value by specifying the output format (map of fields: voltage, current, charge %, temperature, charging state). This provides context beyond the annotation alone.

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

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

The description is a single sentence that is well-structured and front-loaded with the purpose. It includes all necessary information without any fluff.

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

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

The description is complete for a simple read-only tool with no parameters. It explains the return format and lists the fields, compensating for the lack of an output schema.

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

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

There are no parameters (0), and the schema coverage is 100% (trivially). The description adds meaning by listing the fields returned, which is essential given no output schema. This exceeds the 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.

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

The description clearly states it provides detailed battery/power info over BLE as a field-value map, listing specific fields (voltage, current, charge %, temperature, charging state). It distinguishes itself from sibling tools like device_info and healthwatch by its specific focus and the 'Read-only' qualifier.

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

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

The description implies usage for battery/power information, but does not explicitly state when to use this tool versus alternatives like device_info or healthwatch. The agent can infer usage from the tool name and content, but there is no explicit guidance or exclusion criteria.

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

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

No annotations provided, so description carries full burden. It mentions injecting a button and optional screenshot, but lacks details on side effects, permissions, or destructive nature. The last sentence about 'Claude Desktop prompts' is unclear and adds noise.

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

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

Front-loaded with purpose, but includes a vague final sentence that could be removed. Otherwise concise for the information provided.

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

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

Covers all three parameters adequately, but lacks explanation of output (e.g., how screenshot is returned) and error states. No cross-reference to sibling tools like 'screenshot'.

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

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

Schema coverage is 0%, but the description fully enumerates allowed values for 'button' (up|down|left|right|ok|back), 'kind' (short|long|press|release, default short), and explains 'then_screenshot' with default and behavior. This adds critical meaning beyond the schema.

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

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

The description clearly states the action ('Inject a UI button over BLE') and the resource ('drive the Flipper wirelessly'). Lists specific button values, distinguishing from sibling 'press_sequence' which handles sequences.

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

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

No explicit guidance on when to use this tool vs alternatives like 'press_sequence'. No conditions, exclusions, or prerequisites mentioned.

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

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

No annotations provided, so description carries full burden. It states 'Real actions — approve per call,' indicating each press is executed and requires approval. However, it does not disclose rate limits, maximum sequence length, or error behavior. Adequate but could be more detailed.

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

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

Description is relatively short, front-loaded with purpose, and each sentence adds value. Could be slightly more structured (e.g., separate sections), but overall efficient and clear.

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

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

Given only 2 parameters and no output schema, description covers parameter semantics well and mentions screenshot capture. However, it does not specify return format (e.g., whether screenshot is returned). Minor gap for completeness.

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

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

Schema coverage is 0%, so description fully compensates. It explains the 'buttons' parameter format (space-separated btn[:kind] with examples) and 'then_screenshot' default behavior (capture final screen). Adds meaningful context beyond property names.

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

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

Description clearly states the tool injects a sequence of buttons in one BLE connection for efficient multi-step navigation. The verb 'inject' and resource 'sequence of buttons' are specific, and it distinguishes from sibling tools like 'press' (single press) and 'screenshot' (separate capture) by combining both.

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

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

Description explains efficiency ('one connect instead of one per press') and provides example usage ('down down ok'). It implies when to use (multi-step navigation with optional screenshot), but does not explicitly state when not to use or mention alternatives. Sibling comparison is clear.

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

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

Description adds 'newest by timestamp', 'decoded text or a binary summary', and 'over BLE' beyond the annotations. No contradiction with readOnlyHint=true; both say 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.

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

Two sentences, front-loaded with core purpose, no fluff. Every sentence provides value.

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

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

Given low parameter count and output schema existence, description covers tool purpose, parameter meaning, return type, and usage context thoroughly.

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

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

Schema coverage 0%, but description adds meaning by listing example folder paths ('/ext/nfc', '/ext/subghz', etc.) and explaining its role as the directory to search for the latest file.

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

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

Description clearly states it reads the most-recently-saved file in a Flipper folder over BLE, with specific examples like NFC, Sub-GHz, RFID. It distinguishes from siblings like storage_read by emphasizing 'latest' and 'newest by timestamp.'

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

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

Provides context for when to use: 'pull the NFC card / Sub-GHz capture / RFID dump you just saved on the device.' Does not explicitly state when not to use or name alternatives, 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.

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

Disclosures that BLE link drops during restart and that DFU/UPDATE are real bootloader modes. Annotations already indicate destructiveHint=true, so the description adds value by specifying the impact on connectivity.

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

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

The description is a single sentence with a warning, efficiently conveying purpose and critical usage notes. No unnecessary words.

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

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

Covers the essential behavioral and parameter details. With an output schema present, absence of return value documentation is acceptable. Could mention error states or prerequisites, but overall sufficiently complete for a reboot tool.

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

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

The schema only defines mode with a default but no description. The description fully explains each mode (OS, DFU, UPDATE) and their roles, compensating for 0% schema description coverage.

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

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

The description clearly states 'Reboot the Flipper over BLE (system_reboot)' with specific modes. While it doesn't explicitly compare to siblings, the verb 'reboot' is unambiguous and distinguishes it from other app tools.

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

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

Explicitly advises using OS mode as a recovery action when the device is wedged and warns against using DFU/UPDATE unless intended. 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.

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

The description details the steps (upload to path if content given, then launch and start) and warns of keystroke injection. Annotations already mark destructiveHint=true, and the description adds context about the 'Real action' and approval per call, enhancing transparency beyond annotations.

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

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

The description is concise, using a warning emoji at the start and covering all key points in a single paragraph. It is front-loaded with the essential purpose and warning, but the phrase 'Real action — approve per call' is slightly cryptic.

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

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

For a destructive tool with no output schema and 0% schema coverage, the description adequately explains the workflow (upload, launch, start), the return ('run screen'), and the risk. It covers most gaps but could clarify the return format or error scenarios.

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

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

With 0% schema coverage, the description explains that 'content' is uploaded to 'path' and provides a path example. This adds meaning to both parameters, though it could specify the expected format of content (DuckyScript commands) more precisely.

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

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

The description clearly states 'Run a BadUSB (DuckyScript) payload over BLE' and explains the process (upload content if given, launch app, start). It distinctly identifies the tool's action and resource, differentiating it from sibling tools like storage_write and app_launch.

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

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

The description warns 'YOUR OWN machine / authorized targets ONLY', providing clear usage context and emphasizing the destructive nature. However, it does not explicitly state when to use this tool versus alternatives (e.g., manual file writing + app launch).

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

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

Annotations already declare readOnlyHint=true, and the description adds that it is a diagnostic with 'No device action.' This reinforces the read-only nature and explains the tool's behavior (scanning BLE). It provides useful behavioral context beyond the annotation, though it does not detail failure modes 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.

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

The description is concise, with two sentences front-loaded with the key term 'Diagnostic.' Every word adds value, with no wasted information.

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

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

Given no parameters and the existence of an output schema, the description is complete. It provides enough context for an agent to understand when and why to use this diagnostic tool, and it covers the necessary behavioral aspects.

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

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

The tool has no parameters, so baseline is 4. The description adds full meaning by explaining that the tool performs a BLE scan with no arguments, which is clear and sufficient.

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

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

The description clearly states the tool's purpose: a diagnostic to check if the Flipper is advertising over BLE. It specifies the resource (Flipper) and the action (check BLE advertising), distinguishing it from siblings like 'ping' or 'device_info' which serve different diagnostic purposes.

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

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

The description implies when to use: for diagnosing connectivity when Flipper seems offline, and provides context (if not advertising, likely connected to phone or asleep). However, it does not explicitly state when not to use or compare to alternatives like 'ping'.

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

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

Adds context beyond readOnlyHint: specifies BLE transport, PNG format, and screen size (128x64). Contradicts nothing in annotations.

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

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

Extremely concise: two sentences, front-loaded with emoji for visibility, no wasted words.

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

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

Fully covers the tool's purpose, output (PNG), and safety profile. No output schema needed; description explains return format. No missing information for a simple read-only tool.

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

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

No parameters; schema coverage is trivially 100%. Description adds no parameter-specific info, but baseline for 0 params is 4.

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

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

Clear verb 'Capture' with specific resource 'Flipper's 128x64 screen as a PNG over BLE'. Distinguishes from siblings like device_info, scan, and others that are not screenshot-related.

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

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

Explicitly states 'Read-only/observational (safe to auto-allow)', guiding agents to use it for observational tasks without risks. Lacks explicit mention of alternatives or when not to use, but sufficient given simplicity.

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

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

The description goes beyond the readOnlyHint annotation by detailing what specific states it reports and confirming no side effects, 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.

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

Two concise sentences with no filler; first sentence lists checks, second provides usage guidance and a summary quote, efficiently conveying all needed information.

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

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

Given no parameters and an output schema, the description fully covers purpose, behavior, and usage, leaving no gaps for an agent to interpret.

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

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

Input schema has no parameters; schema coverage is 100%. The description does not add parameter info (unnecessary), and baseline for zero parameters is 4.

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

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

The description clearly identifies the tool as a self-test/diagnostics, enumerating specific checks (daemon up, BLE link, etc.), and distinguishes it from sibling tools by being read-only and not forcing a connect.

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

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

Explicitly states when to use ('debug wireless toolkit health'), what it does not do (does not force a connect), and emphasizes its read-only nature, guiding the agent away from alternative tools.

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

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

No annotations are provided, so the description must bear the full burden. It mentions the action is over BLE and includes 'Real action' implying execution, but lacks details on permissions, error handling, or idempotency. The output schema may cover return values, but the description itself 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.

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

Two sentences, front-loaded with the purpose, and no extraneous content. Every sentence earns its place.

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

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

For a simple set-datetime tool with one parameter and an existing output schema, the description covers the parameter usage and communication method (BLE) sufficiently. No gaps identified.

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

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

With 0% schema description coverage, the description fully compensates by explaining the 'when' parameter: it accepts 'now' or a specific datetime format 'YYYY-MM-DD HH:MM:SS'. This adds significant meaning beyond the schema's bare defaults.

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

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

The description clearly states 'Set the Flipper's clock over BLE' with a specific verb and resource. It distinguishes itself from the sibling 'get_datetime' by indicating it is a set operation.

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

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

It provides explicit guidance on the two modes: using 'now' to sync with the Mac's time or passing a specific datetime format. However, it does not explicitly state when not to use it or mention alternatives beyond the sibling.

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

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

Annotations already indicate destructiveHint=true; description reinforces irreversibility with 'Real action — irreversible' and provides additional context about BLE transport and the underlying function name.

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

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

The description is a single, front-loaded sentence with no wasted words, effectively using a warning emoji and concise phrasing to convey the core action and parameters.

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

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

Given the tool has two parameters, destructive behavior, and an output schema, the description covers purpose, parameters, and behavioral warning completely. It references the output schema implicitly through the function name.

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

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

Schema has 0% description coverage; description compensates by explaining both parameters: path (implied as file/dir) and recursive ('for a non-empty dir'), adding meaning beyond the schema.

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

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

The description clearly states the verb 'DELETE', the resource 'file/dir', and the context 'over BLE'. It distinguishes from sibling storage tools by specifying the action and mentioning the parameter for recursive deletion.

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

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

The description mentions using recursive=True for non-empty directories but does not provide explicit when-not-to-use guidance or compare with alternative sibling tools like storage_rename or storage_write.

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

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

Annotations already declare readOnlyHint=true, so description adds value by mentioning the BLE protocol and the path meaning. 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.

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

The description is two short sentences with no unnecessary words, perfectly front-loaded and efficient.

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

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

With an output schema present, the description covers the tool's purpose, inputs, and safety. It could mention the output format, but it's adequate given the output schema.

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

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

The single parameter 'path' is not described in the schema (0% coverage), but the description explains its meaning ('/ext' for SD, '/int' for internal), adding essential semantics.

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

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

The description clearly states the tool returns free/total space on a Flipper filesystem, distinguishing it from sibling storage tools like storage_list or storage_delete. The specific verb 'info' and resource 'storage' are well-defined.

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

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

The description provides context for when to use (checking available space) and specifies the path options, but does not explicitly exclude cases or mention alternatives. However, the purpose is clear enough for selection.

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

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

Annotations already declare readOnlyHint=true. The description adds value by specifying the underlying request type (storage_list_request), output format details, and the read-only nature, which aligns with annotations. 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.

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

The description is two sentences, compact and efficient. The first sentence states the action and protocol, the second provides path examples and output format. No wasted words.

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

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

The description covers the return format (dirs tagged, file sizes) adequately for a simple list tool. However, it lacks details on error handling or behavior for invalid paths. Given the tool has one parameter and annotations, it is mostly complete but minor gaps remain.

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

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

The input schema has a single parameter 'path' with no description. The description compensates by providing example values ('/ext', '/ext/subghz', etc.) and explaining the path format, adding essential meaning beyond the schema.

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

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

The description clearly states it lists a directory on Flipper storage over BLE, with specific path examples and output format (dirs tagged [DIR], files show byte size). It distinguishes from siblings like storage_delete and storage_read through the 'read-only' tag and listing action.

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

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

The description implies usage for listing directory contents but does not explicitly mention when not to use it or alternatives like storage_info or storage_stat. Given the sibling set includes multiple storage operations, more explicit 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.

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

Annotations already declare readOnlyHint=true. The description adds 'Read-only' and mentions the underlying protocol (storage_md5sum_request), providing context beyond the annotation about how the tool works over BLE.

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

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

The description is a single sentence with a parenthetical, no verbose or redundant content. Every word adds value.

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

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

For a simple hash computation tool with one parameter and an existing output schema, the description covers essential aspects. It mentions purpose (integrity check) and safety (read-only). Missing are potential error conditions like file not found or size limits.

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

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

The only parameter 'path' has no description in the schema (0% coverage). The tool description does not elaborate on path format, constraints, or examples, leaving the agent to infer from name and context.

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

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

Description clearly states 'MD5 hash of a file on the Flipper over BLE', specifying the verb (compute hash) and resource (file). Distinguishes from sibling tools like storage_read or storage_stat, which do different operations.

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

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

The phrase 'integrity check' implies a use case, but no explicit guidance on when to use or not use this tool versus alternatives, nor any prerequisites.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It only states 'Create a directory' and 'Real action' without detailing what happens on success/failure, whether overwrite occurs, or any side effects. 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.

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

The description is very short, but it omits critical information. 'Real action' is vague and unnecessary. While concise, it fails to be informative, balancing brevity with completeness.

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

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

Although the tool has an output schema, the description does not mention return values, error conditions, or behavior when the directory already exists. Given the simplicity of the tool, more context is needed for reliable use.

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

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

The input schema has one parameter 'path' with no description (0% coverage). The tool description does not explain the expected format, meaning, or constraints of the path parameter, adding no value beyond the schema.

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

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

Description clearly states the action 'Create a directory' and the target 'on the Flipper over BLE', which distinguishes it from sibling tools like storage_read or storage_write. The parenthetical 'storage_mkdir_request' is extraneous but not misleading.

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

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

No guidance is provided on when to use this tool vs alternatives like storage_write or when not to use it. 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.

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

Adds beyond annotations: describes timeout caveat, text vs binary behavior, 8KB cap, example path, and read-only nature. No contradiction with readOnlyHint annotation.

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

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

Three front-loaded sentences covering action, return types, example, and a crucial warning. No redundant information; every sentence serves a purpose.

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

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

Given one parameter, output schema existence, and moderate complexity, the description covers tool purpose, usage context, limitations, and format details comprehensively.

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

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

Schema has 0% coverage for path parameter, but description compensates with a concrete example and format explanation. Could add more detail on length or allowed characters, but sufficient for usage.

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

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

Clearly states the tool reads files from Flipper storage over BLE, describes supported text formats and binary fallback, and distinguishes from sibling write/delete tools by emphasizing 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.

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

Explicitly warns about BLE timeout on large files and directs to USB-based alternative `flipper` server's storage_read, providing 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.

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 only says 'Real action' but does not explain whether overwrites happen, what happens to existing files, 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.

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

The description is very short and to the point, with no extraneous words. However, it could be slightly longer to include critical details without becoming verbose.

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

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

Given no annotations and a tool with two required parameters, the description lacks completeness. It does not mention what the output schema conveys (e.g., success indication) or what behavioral constraints exist.

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

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

With 0% schema description coverage, the description should elaborate on parameters. It only mentions 'old' and 'new' implicitly as file/dir paths, but no format, allowed patterns, or examples.

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

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

The description clearly states the tool renames or moves a file or directory, with the specific resource and action. It distinguishes from siblings like storage_delete, storage_list, etc., as no other sibling handles renaming.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or conditions under which rename/move is appropriate.

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

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

The description adds behavioral context beyond the readOnlyHint annotation by specifying the return values (type and size) and the protocol (storage_stat_request). No contradiction with annotations.

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

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

The description is a single sentence with a parenthetical detail, no wasted 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.

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

The tool is simple (one parameter, has output schema, annotations present). The description provides sufficient context: purpose, result details, and safety. The output schema covers return values, so no further explanation needed.

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

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

Schema coverage is 0%, so the description should add parameter context. While 'path' is self-explanatory, the description does not explicitly describe the parameter format or constraints. It compensates somewhat by stating the overall operation.

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

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

The description clearly states the verb ('Stat'), resource ('file/dir on the Flipper'), and what it returns ('type (FILE/DIR) + size'). It distinguishes from siblings like storage_list or storage_read by specifying a stat operation.

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

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

The description includes 'Read-only.' and mentions the underlying request, implying when to use it (to get file/dir metadata) but does not explicitly state when not to use it or list alternatives.

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

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

No annotations are provided, so the description carries the full burden. It discloses the protocol (chunked storage_write_request), that it overwrites, and that BLE is slow for large files. It does not mention error handling or permissions, but the key behavioral traits are communicated.

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

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

The description is relatively concise given the amount of information. It front-loads the purpose and key constraints (BLE, overwrites). The use of emojis and caps adds emphasis but does not detract from readability. Every sentence provides useful information.

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

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

Given the schema (3 params, 1 required, no enums) and no annotations, the description covers the essential aspects: what the tool does, how to use the parameters, and a performance caveat. It does not describe the output, but an output schema exists, so that is acceptable. Overall, it is sufficiently complete for a write operation.

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

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

Schema coverage is 0%, so the description must add meaning. It explains that content is text (UTF-8), local_path is a file on the Mac, and dest is a full Flipper path with a concrete example. It also clarifies the mutually exclusive nature (EITHER content OR local_path), which adds significant value beyond the schema.

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

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

The description clearly states it writes/uploads a file to the Flipper over BLE. It specifies the two input options (content or local_path), the required dest parameter with an example, and that it overwrites. It distinguishes from sibling tools like storage_read, storage_delete, and others.

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

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

The description explains when to use (write/upload) and provides guidance on which parameter to provide (EITHER content OR local_path). It warns about BLE being slow for large files and suggests USB as an alternative, though it does not explicitly name a sibling tool for USB. Overall, usage context is well covered.

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

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

Annotations already provide destructiveHint: true, and the description adds value by warning of real IR, requiring approval per call, and explaining that it launches the app and shows the button list. It does not cover error cases but provides sufficient transparency for the core behavior.

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

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

The description is concise, front-loaded with a warning, and contains only relevant information. It efficiently conveys purpose, usage, and a sibling reference. 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.

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

Given the tool's complexity (2 parameters, no output schema), the description adequately covers the overall workflow and integration with sibling tools press and screenshot. It does not discuss error handling or return values, but since no output schema is provided, this is acceptable. It could be more complete by explicitly describing the screenshot parameter.

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

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

With 0% schema description coverage, the description must explain parameters. It provides an example for path ('/ext/infrared/TV.ir') but does not explain the then_screenshot parameter or its default. The meaning of then_screenshot is only indirectly implied by the mention of screenshot in the usage flow. This is partial compensation; more explicit parameter descriptions would be better.

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

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

The description clearly states it opens a saved Infrared remote file over BLE, launching the Infrared app to show the button list. It distinguishes from siblings like press by explaining the workflow: open then press to fire a command. The verb 'open' and resource 'saved Infrared remote file' 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.

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

The description explains when to use this tool (to open a remote before pressing buttons) and provides a clear usage flow: open, then use press (+ screenshot). It also mentions approval per call. However, it does not explicitly say when not to use this tool or alternatives, though the context implies it is the necessary first step for IR commands.

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

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

The description adds significant behavioral context beyond annotations. It explains the app-driven flow, the error screen for region lock, and includes a warning about legal bands and liability. It does not contradict annotations; destructiveHint=true aligns with the real RF transmission warning.

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

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

The description is dense but well-structured, using emojis and line breaks to highlight warnings and critical details. Every sentence earns its place—covering purpose, mechanism, example, region lock, and legal reminder—without redundancy.

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

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

Given the tool's complexity (RF transmission with safety implications) and missing output schema, the description covers usage, behavior, and error conditions well. However, it does not specify the return value or success/failure indication, which would be useful for an agent to handle responses.

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

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

Schema coverage is 0%, so the description carries the burden. It provides an example for 'path' (e.g., '/ext/subghz/Tesla/Tesla_US_AM650.sub') but offers no explanation for 'then_screenshot' (boolean with default true). While the path example is helpful, the omission of the second parameter's meaning leaves a gap.

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

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

The description clearly states the tool's function: 'TRANSMIT a saved Sub-GHz capture over BLE'. It specifies the mechanism (app-driven TX path, no direct RPC) and differentiates from alternatives like direct TX or infrared transmission, as implied by 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.

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

The description provides clear context: it's the only way to transmit Sub-GHz (no direct RPC) and mentions region lock and legal band requirements. However, it does not explicitly contrast with sibling tools like transmit_infrared, leaving some ambiguity about when to choose this over other transmission methods.

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