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

With no annotations, the description bears the full behavioral burden, and it does disclose the five rule categories and the shape of the result (severity plus rule violations). It omits other relevant traits: that the operation is non-destructive/read-only, what happens if the screen is mid-transition, and how large the report can get on a dense screen with many violations.

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 action, and the rule list is compact and scannable rather than prose. There is no filler, though the closing sentence about the return value is slightly generic ("structured report") where a concrete field hint would have earned the space.

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 single-optional-parameter, non-destructive audit with no output schema, the description covers what is checked and roughly what comes back, which is enough to invoke it confidently. The residual gap is that without an output schema, the report's actual structure and severity levels remain underspecified.

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

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

Schema description coverage is 100% and there is only one optional parameter (device serial), so the schema already carries the semantics and the baseline of 3 applies. The description adds no meaning beyond it, not even clarifying which device is audited when the serial is omitted.

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 and resource ("Run an automated accessibility audit on the current screen") and itemizes the exact rule categories checked, so the agent knows precisely which capability this is. It falls short of a 5 because two sibling tools in the same family (adb_a11y_touch_targets, adb_a11y_tree) overlap in scope and are never named or differentiated.

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

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

Scope is implied ("on the current screen"), which tells the agent the audit applies to the foreground UI rather than the whole app. However, there is no explicit guidance on when to choose this composite audit over adb_a11y_touch_targets or adb_a11y_tree, nor any stated prerequisites such as a connected device or a screen that has finished rendering.

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 behavioral burden: it discloses that elements below 48dp are highlighted and that values are in dp, which implies a read-only listing. It omits prerequisites (screen state, foreground app), whether it triggers a UI dump, and what the response looks like, so the disclosure is partial.

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 short sentences with the core capability front-loaded and the filtering/interpretation context following. No redundant or filler wording; the only minor inefficiency is that the last sentence restates the purpose already implied by the second.

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 two-parameter read tool with no output schema, the description covers what the tool does and the 48dp rule, but leaves out return structure and device-state prerequisites. Adequate but not complete for an agent calling it blind.

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

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

Schema description coverage is 100%, so both `device` and `belowMinOnly` are already documented and the baseline is 3. The description does reinforce the 48dp threshold that gives `belowMinOnly` meaning, but adds no format or default detail 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 states a specific verb and resource: list interactive elements with touch target dimensions in dp, plus the 48dp threshold that defines a violation. This is enough to distinguish it from adb_a11y_tree (raw hierarchy) and adb_a11y_audit (broader audit), though it never names those siblings explicitly.

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

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

"Useful for quickly identifying cramped UI layouts" implies the usage context, but there is no explicit when-to-use versus adb_a11y_audit or adb_ui_find, and no statement of preconditions such as the target app needing to be in the foreground. Usage is inferred rather than directed.

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 behavioral burden. It does disclose meaningful traits — the filtering of decorative containers and the returned fields (roles, labels, states, navigation order) — but says nothing about prerequisites (foreground app, unlocked screen, accessibility service enabled), output format, or the underlying uiautomator cost.

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 short sentences, front-loaded with the core action and immediately followed by scope and filtering behavior. No filler, though the third sentence could have been merged into the second without loss.

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 one-parameter read tool with no output schema, the description covers what is returned and what is excluded, which is most of what an agent needs. The remaining gap is prerequisite/environment context rather than anything structural.

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 optional parameter 'device' is fully documented in the schema ('Device serial') at 100% coverage, so the schema already does the work. The description adds no semantics about device selection, defaulting, or behavior when omitted.

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

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

States a specific verb ('Dump') and resource ('accessibility-focused view of the UI hierarchy'), and the second sentence clarifies exactly what subset is returned. It implicitly separates itself from the full-hierarchy sibling adb_ui_dump by saying it filters out decorative/layout containers, but it never names that sibling explicitly.

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

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

Usage is only implied: 'elements relevant to screen readers' suggests accessibility testing, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives like adb_ui_dump, adb_a11y_audit, or adb_a11y_touch_targets, all of which sit close to this tool in the sibling list.

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

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

No annotations are supplied, so the description carries the full burden. It usefully discloses the key behavioral trait that connectivity is dropped and the radio re-registers, but it does not say whether the prior radio state is restored, what happens if the device is offline or the toggle fails, or whether it blocks for the full delay.

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

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

Two tight sentences, front-loaded with the action and followed by the rationale. Nothing is padded, though the purpose clause could be slightly tighter.

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

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

For a two-parameter, no-output-schema device action, the description covers what it does, why, and the timing control via the schema. The main gap is the post-condition after the cycle (whether airplane mode is guaranteed off and the radio restored), which matters for a connectivity-disrupting 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 description coverage is 100%, with both device and delaySeconds documented including bounds and default. The description only echoes the delay notion ('after a delay'), adding no syntax or device-selection guidance beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb and resource (cycle airplane mode on then off) plus the mechanism (delay) and effect (forces cellular re-registration). It is clearly distinct from the sibling adb_airplane_mode in practice, though it never names that sibling or states the contrast explicitly.

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

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

It names two use cases (radio diagnostics, network testing), which implies when to reach for it. However, with siblings like adb_airplane_mode, adb_mobile_data and adb_network_scan in the same family, it gives no explicit guidance on when this cycler is preferred over setting airplane mode directly, and no prerequisites 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?

No annotations are supplied, so the description carries the full burden. It doesn't disclose whether airplane mode also disables Wi-Fi/Bluetooth, whether root or permissions are required, whether the change persists across reboots, or any error behavior — significant gaps for a device-mutating radio 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?

Two short sentences with the purpose front-loaded and no filler. It could be marginally tighter given the second sentence is context rather than instruction.

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

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

For a simple two-parameter tool with a fully described schema and no output schema, the definition is close to adequate. It is nonetheless thin for a state-changing device tool with zero annotations, leaving modem/connectivity side effects and the cycle alternative unexplained.

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

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

Schema coverage is 100%, with both `device` and `enabled` fully documented, so the schema does the heavy lifting. The description adds no semantics beyond it, and its word "toggle" slightly conflicts with the explicit boolean `enabled` parameter, which sets state rather than flipping it.

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

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

States a specific verb and resource ("Toggle airplane mode on/off") and adds a scoping note about radio testing. It is cleanly distinguishable from most siblings, though it never mentions adb_airplane_cycle, the nearest alternative, so differentiation is only partial.

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?

"Useful for resetting cellular registration during radio testing" implies a usage context but is not an explicit when-to-use rule. It gives no exclusion or pointer to adb_airplane_cycle, adb_wifi, or adb_mobile_data, which an agent would need to choose correctly.

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 supplied, so the description carries the full burden; it does say the operation is a listing and specifies the returned fields (name, version, active/staged status), which is useful behavioral context. It does not state whether this is strictly read-only, whether any privilege/root level is required, or how staged-but-inactive modules are represented.

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 short sentences, front-loaded with the action and resource, followed by just enough disambiguation and return-value detail. No sentence is redundant or padded.

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

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

For a small inspection tool the definition is nearly complete, and listing the return fields compensates for the missing output schema. The notable gap is the optional device parameter: with zero required parameters, the description never explains default-device selection or behavior when multiple devices are attached.

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

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

Schema description coverage is 100% for the single 'device' parameter, so the schema already documents it. The description adds nothing about what happens when device is omitted (it is not required) or how a device serial is resolved, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('List installed APEX modules on the device') and the parenthetical expansion of APEX makes the subject unambiguous. It does not explicitly contrast itself with nearby siblings such as adb_list_packages or adb_package_info, so an agent must infer that this covers system-level APEX containers rather than regular apps.

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

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

Usage is only implied: explaining that APEX modules 'deliver updatable system components' helps an agent decide relevance, but there is no explicit when-to-use or when-not-to-use statement and no pointer to adb_list_packages / adb_package_info as the alternative for normal app inventory.

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 supplied, the description must carry the full behavioral burden, and it does disclose that the operation is read-only and non-mutating plus the cross-domain data it inspects. It omits operationally relevant traits: whether elevated privileges are required, how the preflight behaves on unsupported Android versions, and roughly what the result contains.

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

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

Two sentences, the scope and correlated resources are front-loaded, and the read-only guarantee closes it out. No filler and nothing repeated from the schema.

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 diagnostic tool with three parameters, no output schema, and no annotations, the definition covers what it inspects and that it is safe, but leaves the agent guessing on prerequisites (root, supported API levels) and on the shape of the returned routing data. Adequate but with clear gaps.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by framing packageName as the pivot for UID correlation and by hinting that VPN/default-network state is part of the correlated output, matching the includeConnectivitySummary toggle. It still doesn't clarify the device parameter's selection behavior when multiple devices are attached.

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

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

States a specific verb ('Show the effective Android routing context') with an explicit scope ('for one installed app') and enumerates the exact data correlated: UID, ip rules, route tables, network policy, VPN, default-network state. This is clearly distinguishable from broad siblings like adb_network or adb_network_connections without opening their schemas.

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

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

The clause 'Read-only; does not alter routes or app policy' functions as a mild exclusion, telling the agent this isn't for changing policy. However, it names no alternative tools, no prerequisites (root vs non-root, device selection), and no failure conditions such as an uninstalled package, so usage is only implied.

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

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

With no annotations, the description does useful work by disclosing "Requires root," a prerequisite the schema does not carry. However, it omits key behaviors for a potentially risky tool: whether execution aborts on the first failed command, that the force flag bypasses dangerous-command safety checks, and how per-command responses are delineated in the output.

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

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

Three short sentences with the core action front-loaded and the root prerequisite surfaced immediately. "Useful for running a diagnostic sequence" is the softest sentence but still earns its place as a usage cue.

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 6-parameter, mutation-capable tool with no annotations and no output schema, the definition covers the essentials (root requirement, sequential execution) but leaves gaps around failure handling and response format. An agent could invoke it correctly but cannot predict behavior when a mid-sequence command fails.

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

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, including ranges and defaults for delayMs and timeout. The description only reinforces ordering ("in order"/"sequentially") and adds no format or content detail beyond it, so the baseline of 3 applies.

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

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

"Send multiple AT commands sequentially and capture all responses" gives a specific verb (send), resource (AT commands), and cardinality (multiple/batch), which cleanly separates it from a single-command tool. It stops short of naming the obvious sibling adb_at_send, so differentiation relies on the agent inferring it from the name.

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

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

"Useful for running a diagnostic sequence" implies the batching use case but never states when to pick this over adb_at_send, adb_at_probe, or adb_at_cross_validate. There are no explicit exclusions or conditions for choosing batch versus single sends.

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 supplied, the description carries the full burden and handles most of it: it discloses the root requirement, the exact modem commands issued, the properties read, and that a per-command timeout applies. It implicitly conveys this is a read/compare operation with no mutation. What it omits is failure behavior (no modem node found, non-root, AT non-responsive) and whether the two sources are queried sequentially.

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

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

Four tight sentences: purpose first, then interpretation of results, then the concrete mechanism, then the prerequisite. Every sentence contributes information and nothing is repeated from the schema or title.

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 moderately complex, root-requiring cross-validation tool with no output schema, the description explains inputs and mechanism well but never describes what comes back — no mention of a per-field comparison result, a mismatch report, or a verdict flag. An agent knows what the tool does but not what to expect in the response, and it lacks guidance on partial failures.

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

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

Schema description coverage is 100%, so port, device, and timeout are already fully documented in the schema, including the auto-detect default for port and the 1000-30000 ms bounds for timeout. The description adds no parameter-level detail beyond that, which is acceptable but not additive. Baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb and resource ('Cross-validate baseband firmware') and explains the mechanism: comparing AT command responses against Android system properties. It names the exact AT commands (ATI, AT+CGMR, AT+CGMM) and properties (gsm.version.baseband, ro.hardware.chipname), which makes the purpose unmistakable. It stops short of naming siblings like adb_baseband_info or adb_at_send, so an agent must infer the distinction from the description alone.

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

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

It gives clear context for when this tool is appropriate by explaining what discrepancies indicate (firmware tampering, incomplete OTA updates, property spoofing) — that is the use case. It also states a hard prerequisite ('Requires root'). However, there are no exclusions and no explicit routing to alternatives such as adb_at_probe for single-command interrogation or adb_firmware_probe for broader firmware inspection.

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 supplied, the description carries the full disclosure burden, and it does deliver real value: root requirement, the probing strategy across known node paths, and the 'first responding node' selection rule. It leaves out what happens when nothing responds (error vs empty), whether probing has side effects on the modem, and any timeout/latency expectations.

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

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

Four short sentences, front-loaded with the action and resource, then capability, then prerequisite, then return behavior. No filler or restatement of the tool name.

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

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

No output schema exists, and the description compensates by stating the return value ('the first responding node'). For a single-parameter detection tool this is largely sufficient; the only material gap is the no-match/failure outcome and whether device selection falls back to the sole connected device.

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 optional parameter and schema description coverage is 100%, so the schema already documents 'device' as the serial. The description never mentions the device parameter or whether omitting it defaults to a single connected device, which is the one ambiguity an agent would want resolved here. Baseline 3 applies.

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

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

States a specific verb and resource: 'Auto-detect the modem AT command device node', plus the chipset families it can identify. An agent can tell this is a discovery/lookup tool rather than a command sender. It does not, however, distinguish itself from the closely related siblings adb_at_probe and adb_at_send, which is the only thing keeping it from a 5.

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

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

Gives one concrete prerequisite ('Requires root') and implies the usage context (find the node before issuing AT commands), but never explicitly says when to pick this over adb_at_probe or adb_at_cross_validate. There are no exclusions or failure-path guidance, so the agent must infer the workflow position from sibling names.

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 usefully discloses the root prerequisite and implies a read-only diagnostic operation, but it does not explicitly state that the probe does not modify modem state, does not describe return content, or mention timeouts or failure 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 a single front-loaded sentence that names the operation, lists its scope, and ends with the root prerequisite. There is no filler or redundancy.

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

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

For a two-parameter, no-annotation, no-output-schema tool, the description covers scope and the root requirement but omits return-value expectations and explicit safety/idempotency context. It is minimally adequate but leaves gaps an agent would want to know before invoking a modem diagnostic.

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 already documents both optional parameters at 100% coverage: port is a modem device node with auto-detection, and device is a serial. The description adds no additional parameter meaning, so the baseline of 3 is appropriate.

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

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

The description states a specific verb and resource: "Run a standard AT diagnostic probe," then enumerates exactly what is collected (modem identification, signal quality, registration, SIM status, bands). This is clear enough to distinguish it from a generic AT send or detect tool, though it does not explicitly name sibling alternatives.

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

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

Usage is implied by "standard AT diagnostic probe" and "Requires root," but there is no explicit when-to-use guidance, no exclusions, and no stated alternative such as adb_at_send for arbitrary commands or adb_at_cross_validate for validation.

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 carry the behavioral load. It discloses the root requirement and that a response is captured, but says nothing about the dangerous-command safety check, what happens when it blocks a command, timeout behavior, or whether the command has device-side side effects.

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

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

Two sentences, zero filler, and the core action is front-loaded ahead of the prerequisite and the port guidance. Nothing could be removed without losing 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?

There is no output schema and no annotations, so the description should say more about what 'capture the response' yields and how the safety check/force interaction behaves. It is adequate for invocation but leaves real gaps for a root-level modem mutation 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 description coverage is 100%, so all five parameters are already documented, including the port/force/timeout semantics. The description adds only the pointer to adb_at_detect for port discovery, which is marginal beyond the schema's 'If omitted, auto-detects.' Baseline 3 applies.

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

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

States a specific verb and resource ('Send a single AT command to the modem') and implies scope via 'single', which distinguishes it from adb_at_batch without naming it. The sibling of closest contrast (adb_at_batch) is never named explicitly, so it falls short of a 5.

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

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

Explicitly routes the agent to adb_at_detect to locate the port, and offers the manual-port alternative. Prerequisite ('Requires root') is stated. It gives clear context but no when-not guidance (e.g., use adb_at_batch for multiple commands, adb_at_cross_validate for verification).

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 supplied, so the description carries the full disclosure burden. It hints that results are filtered to startable AVDs, but says nothing about whether it requires a running emulator or SDK, whether it reads local config only, or what each returned entry contains. For a zero-annotation tool this is thin.

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

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

A single front-loaded sentence with no filler; the scope qualifier ('that can be started') arrives before any trailing detail, so the agent reads the key constraint immediately.

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 zero-parameter list tool with no output schema, the description covers what is enumerated but not what an entry looks like (name vs. ID vs. target API) or how to act on the result. Adequate at minimum, but an agent would need to inspect output to know next steps.

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

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

The tool takes zero parameters, so the baseline is 4. Nothing in the description is needed to explain inputs, and it introduces no misleading parameter expectations.

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?

Uses a specific verb (List) and resource (Android Virtual Devices / AVDs) with a qualifying clause ('that can be started') that narrows scope to launchable images. It does not, however, name a sibling such as adb_emulator_start or adb_qemu_images to distinguish this lookup from the act of starting one.

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

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

Usage is only implied: an agent can infer this is the discovery step before starting an emulator. There is no explicit when-to-use statement, no exclusion of related tools (adb_qemu_images, adb_emulator_start, adb_qemu_list-style siblings), and no prerequisites noted.

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 supplied, so the description carries the full behavioral burden and does not meet it. It never states that this is a read-only query, whether radio/chipset fields require root or a specific RIL state, whether the call can fail or hang on some devices, or what the response looks like. Listing IMEI as a standard returned field also sits awkwardly against the schema's opt-in, sensitivity-gated includeImei flag — a caller could reasonably expect IMEI by default.

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

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

A single front-loaded sentence with a clear verb and an enumerated payload; nothing is redundant. It is dense but readable, and the field list earns its space by telling the agent what to expect.

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

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

There is no output schema and no annotations, so the description is the only source of behavioral context, and it covers only what is collected, not how it is returned or what constraints apply. For a read-only diagnostic tool with fully documented parameters this is minimally adequate, but a mutation-adjacent, permission-sensitive telephony probe warrants more.

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

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

Schema description coverage is 100%, so device, includeImei, result_handle, and result_handle_ttl are all documented in the schema. The description adds no mapping between the enumerated fields and includeImei's opt-in behavior, so it does not meaningfully exceed the schema baseline.

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

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

The description gives a specific verb ('Get') plus the resource ('modem/baseband identification') and enumerates the exact fields returned: firmware version, RIL implementation, chipset, IMEI, SIM state, radio capabilities. An agent can tell this is a broad baseband read. It stops short of differentiating itself from near-neighbors like adb_telephony, adb_firmware_probe, or adb_ril_start, so a 4 rather than a 5.

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

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

There is no when-to-use guidance, no prerequisites, and no named alternative. The word 'comprehensive' hints at a broad diagnostic sweep, but nothing tells the agent whether to prefer this over adb_device_info, adb_telephony, or adb_firmware_probe for overlapping data.

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 supplied, the description carries the full burden, and it does disclose useful behavior: sequential execution and an optional inter-action delay. It does not state what a failed batch returns, whether partial execution leaves the UI in a mutated state, or what the response looks like, which matters for a multi-step input tool with no safety 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?

Three short sentences, front-loaded with the core purpose, then the benefit, then the execution semantics. The trailing enumeration of action types largely duplicates the schema enum, which is the only redundancy.

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

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

For a four-parameter mutation tool with no annotations and no output schema, the description covers purpose, sequencing, and action vocabulary well. It leaves the return value and failure/partial-execution semantics unexplained, which is the main gap for an agent deciding whether to batch a fragile UI flow.

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

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

Schema description coverage is 100% and every parameter (device, actions, delayMs, stopOnError) is documented inline with bounds and defaults, so the schema does the heavy lifting. The description adds only the sequencing concept ('optional delay between them'), which is already implied by delayMs; it adds no new meaning about the args string format.

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 and resource ('Execute multiple input actions in a single tool call') and enumerates the supported action types, which lets an agent distinguish this batching tool from single-action siblings like adb_input or adb_input_text. It never names a sibling explicitly, so differentiation is inferential rather than stated.

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

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

'Reduces ADB round-trips for multi-step UI interactions' implies the use case (chained gestures) without ever saying when to prefer this over adb_input, adb_input_drag, or adb_tap_element. There are no exclusions and no prerequisites, so the agent must infer the selection rule.

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 supplied, so the description carries the full burden; it does signal a read-only snapshot and names the returned fields, which is meaningful disclosure. It omits how the data is sourced, whether the device parameter defaults when 0 required params are given, and whether the call fails on a disconnected device.

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

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

One front-loaded phrase with no wasted words; the resource and returned fields come first. It is arguably under-specified rather than padded, but as a sentence it is 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, single-optional-parameter read tool with no annotations or output schema, the description covers what is returned at a high level. It leaves gaps around default device behavior and return format, which matter because no output schema exists to fill them.

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

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

Schema description coverage is 100% for the single optional 'device' parameter, so the baseline is 3. The description adds nothing about the parameter and does not state what happens when it is omitted, leaving default-device resolution undocumented.

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

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

The description uses a specific verb ('Get') and resource ('battery') and enumerates the data returned: status, level, temperature, and charging info. An agent can tell this is a read of current battery state. It does not, however, distinguish itself from the sibling adb_battery_drain, which an agent choosing between the two would want.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives such as adb_battery_drain for drain analysis or adb_thermal_snapshot for thermal trends. Usage must be inferred entirely from the name and the listed fields.

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 usefully discloses the measurement mechanism (initial and final readings, then calculation), which implies the call blocks for the sampling duration, but it never says the call is read-only, that the device must remain idle for accurate results, or that packageName detailed stats require root (only the schema mentions root).

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 short sentences: purpose, outputs, use case — well front-loaded with no filler. The closing sentence is slightly generic but still informative rather than redundant.

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

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

There is no output schema, and the description compensates by naming the returned metrics. For a zero-required-param, moderately complex sampling tool, the main missing element is the blocking/idle-device caveat rather than anything about inputs or returns.

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

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

Schema description coverage is 100%, so all three parameters are already documented with ranges and defaults. The description references duration and implicitly the target of profiling, but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Measure battery drain rate') and further specifies the computed metrics (mA draw, mW power, %/hour). An agent can distinguish this from adb_battery, which returns instantaneous battery state, though the description never names that sibling explicitly.

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

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

'Useful for profiling power impact of specific operations' implies when to reach for it, but there are no explicit exclusions or pointers to alternatives like adb_battery, adb_top, or adb_perf_snapshot for lighter-weight sampling. Usage context is implied rather than stated.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does well to disclose the sensitive-identifier handling ('MAC address and device name are opt-in only') and implies a read-only probe by using 'Reports', but never states whether Bluetooth must be enabled, whether privileged/root access is required, or what happens on failure.

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 short sentences, zero filler, with the capability list front-loaded and the privacy caveat placed last where it belongs. Every sentence contributes something an agent would otherwise have to guess.

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

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

With no output schema, the enumeration of returned fields substitutes well and tells the agent what it will get back. Three all-optional parameters keep the call surface simple; the only real gap is preconditions (adapter off, permission requirements) for a probe that reads dumpsys-level state.

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

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

Schema description coverage is 100%, including the maxLines range/default and the includeIdentifiers privacy note, so the schema already does this work. The description restates the identifier opt-in rule but adds nothing about when to raise maxLines or what device selection means.

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

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

Names a specific resource (Bluetooth firmware and chipset) and enumerates exactly what is reported: firmware version, BT version, chipset model, adapter state, profiles, LE capabilities, bonded device count. The Bluetooth qualifier cleanly separates it from the analogous siblings adb_wifi_firmware, adb_nfc_firmware, adb_gps_firmware and adb_firmware_probe without needing to name them.

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

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

Usage context is only implied by the content of the report; there is no explicit 'use this when you need X, use adb_firmware_probe instead when you need Y'. The opt-in identifier note is a useful conditional but is a privacy rule, not a when-to-use rule.

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 usefully discloses that the artifact is written to a local file path rather than returned inline, but omits important behavior: bugreport capture is long-running (minutes), produces a large zip, may require specific permissions/root, and may affect device responsiveness. These omissions matter for a heavyweight operation.

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, zero filler, with the resource and its scope front-loaded and the return artifact stated second. Every clause 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 one-parameter tool with no output schema, the description covers what it produces and where it lands, which is adequate. However, given no annotations and the fact this is an expensive, long-duration capture, the absence of any runtime, size, or permission expectations leaves an agent underprepared to call it well.

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

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

There is a single 'device' parameter with 100% schema description coverage, so the schema already documents it as a device serial. The description adds nothing about the parameter, such as whether omitting the optional device falls back to a default or single connected device. Baseline 3 applies when the schema does the work.

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

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

States a specific verb ('Capture') and resource ('full bug report zip') and enumerates the contents (device state, logs, dumpsys, system info), which distinguishes it from point tools like adb_logcat or adb_dumpsys. It does not explicitly name those siblings as alternatives, so the differentiation is implied rather than stated.

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

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

Usage is only implied by the word 'full' – an agent can infer this is the comprehensive diagnostic snapshot rather than a targeted log/dumpsys call. There is no explicit when-to-use, when-not-to-use, or named alternative, so the agent must reason from the sibling list.

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

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

No annotations are provided, so the description carries the full behavioral burden. It reveals the build variant (debug) and that it targets a connected device, but says nothing about whether an existing installed app is replaced or its data cleared, whether the build runs offline, what permissions or gradle state are required, or what the result reports on build failure versus install failure.

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

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

A single front-loaded sentence with no filler, stating the action and its scope. It is lean, but the brevity is partly the cause of the missing behavioral detail rather than a model of tightness.

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 three-parameter convenience tool with no output schema and no annotations, the description omits the two things an agent most needs: what the call returns (build output, APK path, install status) and the side effects of reinstalling over an existing app. Adequate but clearly incomplete.

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

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

Schema description coverage is 100%, so projectPath, device serial, and the timeout range are already fully documented in the schema. The description adds no parameter-level meaning beyond that baseline.

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

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

The description states a concrete compound verb+resource: build a debug APK and install it on the connected device. An agent can distinguish it from adb_install (install only) and adb_gradle (arbitrary gradle task) without opening a schema, though neither sibling is named explicitly.

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

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

The parenthetical '(convenience wrapper)' implies this bundles build+install for the common single-device debug flow, which is weak when-to-use guidance. It does not say when to prefer adb_gradle plus adb_install separately, nor what prerequisites exist (connected device, gradle wrapper present).

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

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

No annotations exist, so the description carries the full burden. "Dump" implies a read-only operation but that is never stated, and nothing is said about required privileges (e.g. root), whether this works on all devices/Android versions, or roughly what the dump contains or how large it is.

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, purpose first, use cases second – no waste or filler. The use-case list is slightly generic but still front-loads the key 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?

For a simple single-parameter read tool with no output schema, the definition conveys the domain (carrier config, APNs) adequately. It stops short of describing the returned structure or preconditions, which would matter for an agent trying to interpret or act on the output.

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 one parameter at 100% schema description coverage, the schema already documents the optional "device" serial, and the description adds no further meaning such as default-target behavior when device is omitted. Baseline 3 applies when the schema does the heavy lifting.

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

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

"Dump carrier configuration values" names a specific verb (dump) and resource (carrier configuration), so the agent knows exactly what is retrieved. It does not, however, distinguish this from nearby siblings such as adb_telephony, adb_baseband_info, or adb_settings_get, which could plausibly return overlapping data.

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 second sentence lists motivating scenarios (verifying carrier settings, detecting anomalies, inspecting APNs), which implies when to reach for the tool. There is no explicit when-not guidance and no named alternative for overlapping needs like telephony or baseband inspection.

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 behavioral burden and says almost nothing: not whether truncation occurs by default, what happens with binary files, how errors surface, or whether the device parameter is required when multiple devices are attached. The only behavioral hint is the implicit assumption that the target is a text file.

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

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

A single front-loaded sentence with no wasted words. It is arguably too spare rather than bloated, and offers no structural aids, but nothing in it is redundant.

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

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

For a three-parameter file-read tool with no annotations and no output schema, the agent is left unaware of return shape, truncation defaults, or error behavior. The definition is technically correct but too thin to call the tool confidently in ambiguous cases.

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

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

Schema description coverage is 100%, so path, device, and maxLines (with its 1-10000 bounds) are already fully documented in the schema. The description adds no additional meaning about parameter interaction, such as how maxLines truncation affects output or what device resolution happens when device is omitted.

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

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

States a specific verb and resource ("Read a text file from the device"), which is clearly distinct from siblings like adb_ls, adb_file_stat, or adb_pull. The word "text" usefully narrows the scope, though no sibling is named to reinforce the distinction.

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

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

There is no guidance on when to use this versus adb_pull (copy to host), adb_grep (search contents), or adb_file_stat (metadata), and no mention of prerequisites such as read permissions or root. An agent must infer applicability from the tool name alone.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It discloses the data source ('parses structured data from dumpsys') and implies a read-only extraction, but says nothing about failure modes (Wi-Fi-only device, no SIM, airplane mode), permissions, or whether the result is a single cell or a list — all material for a telephony probe.

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 compact sentences, front-loaded with the field list, with no filler. The phrase 'detailed cell identity information' is slightly redundant with the field enumeration that follows, but nothing else wastes space.

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

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

With no output schema, the field enumeration effectively serves as a return-value description, which is a genuine strength. The remaining gap is environmental preconditions and the list-vs-scalar shape of the result, which an agent would need before relying on it.

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

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

There is a single parameter ('device') with 100% schema description coverage, so the schema already documents it. The description adds no meaning about the parameter, such as whether the device is optional or what happens when it is omitted; baseline 3 is appropriate when the schema does the work.

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

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

The description opens with a specific verb and resource ('Extract detailed cell identity information') and enumerates the exact data points returned (CID, TAC/LAC, EARFCN/ARFCN, PCI, PLMN, network type), so an agent knows precisely what this produces. It does not, however, distinguish itself from close telephony siblings such as adb_signal_detail, adb_neighboring_cells, or adb_telephony.

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

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

Usage is only implied by the closing clause 'for cellular network analysis', which signals the general context. There is no explicit when-to-use statement, no prerequisites (e.g. active SIM, cellular-capable device), and no pointer to the sibling tools that handle signal strength or neighbor measurements instead.

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 supplied, so the description carries the full burden. It usefully discloses the five checks performed and that results are structured pass/fail, but it omits whether the tool waits/retries for boot, what its timeout behavior is, and whether any check mutates device state (e.g., unlocking the screen).

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 the purpose and followed by the concrete checks; every phrase carries information. The final sentence about structured pass/fail results is justified because no output schema exists.

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 single-optional-parameter, no-annotation, no-output-schema tool, the description is nearly sufficient: it names the checks and the return shape. Remaining gaps are failure granularity (does it report which check failed?) and timing/blocking semantics, which matter for a CI gate but are secondary.

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

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

Schema coverage is 100% and there is only one optional parameter ('device': Device serial), so the baseline of 3 applies. The description adds no meaning about what happens when 'device' is omitted (default device? error? first connected?), which is the one genuinely useful semantic it could have supplied.

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

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

States a specific verb and resource ('Comprehensive CI readiness check') and enumerates the five conditions verified (online, booted, package manager, screen unlocked, network), so the agent knows exactly what the tool inspects. It does not, however, distinguish itself from close siblings such as adb_health_check or adb_ci_wait_boot, leaving overlap ambiguous.

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 'CI' framing implies the intended context (pre-flight before running tests) but there is no explicit when-to-use statement, no exclusions, and no pointer to the sibling checks that overlap with it. An agent must infer the routing decision from the name alone.

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

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

With no annotations, the description carries the full burden. It usefully discloses that results are captured and returned as 'structured pass/fail output', but omits key behavior for a test runner: whether it blocks until completion (only implied by the timeout param), what happens on device disconnect or runner crash, and whether the test package must already be installed.

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 the action and mechanism, followed by the return-value note. Nothing is repeated or wasted.

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

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

For a six-parameter execution tool with no annotations and no output schema, the description covers what it does and roughly what it returns but leaves operational gaps: prerequisites, blocking semantics, and failure reporting. Adequate minimum viable, not complete.

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

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

Schema description coverage is 100%, so every parameter (device, runner, timeout, testClass, testMethod, testPackage) is already documented with defaults and ranges. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Run') plus resource ('Android instrumented tests (androidTest)') and even names the underlying mechanism ('am instrument'), which separates it from Gradle-driven siblings like adb_gradle or adb_build_and_install. It does not explicitly name a competing sibling (adb_farm_run, adb_multi_test, adb_test_session_start), so it stops short of a 5.

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

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

The mechanism mention implies context: use this to execute already-built instrumented tests on a connected device rather than rebuilding. But there is no explicit when-to-use/when-not-to-use statement and no mention of prerequisites (test APK installed, device booted) or alternatives such as adb_farm_run or adb_test_session_start for multi-device/stepwise flows.

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 supplied, so the description carries the full behavioral burden. It usefully discloses the polling mechanism and the two conditions being awaited (boot_completed and launcher ready), but says nothing about what happens on timeout, whether the call blocks until failure, or what is returned on success versus timeout — a meaningful gap for a wait 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?

Three short sentences, front-loaded with the primary action and followed by the mechanism and the target scenario; nothing is redundant. It stops short of the top mark only because a sentence on timeout/return behavior would have been a better use of the space than the somewhat promotional 'Essential for CI pipelines.'

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

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

For a two-optional-parameter, no-annotation, no-output-schema tool, the description covers purpose and mechanism adequately. What is missing is failure semantics on timeout and the expected result shape, both of which the agent needs because no structured field supplies them.

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

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

Schema coverage is 100%, with 'device' and 'timeoutSeconds' (including default 120 and 10–300 bounds) already documented in the schema, so the baseline of 3 applies. The description adds no extra meaning about device selection (e.g., behavior when omitted) or how the timeout interacts with the two polling conditions.

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

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

States a specific verb and resource ('Wait for a device or emulator to fully boot') and adds the mechanism (polls sys.boot_completed, waits for launcher readiness), which lets an agent understand exactly what state change is being observed. It does not, however, distinguish itself from nearby siblings such as adb_ci_device_ready, adb_device_state, or adb_wait_stable, so an agent still has to infer which readiness check applies.

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?

'Essential for CI pipelines' gives a clear usage context but no explicit when-to-use/when-not or named alternative among the several readiness siblings. The agent gets a hint about the scenario, not a decision rule.

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 and does most of it well: it flags irreversibility, enumerates what is wiped (data, cache, databases, shared preferences, login state), and documents the confirm gate. Gaps remain on side effects such as whether the app is force-stopped or runtime permissions revoked, and how the device parameter is resolved when omitted.

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

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

Front-loaded with the destructive warning and what gets destroyed, then the safety gate — a good order with almost no waste. The 'AP5 fix:' tag is internal jargon that costs a few tokens without informing the agent.

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, annotation-free mutation with three params and no output schema, the description covers the essentials: destructiveness, scope of loss, and the confirmation requirement. It falls short only on device targeting and post-clear app state.

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

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

Schema coverage is 100%, so the schema already explains all three parameters including the confirm-equals-packageName rule. The description only restates the confirm requirement, adding emphasis rather than new semantics, which matches the baseline 3.

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

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

States a specific verb and resource ('Clear all data for a package') and anchors it to a familiar operation ('equivalent to clearing storage in settings'), which cleanly separates it from siblings like adb_uninstall, adb_force_stop, or adb_rm.

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 settings analogy implies the scenario (resetting an app to first-run state), but there is no explicit when-to-use/when-not guidance and no mention of the obvious alternatives such as uninstall/reinstall or force-stop for less drastic resets.

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 behavioral burden, and it does disclose the Android 10+ requirement plus a possible foreground requirement on Android 12+. It omits permission prompts, overwrite behavior, failure modes, and the return/format semantics for read mode.

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

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

It is three short sentences with no filler, front-loading the core purpose and then adding mode and compatibility details. Every sentence contributes 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?

For a simple three-parameter tool with complete schema descriptions and no output schema, the description covers purpose and platform constraints adequately. It leaves minor gaps around what read mode returns and how write failures surface.

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

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

Schema description coverage is 100%, with action, text, and device all documented, including that text is required for write. The description adds only a restatement of read/write behavior and no additional parameter constraints or formats, so the baseline 3 applies.

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

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

The opening sentence gives a specific verb pair and resource: read/write the device clipboard, and the second sentence disambiguates the two modes. No sibling tool is explicitly named or contrasted, such as adb_input_text, so it stops short of a 5.

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

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

The action enum and mode explanation make the basic use case clear, and the Android 10+/foreground constraint helps the agent anticipate conditions. However, it gives no explicit when-to-use versus alternatives or when-not guidance, so usage is mostly implied.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It usefully adds the pairing/TCP/IP prerequisite, but says nothing about connection timeout, whether an existing connection is replaced, or whether the tool blocks until the device is reachable — all of which matter for a stateful connect operation.

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 with the action front-loaded and the prerequisite second. Nothing is redundant and nothing could be trimmed without losing 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?

The tool is simple (one required parameter, no nesting), and the description covers what it does and the precondition. With no output schema and no annotations, it leaves the return value and failure behavior undocumented, which an agent needs to chain this call 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 100% and the single 'host' parameter already documents the IP:port format with two concrete examples and a strict pattern. The description adds no syntax or format detail beyond that, so the baseline of 3 applies.

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

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

States a specific verb and transport ('Connect to a device over WiFi/TCP'), which is clearly distinct from siblings like adb_pair, adb_tcpip, adb_disconnect and adb_network_auto_connect. It does not name those siblings explicitly, so the agent must infer the boundary, but the resource and mode are 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?

'Device must be paired first or have TCP/IP enabled' gives a concrete precondition that implicitly routes the agent to adb_pair or adb_tcpip when unmet. It stops short of naming those alternatives or saying what to do when connection fails, so it is strong context rather than full when/when-not guidance.

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

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

With no annotations, the description carries the full burden. It discloses the root prerequisite and the paths read, plus that only the most recent entries are returned. It does not say whether the tool attempts to acquire root itself, how it fails on an unrooted device, or the format of the returned traces — meaningful gaps for an unannotated 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?

Three short sentences, each earning its place: what is read, the root prerequisite, and the recency/shape of the result. Front-loaded with the resource and free of filler.

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

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

For a 3-parameter read tool with no output schema and no annotations, the description covers the essentials: data source, permission requirement, and result recency. The remaining gap — failure behavior without root and the structure of returned trace text — is modest but real.

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

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

Schema description coverage is 100% and the enum on "type" plus the maxEntries bounds are already fully documented in the schema. The description's phrase "most recent entries" loosely reinforces maxEntries but adds no syntax, format, or per-type behavior beyond what the schema states.

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?

Uses a specific verb ("Read") with two concrete resources (ANR traces and tombstone crash dumps) and even expands the ANR acronym, so the agent knows exactly what data this yields. It does not, however, differentiate itself from nearby siblings such as adb_logcat_crash, adb_bugreport, or adb_dumpsys, which an agent could reasonably confuse it with.

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

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

Usage is only implied by the resource type: reach for this when diagnosing ANRs or native crashes. The description states a hard prerequisite (root access for /data/anr/ and /data/tombstones/), which is genuinely useful context, but it never says when to prefer this over adb_logcat_crash or adb_bugreport, nor what to do if the device is not rooted.

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 burden alone. It does say exactly what is retrieved (focused activity plus the window stack), which is the key behavioral trait for a read-only diagnostic query, but it says nothing about failure modes (no device connected, ambiguous device when omitted), required permissions, or whether the output is truncated.

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 short, front-loaded sentence with zero filler; the core resource is stated immediately. It is a bit thin rather than bloated, which is a completeness issue rather than a conciseness flaw.

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

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

With no annotations and no output schema, the description is the only source of return-shape information, and it only gestures at 'window stack' without saying what structure or fields come back. For a simple one-parameter read tool this is minimally adequate but leaves real gaps.

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

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

There is a single optional parameter (device) and the schema already documents it at 100% coverage, so the baseline of 3 applies. The description adds no meaning beyond the schema, e.g. what happens when device is omitted and multiple devices are attached.

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

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

The description gives a specific verb ("Get") and a specific resource ("currently focused activity and window stack"), which is concrete enough to distinguish it from generic siblings like adb_shell or adb_dumpsys. It stops short of naming the closest alternatives (adb_ui_dump, adb_screen_state, adb_top), so an agent still has to infer the boundary.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of the sibling tools that report overlapping UI state (adb_ui_dump, adb_ui_find, adb_screen_state, adb_dumpsys). The agent must guess whether this is the right tool for 'what screen am I on' questions.

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 supplied, the description carries the full burden. It implies a read-only operation and names example fields, but it does not explain behavior when multiple or no devices are connected, nor does it describe response format or edge cases.

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 definition is a single front-loaded sentence with no wasted wording. The 'etc.' is slightly vague, but overall the size is appropriate for a simple information-retrieval tool.

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 one-parameter read tool with no output schema and no annotations, the description is minimally adequate. It explains the kind of data returned but leaves out device-selection behavior and sibling differentiation that would help an agent call it confidently.

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 one optional parameter with 100% schema description coverage, so the schema already fully documents device serial selection. The description adds only the phrase 'connected device' and no additional 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 states a specific verb and resource ('Get detailed properties for a connected device') and gives examples of returned fields. It is clear what the tool does, but it does not explicitly distinguish itself from siblings like adb_devices, adb_getprop, or adb_device_state.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as adb_devices for listing devices or adb_getprop for individual properties. Usage is only weakly implied by 'connected device'.

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, and it only adds that each row includes state, model and product info. It does not state that the operation is read-only/safe, whether offline or unauthorized devices appear in the list ("connected" vs the reported "state" is ambiguous), or whether it triggers an adb server start.

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

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

A single front-loaded sentence with no filler; the scope ("all connected") and the returned fields are packed into one clause that survives skimming.

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

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

For a zero-parameter listing tool with no output schema, the description names the three fields an agent will need, which is close to sufficient. The remaining gap is device-state nuance (offline/unauthorized/emulator entries) that would affect how an agent branches after the call.

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

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

The tool takes no parameters, so the baseline is 4; there is nothing the description needs to disambiguate and it correctly focuses on the returned per-device fields instead.

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

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

States a specific verb and resource ("List all connected Android devices") plus what each entry carries (state, model, product info), which is more than a restatement of the name. It implies scope (all connected devices, not one) versus siblings like adb_device_info, but never names that sibling or states the distinction explicitly.

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

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

Usage is only implied — an agent can infer this is the discovery/enumeration step before per-device calls such as adb_device_info. There is no explicit guidance on when to prefer this over adb_device_info, adb_device_state, or adb_avd_list, and no mention of what to do when zero devices are returned.

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 supplied, so the description carries the full behavioral burden. "Get ... snapshot" establishes a read-only, point-in-time operation, but the description does not state prerequisites (e.g., an attached/authorized device), what happens when `device` is omitted and multiple devices are connected, or whether the call is fast/rate-limited. For a no-annotation read tool that is adequate but thin.

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, zero filler: the first front-loads the action and lists the returned components; the second gives the use case. Every clause earns its place and nothing is repeated from the schema.

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

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

With no output schema, the description usefully acts as a return-value sketch by enumerating the five state components, which is what an agent needs to know before deciding to call it. The remaining gap is only the no-annotation behavioral detail (device resolution, failure modes), which is minor for a read-only snapshot 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?

Only one parameter (`device`, "Device serial") with 100% schema description coverage, so the schema already documents it fully. The description adds no meaning about device selection or default behavior when the parameter is omitted, which is the one ambiguity that matters given required=0. Baseline 3 is appropriate.

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

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

"Get a combined device state snapshot in one call" gives a specific verb plus an aggregation resource, and the description enumerates exactly what is bundled: battery level/status, network connectivity, screen on/off, foreground activity, orientation. The phrase "in one call" implicitly distinguishes it from the granular siblings (adb_battery, adb_network, adb_screen_state, adb_current_activity, adb_orientation), though it never names them.

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?

"Useful as a pre-check before UI automation or as a quick device health summary" gives two concrete usage contexts, which is more than most definitions offer. It stops short of explicit routing advice such as "use adb_battery when you only need battery detail" or an exclusion against adb_health_check/adb_device_info, so the agent must infer the aggregation-vs-single-metric tradeoff.

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 supplied, so the description carries the full behavioral burden. It does disclose the most important trait — that with no host argument the operation fans out to ALL wireless devices — but it says nothing about prerequisites (wireless debugging enabled), failure behavior when no device is connected, or whether the operation is idempotent.

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

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

A single sentence with zero waste; the scope-of-effect clause is attached directly to the action so the agent reads the conditional behavior up front.

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 one-optional-parameter, no-output-schema tool, the definition covers the essentials: action, target format via schema, and the all-devices fallback. The remaining gap is lack of sibling disambiguation (notably adb_qemu_disconnect) and any error/permission expectations.

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

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

Schema description coverage is 100%, and the schema's own text ('Device IP:port to disconnect (omit for all)') already conveys the omit-for-all semantics. The description restates that fact rather than adding format detail, so the baseline 3 applies.

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

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

States a specific verb+resource ('Disconnect from a wireless device') plus the scope of effect when the target is omitted. An agent knows exactly what the tool does, though it does not distinguish itself from the similarly-named sibling adb_qemu_disconnect, which also disconnects but for QEMU guests.

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 clause 'or all wireless devices if no host specified' implicitly tells the agent that omitting the parameter is a valid, deliberately broad mode, which is useful. However, there is no explicit routing guidance: nothing points to adb_connect for the inverse operation, to adb_devices for discovering connected hosts, or explains how this differs from adb_qemu_disconnect.

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 supplied, so the description carries the full burden, and it discloses nothing about behavior beyond the bare verb. It does not state that dumpsys is read-only and safe, that output is typically very large and verbose, or how device selection works when multiple devices are connected; the result-handle plumbing is documented only in the schema.

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

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

Two short sentences, zero filler, with the core action first and the 'list' discovery tip second. Nothing is repeated and nothing could be cut without loss.

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 five-parameter tool with no annotations and no output schema, the description is thin: it explains service values but leaves args semantics, multi-device behavior, and the character of the output (verbose, read-only, potentially huge) entirely undiscussed.

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

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

Schema coverage is 100%, so the baseline is 3. The description does add one piece of meaning beyond the schema: that the literal value 'list' enumerates all available services rather than naming a service, which the schema only hints at by listing 'list' as an example.

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

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

States a specific verb and resource: run dumpsys for a given service. An agent can tell it is an arbitrary-service diagnostic passthrough, though the description never distinguishes it from sibling specializations like adb_battery, adb_telephony, or from adb_shell which could issue the same command.

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 only guidance is the discovery tip: pass 'list' to enumerate available services, which is genuinely useful for a first call. It gives no when-to-use/when-not guidance relative to adb_shell or the curated diagnostic tools, and no prerequisites such as whether a device serial is needed when several devices are attached.

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, and it does disclose one important behavior: it returns as soon as the process starts, not when the device is booted, which warns the agent that follow-up readiness checks are needed. It says nothing about resource consumption, whether the emulator persists in the background, what happens if an AVD is already running, or failure 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?

Two short sentences, purpose first, with the practically important return-timing caveat second. No filler or restated title text.

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

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

For a process-launching tool with no annotations and no output schema, the definition covers what it does and when it returns, but omits prerequisites (emulator SDK availability), pre-conditions (AVD already running), and the expected follow-up of waiting for boot. Adequate but with clear gaps for a state-changing launch 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 description coverage is 100%, so every parameter including the gpuMode enum and the coldBoot/headless flags is already documented in the schema with their underlying emulator flags. The description adds no additional parameter meaning, so the baseline of 3 applies.

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

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

States a specific verb and resource: "Launch an Android Virtual Device (AVD) emulator." This clearly separates it from adb_emulator_stop and adb_avd_list, though it does not explicitly distinguish it from the nearby adb_qemu_start / adb_ci_wait_boot 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?

There is no explicit when-to-use or when-not-to-use guidance. The description never says to call this before wait/boot-check tools or that a running emulator should be stopped first, leaving the agent to infer sequencing from sibling names alone.

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

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

With no annotations, the description carries full behavioral burden; it does disclose the underlying mechanism ('adb emu kill') and that the shutdown is graceful, which is real added context. It is silent on what happens to AVD state/snapshots, whether in-flight work is interrupted, and failure behavior when no emulator matches.

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 the action and followed by the implementation detail. No wasted wording, though the second sentence could have been spent on differentiation instead of mechanism alone.

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

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

For a zero-required-parameter, fully documented tool with no output schema, this is nearly complete; the agent knows what it does and how. The missing piece is disambiguation from other stop/restart siblings in a very large tool set.

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

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

Schema description coverage is 100%, so both optional parameters (device, avdName) and their alternatives are already documented in the schema. The description adds no additional meaning about how the parameters interact or what happens when both are given.

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

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

States a specific verb and resource: 'Stop a running emulator,' which tells an agent exactly what the tool does. It does not distinguish itself from nearby siblings such as adb_qemu_stop or adb_reboot, so the agent must infer which stop mechanism applies.

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

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

There is no explicit guidance on when to use this instead of adb_qemu_stop, adb_reboot, or adb_force_stop, nor on preconditions (emulator must be running, one vs. multiple emulators). The only routing hint — that omitting avdName lists running emulators — lives in the schema, not the description.

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 behavioral burden; it does disclose the key trait that this writes files to the local filesystem and retrieves all splits rather than just the base APK. However, it says nothing about overwrite behavior for existing files, required permissions, or what happens if the package has no splits or is not installed.

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 compact sentences with the action stated first and the rationale second; nothing is redundant. The second sentence is somewhat generic but still earns its place by orienting the agent toward use cases.

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 three-parameter tool with no annotations and no output schema, the definition is adequate but thin: it never indicates what the tool returns (file paths? count?) or how partial failures are reported, which an agent needs to chain calls 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 description coverage is 100%, so device, outputDir, and packageName are already documented, including the temp-dir default. The description reinforces 'all APK splits' semantics for packageName but adds no format or constraint detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb and resource: pulling all APK splits for a named package from the device to a local directory. This is clearly distinguishable from adb_list_splits or adb_pull in intent, though the description never names those siblings to reinforce the distinction.

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

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

The second sentence lists intended use cases (analysis, backup, transfer) which implies when to reach for it, but there is no explicit when-not guidance and no pointer to alternatives such as adb_list_splits for enumeration-only or adb_pull for single-file retrieval.

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 must carry the behavioral burden. 'List' implies a read-only operation against Firebase Test Lab, but the description does not disclose authentication requirements, whether results are live or cached, pagination, or the returned shape.

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, with the core listing capability front-loaded and the planning use case immediately after. There is no redundant or wasted wording.

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 one-parameter list tool, the description covers purpose and a practical use case. However, with no annotations and no output schema, it leaves out return format, authentication expectations, and result granularity, which would help an agent call it with confidence.

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 optional 'type' parameter has 100% schema description coverage and an enum, so the schema already explains it. The description mentions models and API levels but adds no format, default, or enum guidance beyond what the schema provides; baseline 3 applies.

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

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

The description names a specific verb ('List') and resource ('available device models and API levels on Firebase Test Lab'), making the scope clear. It implicitly separates planning from running tests but does not explicitly name sibling alternatives like adb_farm_run or adb_devices.

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

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

It gives a clear use case ('Use to plan test matrices'), which tells the agent when this tool is appropriate. It lacks explicit exclusions or guidance on when to use adb_farm_run/adb_farm_results instead, so it falls short of a 5.

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

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

No annotations are supplied, so the description carries the burden. 'Retrieve' and 'Shows' imply a non-mutating read, and the description usefully discloses the return contents (status, device results, links). It does not confirm read-only/no-side-effects or state what happens when no matrices exist.

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

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

A single well-formed sentence, front-loaded with the core action and followed by the return contents. Nothing extraneous, though it is on the terse side for a tool with no annotations.

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?

Low complexity, one optional parameter, no output schema, and the description already characterizes the returned payload. Only gap is the absence of any behavioral/permission context, which matters slightly since annotations are absent entirely.

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 optional parameter with 100% schema coverage; the schema already explains matrixId and that omitting it lists recent matrices. The description adds no format, ID syntax, or fallback behavior beyond the schema, so baseline 3 applies.

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

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

States a specific verb (Retrieve) and resource (results from a Firebase Test Lab run / test matrix ID) and enumerates the payload (pass/fail, device results, log and artifact links). It is clearly distinct from adb_farm_run (which produces runs) though it never names a sibling explicitly.

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

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

Implies usage via 'most recent run' vs 'specific test matrix ID', and the schema cross-references adb_farm_run output. However it never states when to prefer this over adb_farm_matrix or the adb_result_* family, so routing between the farm and result tools is left to inference.

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

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

With no annotations, the description must carry the behavioral load. It correctly discloses that this is a remote cloud-lab execution that uploads artifacts and requires authenticated gcloud, which is valuable context. It omits whether the call blocks until the matrix finishes, whether it returns a run ID for later retrieval via adb_farm_results/adb_farm_matrix, and what happens to uploaded APKs.

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 short sentences, front-loaded with the action and then the mechanism and prerequisite; no filler or restatement of the tool name. It could be marginally tighter by folding the prerequisite into the first sentence, but 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 7-parameter remote-execution tool with no annotations and no output schema, the definition covers what is run and what credentials are needed but leaves the result lifecycle underspecified. An agent cannot tell from this description how to fetch results afterward or how long a run may take, both of which matter for a cloud matrix job.

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

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

Schema description coverage is 100%, so every parameter including devices syntax, timeout vs execTimeoutMs distinction, and testTargets is already documented in the schema. The description only restates that device models and API levels are configurable, adding no meaning beyond the structured fields, so the baseline of 3 applies.

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

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

"Run tests on Firebase Test Lab" names a specific verb and resource, and the follow-up sentence clarifies the mechanism (upload app APK + test APK, execute instrumented tests across device models and API levels). This distinguishes it from local-execution siblings like adb_shell or adb_ci_run_tests, though it never names an alternative explicitly.

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

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

The description gives a real prerequisite (gcloud CLI authenticated against a Firebase project), which is the main barrier to using this tool. It does not say when to prefer it over sibling runners such as adb_ci_run_tests, adb_multi_test, or adb_test_session_start, so selection between them is left to inference.

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

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

With no annotations supplied, the description carries the full disclosure burden. It does state "Read-only operation" and that file size is reported alongside the hash, which is genuinely useful. It omits what happens for missing/unreadable files, the overhead of hashing large files, or what the root flag changes operationally.

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 short sentences, front-loaded with the operation and followed by use cases and the read-only/side-output facts. The phrase "Critical for..." is mildly promotional but still conveys intent, so only minor trimming is possible.

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

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

For a 4-parameter, 100%-covered schema with no output schema, the description covers the operation, safety profile, and return content (hash plus file size), which is what an agent needs to invoke it. Only error behavior and the operational effect of the root flag remain unstated.

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

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

Schema description coverage is 100%, so all four parameters (path, root, device, algorithm) are already documented, establishing a baseline of 3. The description adds no parameter-level meaning beyond the schema and even implies SHA-256 only, while the schema allows sha1/md5 selection.

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

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

The description names a specific verb and resource ("Compute SHA-256 hash of a file on the device") and is easily separable from siblings like adb_file_stat or adb_cat. It is slightly narrower than the actual tool, since the schema's algorithm enum also permits sha1 and md5, but the core purpose is unmistakable.

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

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

It gives use-case contexts (firmware integrity verification, tamper detection, cross-device comparison), which implies when to reach for it. However, it never explicitly says when to use adb_file_stat or adb_cat instead, nor does it state prerequisites or exclusions, so the agent must infer the routing.

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

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

No annotations exist, so the description carries the full behavioral burden and does meaningful work: it discloses a safety guard ('refuses at depth ≤ 2 from root') and a silent-failure filesystem caveat (/sdcard, sdcardfs/FUSE). It doesn't describe the failure/return shape on permission errors or that root is typically required, leaving some behavioral gaps.

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

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

Three sentences, front-loaded with the core action, then the mode constraint, then the recursive guard and the filesystem caveat. The mode sentence duplicates the schema pattern/examples and is the one line that doesn't fully earn 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 mutating 5-parameter tool with no annotations and no output schema, the description covers the format constraint, recursive safety semantics, and the environment caveat where the operation silently does nothing. Remaining gaps — root requirement and error behavior — are either in the schema or minor for a chmod 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 100%, so the baseline is 3; the description earns an extra point by supplying concrete octal examples and, more importantly, explaining that `recursive` triggers a depth-based refusal at depth ≤ 2 from root — a constraint the schema only hints at with 'Depth-protected.'

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

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

The description opens with a specific verb+resource ('Change file permissions on the device') that clearly distinguishes it from siblings like adb_file_chown, adb_file_stat, and adb_file_touch. It never names an alternative explicitly, but the operation 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?

It implicitly tells the agent when NOT to bother: on /sdcard the chmod is a no-op because sdcardfs/FUSE ignores Unix permissions. It also warns that recursive mode is depth-protected. It stops short of naming alternatives (e.g., adb_file_chown for ownership) or stating the root prerequisite, which the schema carries instead.

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 carries the full burden and does substantial work: root requirement, a concrete recursive guard threshold, and a filesystem caveat where the operation silently does nothing. It does not say what is returned or whether a refusal raises an error versus a partial success, which is the main remaining gap for a mutation tool.

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

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

Four short sentences, each carrying a distinct fact (purpose, prerequisite, input formats, guard rail, caveat), with the purpose front-loaded and zero filler.

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

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

For a mutating file operation with no annotations and no output schema, the description covers prerequisites, accepted input forms, safety limits, and known no-op filesystems. Only failure/return semantics remain unaddressed.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds genuine meaning beyond it by confirming both numeric and symbolic owner formats are accepted and by spelling out the depth-protection rule that the schema only labels as "Depth-protected." The device parameter is left entirely to 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?

"Change file ownership on the device" is a specific verb+resource pair, and the owner-format detail makes it clearly the chown counterpart to adb_file_chmod. It never names adb_file_chmod explicitly, so sibling differentiation is implied by resource semantics rather than stated.

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

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

It states the key precondition ("Requires root") and two conditions under which the call is pointless or blocked (sdcardfs/FAT32, depth ≤ 2 in recursive mode). It stops short of pointing to adb_file_chmod or adb_shell as the alternative when root is unavailable.

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 carries the full behavioral burden, and it does disclose two non-obvious traits: a pre-flight free-space check and a post-copy size verification. It still omits critical mutation semantics — whether an existing destination is overwritten, what happens to a partial copy on failure, and whether verification failure raises an error or merely reports it.

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 short sentences, front-loaded with the core action, then the safety behaviors, then the recursive note. The final sentence is largely redundant with the `recursive` schema property, but overall there is little 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 mutation tool with no annotations and no output schema, the description should say more about results and failure modes — particularly since it advertises post-copy verification whose outcome an agent would need to interpret. Overwrite behavior and the shape of the verification result are the notable gaps.

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

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

Schema description coverage is 100%, so all five parameters (including `root` for protected paths and `recursive`) are already documented in the schema. The description only echoes the `-r` mapping for recursion and adds no meaning beyond that, so the baseline of 3 applies.

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

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

The description gives a specific verb and resource ('Copy a file or directory on the device') and mentions recursive directory handling. However, in a sibling set containing adb_push, adb_pull, and adb_file_move, it never states how this on-device copy differs from those, leaving the agent to infer the distinction.

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

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

The only usage-like statement is 'For recursive directory copies, use -r flag,' which merely restates the `recursive` parameter. There is no guidance on when to prefer this over adb_push (host-to-device), adb_pull, or adb_file_move, and no stated preconditions such as root requirements for protected paths.

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, and 'Report' plus the attribute list implies a safe read-only inspection. However, it never states that it is non-mutating, whether elevated permissions are needed for system paths, or what happens on unsupported/inaccessible paths, so meaningful behavioral gaps remain.

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

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

Two sentences: the first front-loads the purpose and the return contents, the second the motivation. The long field enumeration is dense but each item conveys a distinct capability the caller may depend on.

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

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

There is no output schema, so the description usefully compensates by listing the returned fields, which is what an agent needs to decide whether this tool answers its question. Only error/permission failure behavior is left unexplained for a 3-parameter inspection 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 description coverage is 100%, so path, root, and device are all documented in the schema itself. The description adds no extra meaning about path formats (e.g., device-absolute paths) or when to set root, so the baseline of 3 applies.

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

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

The description names a specific verb and resource ('Report filesystem details for any path') and then enumerates the reported attributes (fs type, mount point, capacity, SELinux context, etc.), which makes it unmistakable against siblings like adb_file_stat or adb_ls. It stops short of explicitly naming the nearest sibling to contrast with, so it is clear but not fully differentiated.

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

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

It gives a concrete usage context: 'Essential for understanding what operations are possible before attempting them', telling the agent to call this as a pre-flight check before write/mutation operations. It provides no exclusions or named alternatives, so it lands at clear-context-without-routing.

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

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

With no annotations, the description carries the full burden and does substantial work: it flags destructiveness, the source-depth protection rule (depth ≤ 1 from root), pre-check symlink resolution, and the copy+delete fallback with a performance warning for cross-filesystem moves. It still omits whether an existing destination is overwritten and whether root is required for protected paths.

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

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

Four dense sentences, front-loaded with the core action, and each subsequent sentence adds a distinct hazard or behavior. Slight density in the depth-protection clause costs it the top mark, but there is no filler.

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

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

For a mutation tool with no annotations and no output schema, the description covers the important failure and performance characteristics an agent needs before calling it. The remaining gaps — destination overwrite semantics and explicit root prerequisite — are minor but real.

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

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

Schema coverage is 100%, so source, destination, device and root are already documented, and the baseline is 3. The description adds indirect meaning (system paths tie to the root flag, symlink resolution affects how source is interpreted), but it never explicitly explains the root or device parameters.

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

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

States a specific verb pair (move/rename) and resource (file/directory on the device), which cleanly separates it from sibling tools like adb_file_copy, adb_rm, adb_push and adb_pull. The rename capability is called out explicitly, so an agent knows this is not just a path-to-path transfer.

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

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

Usage is implied rather than stated: an agent infers 'use this to relocate or rename a path' but no alternative is named and no explicit when-not guidance is given. The source-depth refusal rule is operation-time behavior, not selection guidance, though it does hint at when the call will fail.

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 supplied, so the description carries the full burden. It does disclose real behavior: sed-based in-place editing with escaping, global vs first-only, line targeting, an optional .bak backup, and a returned match count. It stays silent on what happens on zero matches, whether a missing file errors, permission failures, and whether edits are atomic, which are material 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?

Three short sentences, front-loaded with the action and followed by capabilities. The sed-internals clause is useful for trust but borders on implementation trivia; nothing else is wasted.

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