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

With no annotations, the description does real work: it discloses the return shape ('effect', a plain sentence describing navigation/dialog/scroll/no-change, plus snapshot_id) and the observe toggle. It stops short of warning about irreversible side effects (clear wipes text, taps may trigger destructive flows) or timeout 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?

Front-loaded with the combined act+observe premise, then targeting, then return value, then the observe escape hatch — a logical order with little waste. The opening 'One human-shaped verb' is slightly rhetorical, and the dense parenthetical list of selector fields is a bit compressed.

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

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

Covers the essentials for a high-traffic interaction tool: what it does, how to target, what comes back, and the no-observe fast path. Gaps remain for the scroll/key-specific params (direction, duration_ms) and the wait_timeout that governs how long it blocks.

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

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

Schema description coverage is 0% across 9 params, so the description must compensate. It well documents `action`, the selector predicates (role, label_contains, semantic_key, text, resource_id) and `observe`, but leaves `value`, `direction`, `duration_ms`, and `wait_timeout` entirely unexplained.

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

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

States a concrete verb and effect: 'perform an interaction AND report what changed, in a single round trip,' then enumerates the action space (tap/long_click/set_text/.../key). It implicitly separates itself from the pure-inspect siblings (ui_snapshot, get_ui_tree) by saying no follow-up perceive call is needed.

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

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

Gives a clear condition for the alternate mode ('Set observe=false for tight loops where you will observe later yourself') and explains the two targeting routes (semantic selector vs x/y). It does not explicitly say when to prefer sibling tools like tap_element, input_text, or element_action, which leaves some routing ambiguity.

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 does disclose two important traits: arguments go straight to native adb (no host shell) and the command targets the selected device. But it says nothing about the destructive potential of arbitrary adb, whether output is validated or exit codes are surfaced, or what error conditions appear, which for an unannotated raw-command tool is a significant gap.

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

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

Two sentences, zero filler, and the core identity (raw escape hatch) plus the operative constraint (no host shell) are front-loaded before the routing advice. Nothing could be cut 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 output schema means return values need not be explained, and the description covers the tool's nature and target device. For a raw unvalidated command executor with three undocumented parameters and no annotations, though, it should warn about destructive scope and explain args construction to be genuinely 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 0%, so the description must explain args, timeout, and max_output_bytes. It adds nothing: no format or example for the args array, no note that timeout is in seconds with a 30s default, no mention that max_output_bytes truncates output at 64KB. The one nod — that typed tools handle timeouts better — is indirect and doesn't define the parameter.

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 combination: a raw ADB command escape hatch targeting the selected device, with concrete examples (bugreport, jdwp, shell am instrument). It also implicitly distinguishes itself from the typed siblings, though it does not name the closest overlaps such as shell_execute or root_shell.

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?

"Prefer typed tools for timeouts and validation" implies this is a fallback for cases the typed tools don't cover, which is useful guidance. However, it never states the positive condition for choosing this over shell_execute, shell_batch, or root_shell, so the agent must infer where this tool sits among several similarly-scoped siblings.

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 add real behavioral content: it mutates device settings, snapshots exact original values before changing them, and restores them including absent keys, tied to the same device. It still leaves out whether elevated privileges/root are required, whether applied changes survive reboot, and what list returns, which matter for an unannotated 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?

Two tight sentences with no filler, front-loading the action set and then the save/restore guarantee. The second sentence is dense but every clause (BEFORE, including absent keys, same device) carries distinct information.

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

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

Return values need not be explained because an output schema exists, and the save/restore contract is covered. For a four-parameter, zero-schema-coverage tool with no annotations and many adjacent device-setting siblings, it is only minimally complete: action vocabulary, privilege requirements, and cross-tool selection are all absent.

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

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

Schema description coverage is 0%, so the description has to compensate, and it partially does by mapping profile_id to restore and connecting stay_awake/zero_animation to the saved values. It never states that apply/list/restore are the legal values of the otherwise un-enumerated action parameter, nor what the booleans do on list or restore.

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 three specific verbs (apply/list/restore) and a concrete resource (Agent speed profile), plus the mechanism (save original animation/stay-awake values, restore by profile_id). It does not, however, differentiate itself from the closely related sibling optimize_device_for_agent, which an agent could plausibly 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 implied rather than stated: the mention of 'restore ... by profile_id on the same device' signals that restore requires a prior apply on that device, and the save-before-change wording implies apply is the entry point. There is no explicit when-to-use versus when-not-to-use, and no guidance on choosing between actions or against optimize_device_for_agent.

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 one genuinely useful thing: disclosing that clear/uninstall remove user data, and that downgrade/test/permission behaviors are explicit opt-in switches. However, it says nothing about root/privilege requirements, what launch/stop do to running state, whether install replaces existing data, or side effects of enable/disable.

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 short and front-loads the action inventory, with no filler sentences. The dense slash-separated style sacrifices readability for brevity and forces the agent to parse a token stream rather than read structured statements.

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 9-parameter, no-annotation, multi-mode tool, the definition is thin: an output schema exists so return values need not be described, but action semantics, parameter roles, and privilege requirements are all missing. The action enumeration is the only substantive content.

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

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

Schema description coverage is 0% across 9 parameters, so the description must compensate. It partially does: 'apk_paths (base+splits)' maps to apk_paths, and 'explicit downgrade/test/permission switches' maps to allow_downgrade, allow_test, grant_permissions. But action (the primary discriminator), package, user_id, activity, and include_system are given no meaning at all.

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

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

The description names a specific resource (apps) and enumerates the concrete verbs it supports: list/info/paths/launch/stop/restart/clear/enable/disable/uninstall plus install/install_multiple. An agent can tell this is the app-lifecycle tool. It does not distinguish itself from siblings like manage_app, app_permissions, or deploy_and_verify_apk, which appear to overlap.

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 preconditions, and no routing to alternatives despite several overlapping siblings (manage_app, app_permissions, export_apks, deploy_and_verify_apk). The agent must infer action selection entirely from the slash-separated verb 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?

With no annotations provided, the description carries the full behavioral burden and does substantial work: it discloses that the app is stopped, that restore replaces the data and leaves the app stopped, that member paths and the manifest are validated, that a pre-restore backup is retained, and that UID/SELinux context is restored. It omits privilege requirements (root/shell), error/failure behavior, and whether a failed validation aborts before mutation, which matter for a destructive operation.

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

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

The purpose and output format are front-loaded in the first sentence, and every subsequent clause carries operational information with no filler. It is written in dense telegraphic fragments ('Stops app.', 'replaces data, leaves app stopped') that save tokens but slightly reduce readability.

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

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

For a mutating, side-effect-heavy tool with no annotations, the description covers the important behavioral surface: app stoppage, data replacement, pre-restore backup, and validation. An output schema exists so return values need no explanation, but the absence of any privilege/root requirement or user_id semantics leaves a gap given 0% schema coverage.

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

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

Schema description coverage is 0%, so the description must compensate for all five parameters. It implies the 'action' values (backup/restore), explains 'storage' as CE vs DE, and bounds 'package' to one app, but never enumerates the accepted action strings, gives no format for local_path beyond 'tar+SHA256 manifest', and never mentions user_id at all.

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 pair (backup/restore), a precise resource (one app's CE or DE private data), and an output format (tar + SHA256 manifest), so an agent can tell this apart from read-only siblings like inspect_app_data. It stops short of naming a sibling or stating an explicit contrast, so it is clear but not fully differentiating.

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?

'Backup/restore one app's ... data' establishes the use case, and 'Keystore/TEE/external storage excluded' states a when-not boundary for data coverage. It does not route the agent to an alternative when the target data falls outside that boundary (e.g., use file_transfer_root or inspect_app_data instead), so the alternatives half of the guidance is missing.

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 bears the full disclosure burden. It does add real value by stating that grant_runtime_all intersects declared permissions with the device dangerous-runtime list, reports failures individually, and does not silently enable special privileges — but it says nothing about revoke's reversibility, or whether root/elevated access is required for any 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 tight sentences with the capability statement front-loaded and the behavioral caveat following. The only weakness is unexplained jargon: 'grant_runtime_all' appears as if it were a known term, but the schema offers no enum to map it to.

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, zero-coverage, unannotated tool with multi-mode behavior, the description is too thin. It omits the action/mode value space, user scoping, permission string format, required access level, and whether revoke is destructive — an agent could easily call this incorrectly.

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

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

Schema description coverage is 0% across five parameters, and the description only obliquely touches 'permission' and a named appop. It never explains 'mode' (default allow), 'action' (default list), 'user_id', or the expected format of the permission string, so the parameters remain essentially undocumented.

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

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

States specific verbs and resource: inspect, grant, revoke permissions, plus setting a named appop. This clearly distinguishes it from siblings like app_action or system_settings, but the named mode/action values (grant_runtime_all) are never reconciled with the schema's generic 'action' field, leaving some ambiguity about what can actually be invoked.

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

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

The description implies the tool handles permission inspection, granting, revoking, and appop setting, but never says when to use this versus manage_app or app_action, nor which 'action' value selects which behavior. The one concrete condition given (grant_runtime_all intersects against the dangerous-runtime list) is behavioral detail rather than routing guidance.

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

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

With no annotations, the description bears the full burden of behavioral transparency. It explicitly details a crucial operational behavior: upon failure mid-workflow, the tool automatically halts and returns the UI tree of the current state, enabling error correction. This is vital context for a batch process.

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 structure is excellent, front-loading the core value proposition immediately. While the language is slightly marketing-oriented (e.g., '王牌去人机感工具'), the technical instructions are well-organized and highly focused.

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

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

Given the complexity of handling a nested array of diverse action types, the definition is exceptionally complete. It covers the 'what' (workflow execution), the 'when' (2-6 steps), and the 'if-then' (failure recovery mechanism), providing the agent with all necessary context.

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?

While the schema defines the structure, the description provides a functional specification for the complex 'steps' parameter. It lists 8 concrete action types (e.g., `launch`, `wait_for`, `root_cmd`) and provides examples of their required parameters, transforming the abstract schema into an executable blueprint.

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

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

The description clearly defines the purpose: executing sequential, multi-step mobile operations in a single function call (a workflow or pipeline). This sharply differentiates it from the many single-action sibling tools, such as `tap_element` or `input_text`.

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

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

It provides excellent usage guidelines by stating the specific condition under which the tool *must* be used: when the agent can predict 2 to 6 consecutive steps. This directs the agent away from calling multiple single-step tools.

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

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

With no annotations supplied, the description carries the behavioral burden and does disclose key behavior: it captures one frame, compares dimensions and changed-pixel metrics, and can optionally save current and diff outputs. It omits whether the operation is read-only, what permissions are required, and how threshold affects results, leaving meaningful 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?

The description is a single compact sentence-like statement that front-loads the core comparison behavior and follows with implementation details. Every clause adds useful information, and there is no redundant 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?

The presence of an output schema reduces the need to describe return values, and the description covers the main comparison workflow and optional file saves. However, for a five-parameter tool with zero schema description coverage, it should explain threshold and max_width to be fully self-contained.

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

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

Schema description coverage is 0%, so the description must compensate for five undocumented parameters. It implies baseline_path and the optional save_current_path/save_diff_path usage, but it does not explain max_width or threshold semantics, defaults, or valid ranges, leaving important parameters ambiguous.

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: a pixel regression check against a local baseline PNG/JPEG. It also clarifies that it captures one frame and compares dimensions, changed-pixel ratio, and bounds, which distinguishes it from generic screenshot tools. It does not explicitly contrast with the sibling screenshot_annotated, but the purpose is clear.

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

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

The description provides a usage context by saying it is useful for Canvas UI verification. However, it does not state when to choose this over related tools such as screenshot_annotated or ui_snapshot, nor does it describe exclusions or prerequisites.

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

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

With no annotations at all, the description carries the full load. It does disclose two genuinely useful behaviors: update/delete demand an explicit where clause, and where='1' means all rows (a destructive-footgun warning), plus that ROM/provider authorization still applies. However it says nothing about permission failures, whether calls are reversible, or concurrency, so the mutation risk profile remains only partially disclosed.

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

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

Two dense sentences with no filler, and the operation list is up front. The parenthetical about '1' meaning all rows interrupts the flow, and cramming two separate ideas (bindings, authorization caveat) into one sentence makes it slightly harder to parse.

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

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

An output schema exists, so return values needn't be explained. Given zero annotations and eleven undocumented parameters, the description is missing detail an agent would want: the meaning of root, user_id, max_output_bytes, and whether permissions must be pre-granted.

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

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

Schema coverage is 0% across 11 parameters, so the description must compensate. It explains three of the most important parameters: action maps to the chosen CRUD verb, where is the selection filter, values carries the typed payload implicitly. It adds no meaning for uri, projection, sort, arg, method, root, user_id, max_output_bytes, so it falls short of full coverage.

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

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

States a specific resource (Android ContentProvider) and enumerates the concrete operations (query/insert/update/delete/call/gettype) plus the key qualifier 'zero-UI' and 'typed bindings'. That distinguishes it from UI-driven siblings, though it never names which sibling (e.g. query_system_provider, sqlite_database) it competes 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?

Implies usage via 'zero-UI' (bypass the UI layer and hit the provider directly) and gives one hard precondition for update/delete. It does not say when to prefer this over query_system_provider, shared_preferences, or sqlite_database, so the agent must infer the choice from the URI scheme.

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 burden and discloses the important side effects: install uses -r -d (reinstall with downgrade), the target app is force-stopped and cold-started, and the global logcat buffer is retained. It does not cover permissions, adb/root prerequisites, or expected duration/failure modes, but the destructive footprint of the operation is made visible.

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 header line establishes scope up front, followed by a numbered list of the five automated steps. Each item adds information; only the decorative bracket styling is noise. It is slightly long but front-loaded and scannable.

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, multi-step orchestration tool with an output schema, the description explains the sequence, what gets killed, and what is aggregated back (crash stack, logcat, LSPosed module logs, UI tree). Missing only prerequisites and failure handling, which leaves a small gap given no annotations.

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 apk_path, target_package, log_keyword, wait_seconds, and launch_activity are already documented in the input schema. The description adds no parameter-specific meaning beyond that, which matches the baseline for fully covered schemas.

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

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

The description names a concrete multi-step workflow (install → capture logcat → force-stop/cold start → wait for hook → aggregate crash logs, module logs, UI tree) and titles it as an Android/LSPosed one-shot debug loop. That clearly separates it from single-purpose siblings such as adb_command, read_logcat_smart, and get_ui_tree.

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 establishes the context in which it is the right tool: an LSPosed/Android development iteration where the agent needs install-and-verify in one call, and it notes that for module debugging the target_package is the host app. It does not name explicit alternatives or state when not to use it (e.g. use adb_command for a plain install without 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?

With no annotations, the description carries the full burden, and it does disclose one genuine side effect: selection clears UI indices, plus the multi-device defaulting rule. It leaves out failure behavior (what connect returns on an unreachable host), whether pairing consumes the code, and permission/authorization needs, so the disclosure is partial rather than rich.

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

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

Two tight sentences with the operation list front-loaded and the caveats second; no filler. The telegraphic style ('List/select...') costs a little readability but every clause carries information.

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

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

An output schema exists so return values need no explanation, but for a stateful connection tool with four undocumented parameters and zero annotations, the description is too thin. It omits required-field expectations (nothing is required, so which params select which action), prerequisites for pairing, and post-connect 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 0% and all four parameters are undocumented in the schema, so the description must compensate. It only maps partially: 'host:port' hints at the address format and 'pair' implies the pairing code, but serial (the key selector for multi-device selection) and the enumerated action values are never explained.

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 concrete verbs (list/select/connect/disconnect/pair) against a concrete resource (ADB devices, host:port), so the agent knows this is the device-connection lifecycle tool rather than a control/status tool. It is clear enough to separate from siblings like device_control or get_device_status, though it never names those alternatives 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 conveys a situational hint ('no arbitrary default when multiple devices are attached') but gives no when-to-use vs when-not guidance and does not name any sibling or alternative path. Nothing says when to use pair versus connect, or what prerequisite state a device must be in for each.

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 two genuinely useful behavioral traits: ROM-dependent support and that reboot/network changes may disconnect ADB. It omits other important behavior — whether reboot/shutdown are irreversible, what permissions or root are needed (despite a 'root' parameter defaulting to true), and what the tool returns on unsupported actions.

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 capability list is front-loaded and dense with no filler, and the two trailing caveat sentences each add distinct risk information. The enumeration is an unstructured comma list rather than grouped by domain, which slightly hurts scanability but wastes no words.

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

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

An output schema exists, so return values need not be explained. For a 3-parameter, high-blast-radius control tool, though, the definition should say what 'value' expects per action and when root is required; those gaps remain after the (admittedly broad) action enumeration.

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

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

Schema description coverage is 0%, so the description must compensate, and it does partially by enumerating the accepted action values (including the underscore naming convention). However 'value' — whose meaning clearly changes per action (brightness level, volume level, screen density, etc.) — and 'root' are given no semantics anywhere, leaving the caller to infer formats.

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 enumerates the concrete resource domains the tool manipulates (wifi/bluetooth/mobile_data/airplane_mode, brightness, rotation, volume, reboot/shutdown, etc.), which makes the scope of 'device_control' tangible rather than tautological. It never differentiates itself from overlapping siblings such as system_settings, press_key, or adb_command, so an agent must guess 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 named alternative for overlapping tasks (e.g. system_settings for settings changes, root_shell for raw commands). 'ROM support varies' is a caveat about reliability, not a 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?

With no annotations, the description carries full burden; it does disclose two real behavioral traits — probes run inside a single ADB session (implying a bounded round-trip cost) and output_dir creates a persistent host-side report. It says nothing about device state requirements (root/ADB auth), expected runtime, or whether the operation is read-only and safe, which matters for a tool whose name could imply probing.

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 dense sentences with the kind enumeration and the operational notes front-loaded; no filler. It is telegraphic and relies on slash-separated lists, but every clause carries information.

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

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

An output schema exists, so return value explanation is rightly omitted, and the kind enumeration plus session/report notes cover the core invocation. Gaps remain around the `package` scope parameter, prerequisites such as root or connection state, and roughly how heavy each kind is, which an agent needs to choose this over lighter siblings.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: it enumerates the domain of the `kind` parameter (summary/memory/cpu/graphics/network/crashes/activity/services/power/bundle) and explains `output_dir` as a persistent host report directory. The `package` parameter, presumably scoping data to one app, is left completely unexplained.

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

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

States a concrete verb ("Collect") with an explicit enumeration of the diagnostic categories it can gather, so an agent knows this returns device health/diagnostic data rather than acting on the device. It does not differentiate itself from plausible siblings such as get_device_status, device_doctor, or read_logcat_smart, 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?

The phrase "optional persistent host report directory for regression evidence" implies a use case (capturing a snapshot you want to keep for later comparison), but there is no explicit when-to-use rule, no exclusions, and no named alternative among the many sibling diagnostic tools. Usage must be inferred from the kind 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 discloses the probe's targets and the side effect of initialize_u2 (starting a helper process and resetting a broken connection), but says nothing about whether the probe is read-only, whether it restarts ADB or disrupts active sessions, or how long a probe takes.

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 no filler, and the primary probe purpose leads. Sentence one is a terse noun list that reads more like a capability dump than prose, which slightly blunts front-loading, but nothing is wasted.

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

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

With an output schema present, return values need not be described, and the single parameter is explained. Still, 'dependency capabilities' is unspecified, and the description omits whether the U2 initialization can disturb existing sessions — meaningful context for a diagnostic tool that also mutates connection 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 0% beyond the bare boolean named initialize_u2, so the description must supply the meaning and it does: the flag starts the UIAutomator2 helper and resets a failed connection. Without that sentence the parameter would be opaque.

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 specific resources being probed (Root UID, ROM/SDK, installed command/dependency capabilities) and explains the flag's action (starts UIAutomator2 helper, resets a failed connection). It conflates two functions — capability probing and U2 initialization — and never distinguishes itself from the sibling device_diagnostics, so it stops short of 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 one implicit usage trigger: set initialize_u2 when a UIAutomator2 connection has failed. Beyond that, there is no statement of when to call device_doctor versus device_diagnostics, device_connection, or get_device_status, and no preconditions such as whether root is required for the probe.

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 safety burden well: it discloses atomic replacement, preservation of existing ownership/mode, backup-by-default, and optional compare-and-swap via SHA256 — all non-obvious behaviors that materially change how an agent should write. It stops short of flagging which actions are irreversible/destructive (delete, recursive delete, move) or whether elevated privilege is required, which matters given no destructiveHint.

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 telegraphic sentences, front-loaded with the operation list, then behavior guarantees, then the sibling routing rule. Every clause carries distinct information and there is no filler; the dense fragment style is appropriate for an 11-parameter dispatcher.

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 return shape is covered by the existing output schema, and core write semantics are stated, but for a tool this broad (11 params, mixed read/write/delete actions, zero annotations, zero schema descriptions) the definition leaves too much unresolved — notably max_bytes/recursive/destination semantics and which actions can destroy data. Adequate as a signpost, incomplete as a specification.

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

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

Schema description coverage is 0% across 11 parameters, so the description is the only source of parameter meaning, and it does supply the action vocabulary (no enum in schema), plus text-vs-base64 encoding, backup default, and expected_sha256 as a CAS guard. However, several parameters remain entirely unexplained: max_bytes (truncation limit?), recursive, destination, root, and mode's interaction with 'preserve existing ownership/mode'. It compensates partially, not fully.

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?

Opens with a specific noun phrase ('Root file manager') and enumerates the concrete operations (list/stat/read/write/append/hash/mkdir/chmod/copy/move/delete), so an agent knows exactly which file operations live here rather than elsewhere. It also names the boundary against the sibling 'file_transfer_root' for large files/trees, which no other sibling would supply.

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

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

Provides one explicit routing rule with its condition: 'Use transfer for large files/trees', which maps onto the sibling file_transfer_root. What is missing is guidance on prerequisites (e.g. that this is a root/privileged surface) and when to prefer other siblings such as app_data_archive or inspect_app_data for app-scoped 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 does supply real behavioral facts: persistent handles, bounded stdout/stderr, incremental byte offsets, PID-reuse checks, and timeout=0 semantics. It omits mutation consequences (what cancel/cleanup destroy), privilege/root behavior, and any pagination details, leaving meaningful gaps for a lifecycle tool.

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

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

The description is front-loaded with the action list and use cases, then adds behavioral constraints, with minimal wasted wording. The telegraphic style is dense but efficient for an 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?

An output schema exists, so return-value explanation is not required. For a complex 11-parameter multi-action tool with no annotations, the description covers lifecycle and some behavior but leaves privilege, mutation effects, and most parameter meaning unspecified.

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

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

Schema coverage is 0% across 11 parameters, so the description must compensate. It does clarify the action value set, offset/stream/limit semantics via 'incremental byte offsets' and 'bounded stdout/stderr', and timeout=0 behavior, but leaves root, label, command, job_id, encoding, and max_output_mb undocumented in both schema and description.

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

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

The description names the resource (background device processes) and enumerates the concrete actions (list/start/status/output/cancel/cleanup), giving a clear verb+resource picture. It also lists target workloads (logcat, instrumentation, perfetto, tcpdump), though it never explicitly distinguishes itself from siblings like shell_execute or adb_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?

It gives when-to-use hints via the workload list ('Use for logcat, instrumentation, perfetto, tcpdump if installed') and mentions timeout=0 for indefinite work. However, it offers no when-not guidance and no explicit routing to alternatives such as adb_command or shell_execute, so the agent must infer which tool to pick.

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 zero annotations the description carries the full burden and does disclose meaningful behavior: ambiguous/stale/disabled targets fail explicitly rather than silently picking a match, and the return is a compact ack rather than a UI tree. It stops short of stating prerequisites (whether a prior snapshot_id is required, which actions demand a `value`) or what timeout/duration_ms actually govern.

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

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

Three dense sentences with the action vocabulary front-loaded and no filler; the failure-mode and return-shape points follow in priority order. Phrasing like "pay only for the delta" is idiomatic but still clear in context.

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

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

An output schema exists, so the ack need not be expanded, and the description covers the core select-only (no annotation) behavioral story. For a mutation tool with seven parameters it still leaves gaps: text-entry prerequisites (value for set_text/append_text), timeout semantics, and what duration_ms affects are unaddressed.

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

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

Schema description coverage is 0% at the top level, so the description must compensate — and it does add real value by supplying the `action` enum that is entirely absent from the schema, plus the semantics of `return_ui`. However `value`, `timeout`, `duration_ms`, and `press_enter` are never explained, leaving four of seven parameters undocumented anywhere outside their names.

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

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

The description opens with a specific verb-plus-scope ("Act on exactly one matching element") and enumerates the exact action vocabulary (tap/long_click/double_click/set_text/.../read), so an agent knows precisely what surface it covers. It does not name the near-siblings (tap_element, input_text, act) to differentiate itself, which keeps it short of a 5.

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

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

There is explicit when/when-not guidance for one parameter: set return_ui=true only when the next step needs the whole page, otherwise pick up the delta via ui_snapshot(since_snapshot_id=...). Nothing tells the agent when to reach for element_action instead of tap_element, input_text, or fill_form, so sibling selection 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 full behavioral burden. It discloses two useful traits: that ALL splits are captured (not just the base) and that output lands on the host rather than the device. It omits whether root is required, whether existing files are overwritten, and what happens if the package 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?

A single sentence with the action, the resource (including the ALL-splits detail), the destination, and the intended use case — no filler and nothing buried.

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

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

An output schema exists, so return values need no explanation, and the tool is simple at two required parameters. Still, for an operation that may require root or elevated privileges and writes files, the absence of any permission, failure, or overwrite note 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?

Schema coverage is 0% and both parameters are bare titles, so the description must compensate. It partially does: 'an installed app's' clarifies that 'package' is the installed app identifier, and 'host directory' clarifies that 'output_dir' is a path on the host machine. It adds no format examples or path conventions.

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 ('Export') plus a precise resource ('an installed app's base APK and ALL split APKs') and destination ('host directory'). No sibling tool in the list covers APK extraction, so disambiguation is achieved implicitly, but no sibling is named explicitly.

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

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

'for development/testing' signals the intended context, which is a genuine usage hint. However, there is no guidance on when to prefer this over adjacent tools such as app_data_archive, deploy_and_verify_apk, or file_transfer_root, and no prerequisites (root, device connection state) are 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 provided, so the description carries the full behavioral burden. It does disclose valuable mechanics — Root escalation, /data/local/tmp staging, and the ability to replace files inside private directories (a destructive overwrite). However it omits whether push overwrites existing files, whether the target app must be stopped, and what happens to file ownership/SELinux context when writing into /data/data.

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

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

A single compact sentence with the bracketed capability tag front-loaded, followed by the mechanism and the supported path scope. No filler, though the tag is somewhat redundant with the sentence that follows.

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

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

An output schema exists, so return values need not be explained. Still, for a Root-level mutation tool with zero annotations, the definition should say whether push is destructive/overwriting and what the agent must verify beforehand; those gaps keep it at minimum-viable rather than 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 including action, file_mode, local_path and device_path is already documented in the schema. The description adds only the general framing of 'cross-device pull/push' and no per-parameter 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?

The description gives a specific action (pull/push files between host and device) and a specific resource scope (any Root-protected path such as /data/data/ and /data/adb/). The mechanism is also named — routing through /data/local/tmp with Root escalation. It is distinguishable from generic file tools like device_files or app_data_archive, 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?

Usage is implied rather than stated: an agent must infer that this tool is for the root-only paths that ordinary file transfer cannot reach. There is no explicit 'use this instead of X when Y' routing, and no note on preconditions such as requiring Root to be granted first.

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 at all, the description carries the full burden, and it does disclose two genuinely useful traits: it aborts at the first failed field and performs a single UI-tree dump rather than one per field. It does not say whether a partial failure prevents submission, whether already-filled fields persist after the abort, or anything about permissions/visibility requirements, so the failure-handling picture stays incomplete.

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, the batch capability and the submit option are front-loaded, and each clause carries distinct information (capability, failure behavior, performance characteristic). Nothing is repeated 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?

An output schema exists, so return values need not be explained, and the core batch/failure behavior is covered. However, for a tool whose only required parameter is a nested array of selector/value pairs, the description leaves the array ordering, the meaning of `return_ui`, and post-failure submit behavior unaddressed.

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

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

Schema description coverage is 0%, so the description must compensate and it largely does not: `fields` is never described as an ordered selector/value list, and `return_ui` is never mentioned anywhere in the schema or the description. Only `submit` gets any gloss via "optionally submit", and the Selector $defs itself does the heavy lifting for matching semantics.

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

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

The description opens with a specific verb and resource ("Fill several fields ... and optionally submit in one tool call"), which immediately distinguishes it from the single-field input_text and gesture/act siblings by making the batch nature explicit. It stops short of naming an alternative tool outright, but the purpose is unambiguous.

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

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

"in one tool call" and "One tree dump total, not one per field" give a clear context signal: use this instead of repeated per-field filling when multiple fields must be set. "Optionally submit" tells the agent the trailing submit action is conditional. No explicit exclusions or edge conditions (e.g., when not to batch) are 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 load; it usefully discloses that the tool never performs clicks and that results carry a snapshot_id for follow-up actions. It says nothing about result limits, truncation behavior when matches exceed max_results, or cost/latency of a full-tree scan.

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 tightly packed sentences, front-loaded with the verb and the AND-combination rule, with the read-only caveat and return payload in second position. Dense but no filler; "explicit nth" is terse yet the selector schema repeats the ambiguity rule.

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

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

An output schema exists, so return values need not be described. For a query tool of moderate complexity the description covers the predicate model, conjunction semantics, non-mutating behavior, and the snapshot_id handoff to action tools — what an agent needs before calling it.

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

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

Schema description coverage is 0% across ~25 selector fields, so the description must compensate. It does map the major predicate families (text, id, class, package, state flags, region, regex, nth) and confirms AND-combination, but leaves hint, semantic_key, index, label_contains, description_contains, snapshot_id and max_results entirely unexplained.

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

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

States a specific verb and resource ("Query UI") plus the predicate vocabulary it accepts and what it returns (all matches plus snapshot_id). The clause "Does not click" implicitly separates it from action siblings like tap_element/element_action, though no sibling is named explicitly.

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

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

The "Does not click" note implies this is the read-only lookup step to run before an action tool, but there is no explicit when-to-use or when-to-prefer guidance versus get_ui_tree, inspect_view_hierarchy, ui_query, or element_action. The agent must infer the workflow.

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 convey that this is a passive read of live device state and that the root UID reported is the 'actual' one, which hints at privilege context. However, it says nothing about behavior when no device is connected, latency, or whether root access is required to populate the root UID field.

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

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

A single front-loaded sentence that leads with the action and then lists the returned fields, with no filler. The enumerated field list is dense but each item earns its place by telling the agent what data is available.

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

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

With an output schema present, the description need not detail return structure, and it still summarizes the key fields. For a zero-parameter read tool this is nearly complete; the only gap is the absence of any note about failure modes when no device is 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description correctly adds no parameter discussion, keeping focus on the returned data.

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 ('获取当前连接的 Android 设备状态') and then enumerates exactly what is returned: model, Android/SDK version, root UID, foreground package/Activity, resolution, and screen-on state. That makes the tool's scope unambiguous. It stops short of naming how it differs from close siblings such as device_diagnostics, system_property, or device_connection, so it is clear but not sibling-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?

Usage is only implied: an agent can infer this is the snapshot to call before acting on a device, but the description never states when to prefer it over device_diagnostics or system_property, nor any preconditions. No exclusions or alternatives are given.

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

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

No annotations are supplied, so the description carries the full burden and does disclose that extraction happens over a fast RPC path and that returned elements carry [#index] handles for later targeting. It does not cover failure modes (missing accessibility service, empty trees) or read-only guarantees, but the behavioral picture is substantially richer than the name alone.

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

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

Three short lines, front-loaded with the core purpose, then the return shape, then the next-step affordance. Almost no wasted tokens despite the marketing framing.

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

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

An output schema exists, and the description still summarizes the payload (index, class, text, desc, id, coordinates, flags), which is more than required. The remaining gap is disambiguation from the crowded set of sibling perception tools, which the definition never addresses.

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 all three parameters (keyword, max_elements, only_interactive) are self-documented in the schema. The description mentions none of them, so it adds no meaning beyond the structured fields and 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 and resource (extract the semantic UI control tree of the current screen) and explicitly positions itself against a named alternative mechanism ('replaces slow screenshots'), so an agent can tell what it gets and why it beats screenshot_annotated.

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?

Clear usage context: use this for perception, then call tap_element(index=N) or tap_element(text=...) for the follow-up action. It stops short of distinguishing itself from the many overlapping perception siblings (ui_snapshot, inspect_view_hierarchy, find_elements, ui_describe, ui_query), so the agent must still guess among those.

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 given, the description carries the full load, and it does well: it discloses the multi-step side effects (focus, clear, inject, optional Enter), says the system IME is preserved and not modified, states that the UIAutomator2 channel supports Chinese and Emoji and fails explicitly when it is unavailable, and warns that refetching the full tree costs about 200ms and much context. It does not mention required permissions, what is lost when clear_first deletes existing content, or partial-failure behavior, so it falls short of a 5.

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

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

Two compact lines that lead with the core capability and then list the pipeline in execution order. The wording is essentially all substantive, though '极速' is marketing filler with no operational meaning.

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 tool with an output schema, the description covers the execution flow, the IME-safety guarantee, the Unicode/Emoji support boundary, and the context cost of the optional UI tree return. The remaining gap is routing guidance versus fill_form and element_action, which keeps it from being 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 is already documented in the schema, including defaults and the resource_id/hint_or_text/index focusing alternatives. The description adds only the ordering of the composite pipeline, which largely restates what the individual parameters already say. 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 and resource ('文本输入工具') and spells out the composite action: focus the field, clear it, inject the string, optionally press Enter, return the UI tree. This clearly differs from generic gesture tools. However, it does not say how it differs from siblings such as fill_form or element_action, which also enter text.

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 statement of when to use this tool, when not to use it, or which sibling to use instead. The only choice guidance is indirect and appears in the return_ui_after parameter: use ui_snapshot(since_snapshot_id=...) rather than refetching the full tree. The default-value cues (clear_first=true, press_enter=false) imply typical usage, but that is inference, 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?

No annotations are provided, so the description carries the full burden. It does disclose the important behavioral traits of Root dependency and the exact path scope (/data/data/<package>/), and '读取或查询' implies read-only. However, it says nothing about what happens on non-rooted devices, permission requirements, or the risk/behavior of the sql_query mode (whether writes are possible, statement restrictions).

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 lines with the core capability (root-level private data inspection) front-loaded before the supporting detail. The bracketed label and exclamation marks are mild marketing padding but do not obscure the meaning.

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 5-parameter tool with one required param, full schema coverage, and an output schema, the description supplies enough context to select and invoke it: what data is reachable, that it requires Root, and that no UI launch is needed. Missing only failure-mode guidance for non-root scenarios.

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

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

Schema description coverage is 100% and the schema already documents mode, package, pref_key, sql_query, and target_file in detail. The description only names the data sources (SharedPreferences, SQLite) without adding format or interaction constraints beyond the schema, so it lands at the baseline.

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

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

States a specific verb (read/query) and a precise resource: SharedPreferences XML and SQLite databases under /data/data/<package>/, accessed via Root without opening the UI. An agent can tell this is a root-level private-data inspector. It does not explicitly distinguish itself from the shared_preferences and sqlite_database siblings, which keeps 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?

The description implies usage — verifying toggle states, cached data, and internal table records without launching the app — but never states when to prefer this over shared_preferences or sqlite_database, nor any exclusions such as non-rooted devices. Usage context is implied rather than prescribed.

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 that access happens through Root and which on-device files are read, plus that a boolean toggles framework verbose logs. It does not describe failure behavior when the lspd log directory is missing or root is unavailable, nor any size/rate constraints.

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, front-loaded lines with the tool scope first and the diagnostic use case second. The bracketed marketing-style header and exclamation mark are mild fluff, but nothing is redundant or bloated.

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

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

For a read-only diagnostic tool with an output schema and fully documented parameters, the description covers the data source, root requirement, and intended diagnostic purpose. The only meaningful gap is what happens on missing root/logs, which matters for a tool that depends on a specific filesystem path.

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 (lines, keyword, include_verbose) are already documented in the schema. The description only adds the log-source distinction (module log vs framework verbose log) and does not elaborate on keyword matching syntax or line-limit behavior, so baseline 3 is right.

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 the newest module logs from `/data/adb/lspd/log/modules_*.log` and list installed KernelSU/Zygisk modules. The 'LSPosed / Xposed / KernelSU 专属' framing separates it from generic log tools like read_logcat_smart, though no sibling is named outright and it is slightly ambiguous whether the module list is always returned alongside the logs.

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

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

Gives a clear use case: verifying a hook actually took effect and detecting StackOverflowError / ClassNotFoundException style exceptions. It does not state when NOT to use it or point at alternatives (read_logcat_smart, root_shell) for non-LSPosed troubleshooting, so it stops short of 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 provided, the description carries the full burden and does substantial work: it discloses the underlying shell command, a concrete known-failure case (zero `mID=`/`mText` lines, 776-byte output for WeChat), and what data is only conditionally available. It does not state whether root/shell privileges are required to run `dumpsys activity top`, which is the main remaining behavioral gap.

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

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

Front-loads the applicability restriction and the negative result first, then the upside, which is the right order for an agent deciding whether to call it. The WeChat/776-byte anecdote is slightly more forensic detail than needed, but it substantiates the warning rather than padding.

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

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

An output schema exists, so return values need not be explained, and the description covers mechanism, applicability, failure mode, and fallback. Missing only operational prerequisites (privilege level, expected latency) for a shell-backed 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 the schema already documents all three parameters including the enum-like values for `visibility_filter` and the default for `max_lines`. The description's mention of resource IDs and hidden nodes loosely maps to `keyword` and `visibility_filter` but adds no syntax or format detail 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 mechanism (`dumpsys activity top`) and resource (Activity/Task records / View hierarchy), and enumerates the three extra data classes it can surface: custom View class names, hex resource IDs, and GONE/INVISIBLE nodes. It is clearly distinguishable from the UI-inspection siblings because it names `ui_describe` as the different path.

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 scopes use to ROMs that emit AOSP-style View trees, explicitly excludes the current device (HyperOS / Android 16) with measured evidence, and redirects the agent to `ui_describe` for interface understanding. Both the when and the when-not, plus the alternative, are spelled out.

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 does well on safety: destructive/financial controls are refused and recorded as refused, never pressed, and each probe taps only one control with a before/after diff. It still omits important behavior — whether this requires an accessibility service or root, what happens to screen state after a probe that navigates (only the parameter name allow_restore hints at restoration), and failure/partial-budget 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?

Structure is front-loaded: what it does, why it is necessary, then the mechanics, then the safety refusal, then the payoff. The measurement parenthetical (56.7%) supports the rationale rather than padding, though the sentence chain is long enough that the key refusal rule is buried mid-paragraph.

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 high-risk UI-mutating prober, the description covers the probing loop, persistence key, refusal policy, and budget, and an output schema exists so return shape needs no explanation. The remaining gap is the two unexplained parameters, especially the restore behavior, which an agent needs to invoke it safely.

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

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

Schema description coverage is 0%, so the description must compensate, and it only explains one of three parameters: budget, correctly, with the 1-5 range that the schema's bare default of 2 does not convey. settle_ms and allow_restore are never mentioned, and allow_restore in particular looks safety-relevant for a tool that navigates and mutates UI state.

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 names a specific verb and resource — tap unknown/unnamed controls, diff the screen, and persist the observed effect under app+activity. It also implicitly separates itself from direct-action siblings like tap_element or act by scoping to controls with no label or clickable flag, and states where results surface (learned_effect on ui_describe).

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 triggering condition (apps whose tappable controls carry no text/description/id, or report no clickable flag) and a budget of 1-5 probes per call, which tells the agent the expected scope of use. It never explicitly names an alternative tool for labeled elements or says when not to call it, leaving that routing 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?

No annotations are supplied, so the description alone must carry the behavioral burden. It does not disclose that stop is a force-stop, that clear_data irreversibly wipes data and cache, that restart is a cold restart, or that grant_all_permissions may partially succeed, with special permissions being out of scope. The only hint of destructiveness is the word '清空数据' in the parenthetical.

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

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

It is a single short parenthetical sentence with no wasted prose, and its core nouns lead. However, it duplicates the schema's action list instead of front-loading the higher-value information, such as the destructive nature of clear_data or when to prefer a sibling 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?

An output schema exists, so return values need not be explained, and the 2-parameter schema is fully documented. But for a tool that can force-stop, cold-restart, and irreversibly wipe an app with zero annotations, the description omits the risk and side-effect information that an agent would need before invoking it.

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

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

Schema description coverage is 100% and every action is documented in detail at the parameter level, including per-action semantics. The description adds nothing about package format, defaults, or action interactions that the schema does not already state, 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?

It names a specific resource (app) and enumerates the five operations (info, stop, restart, clear_data, grant permissions), so the general purpose is discernible. But the enumeration simply reproduces what the schema already declares, and it never distinguishes the tool from close siblings such as app_action or app_permissions, which overlap heavily with lifecycle and permission work.

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 statements, no preconditions, and no explicit exclusions. The agent must infer that this tool should be chosen over app_permissions for granting or app_data_archive or inspect_app_data for data-related tasks; the description gives no guidance on that choice.

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

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

With no annotations, the description carries the full burden; it does disclose real side effects (animation scales set to 0, keyguard dismissed, screen woken, stay-awake enabled). It does not say whether root/ADB privileges are required, whether the changes persist across reboots, or what happens if one step fails.

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 Chinese header followed by a tight numbered list of exactly the three effects; no filler. The bracket-styled title is slightly decorative but still informative.

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?

Outputs are covered by the output schema and parameters are fully described, so the essentials are present. For a state-mutating device tool with zero annotations, missing prerequisites (root/ADB), reversibility guarantees, and partial-failure behavior leave a real gap.

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

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

Schema coverage is 100% and each parameter already documents its default and the profile_id restore path, so the schema does the heavy lifting. The numbered list loosely maps to the three boolean flags but adds no new semantics beyond the field descriptions.

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

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

States a specific verb and resource (tune the device into agent-optimal mode) and enumerates the three concrete mutations, so an agent can tell it apart from granular siblings like system_settings or device_control. It stops short of naming those siblings explicitly, which keeps 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?

The framing 'best state for AI Agent high-speed control and debugging' implies the use case (preparing a device before automation), but there is no explicit when-to-use, when-not-to-use, or named alternative such as changing individual settings via system_settings.

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 disclosure burden. It reveals the backend (uiautomator2) and the batching rationale, but says nothing about what happens on an invalid action string, whether gestures block until completion, or what the response contains beyond the mere existence of an output schema. For a device-mutating input-driving tool with zero annotation coverage, 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 or redundancy. It is efficient, though its terseness comes at the cost of the missing parameter and behavior detail noted elsewhere.

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 output schema relieves it of explaining return values, but for a 5-parameter tool with 0% schema description coverage and no annotations, the description should define the action vocabulary, the points coordinate format, and the meaning of percent/duration/selector. None of that is present, leaving an agent to guess at call shape.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and largely does not. It hints that 'points' is the swipe path and that 'action' values include pinch_in/pinch_out, but leaves 'percent', 'duration', and 'selector' entirely undefined, and never enumerates the full set of valid action strings for a free-form required string.

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 concrete verb (perform) and concrete gesture resources (multi-point swipe path, pinch_in/pinch_out), plus the backend (uiautomator2). This distinguishes it from the plain swipe path implied by the sibling swipe_screen, though 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?

The phrase 'avoiding repeated tap/swipe tool round trips' implies when to reach for this tool over single-action siblings, but it is indirect. There is no explicit 'use X instead when...' routing and no stated preconditions (e.g., screen must be idle, gesture must start from a valid UI state).

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 add useful behavior: tcp:0 allocates an ephemeral port, and the no-rebind default avoids clobbering another debugger's mapping. It does not state that add/remove mutate the device forwarding table, whether changes persist, or what privileges are needed.

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

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

Three short sentences, front-loaded with the verb and resource, with no filler. The dotted-domain phrasing is terse but each clause adds information; it stops just short of being cryptic.

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

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

Since an output schema exists, return values need not be described, and the description covers endpoint types, port allocation, and the no-rebind safety behavior. Remaining gaps (mutation effects of add/remove, prerequisite adb authorization) are real but modest for a 4-parameter tool.

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

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

Schema coverage is 0%, so the description must compensate, and it partially does: 'tcp:0 allocates a port' clarifies the endpoint spec syntax, and 'forward/reverse' and 'list/add/remove' map onto the reverse and action parameters. It never explains the local/remote string formats per endpoint type or enumerates valid action values, so the compensation is incomplete.

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

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

The description names the specific resource (ADB forward/reverse mappings) and the operations (list/add/remove) plus supported endpoint types (tcp/localabstract/localfilesystem/jdwp). An agent can distinguish this from generic command tools, though it does not name the closest sibling (adb_command) 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?

There is no explicit when-to-use guidance or routing advice relative to adb_command or shell_execute. The phrase 'No host shell' hints at a boundary but is a constraint, not a condition that selects this tool over alternatives.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It claims the tool automatically returns the latest UI structure, which conflicts with the schema's return_ui_after default of false, and it says nothing about permission requirements or side effects of POWER/SLEEP presses on device state, nor how long the call blocks when wait_after_ms is used.

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

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

A single, front-loaded sentence that states the action and its postcondition without padding. The trailing 'etc.' and the vague '等' slightly blur the exact key set, but overall the wording 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?

An output schema exists, so the description need not explain return values, and the operation itself is simple. However, for a tool capable of POWER/SLEEP and WAKEUP — device-state-affecting keys — the absence of any note on permissions, irreversibility, or how the UI-return behavior relates to the return_ui_after parameter leaves meaningful 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 three parameters (key, wait_after_ms, return_ui_after) are already documented in the schema and a baseline of 3 applies. The description's mention of key names merely echoes the schema's enum-like examples and adds no syntax, format, or default-behavior detail beyond 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?

The description gives a concrete verb+resource — sending physical/virtual system key presses — and lists representative keys (BACK, HOME, APP_SWITCH, ENTER, POWER/WAKEUP), so the agent knows exactly what operation this performs. It does not distinguish itself from sibling input tools such as swipe_screen, tap_element, perform_gesture or send_intent, which keeps it short of a 5.

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

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

There is no explicit when-to-use guidance: nothing says when a key press is preferable to perform_gesture, element_action, or send_intent, and no prerequisites or exclusions are given. The key list implies navigation scenarios, but the agent must infer selection criteria on its own.

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 behavioral load; it does disclose the important Root prerequisite and that the operation is UI-free/background, which is real added value. It does not warn that 'clipboard_set' overwrites existing clipboard content, nor what happens if Root is unavailable or the source is empty.

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 bracket tag identifying the tool class, followed by the concrete extraction targets. Nothing is wasted, though it is dense and omits the write-side behavior of the clipboard operation.

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 small (2 optional params, full schema coverage, output schema present), so return values need no explanation. The remaining gaps are behavioral: no mention of Root failure handling, permission implications, or the mutating nature of clipboard_set, which matters for a forensics tool an agent may invoke autonomously.

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 every enum value of 'source' and the dual meaning of 'value_or_uri' already documented in the schema. The description only restates the source categories at a high level, adding no format, constraint, or interaction detail beyond the schema; 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 capability set — extracting notifications, SMS verification codes, and reading/writing the clipboard through Root without touching the UI — which is far more concrete than the name alone. It stops short of differentiating itself from plausible siblings such as content_provider or inspect_app_data, which also read device-side 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 phrase '无需下拉通知栏或打开短信 App' implies the scenario (headless background collection where UI interaction is undesirable), so an agent can infer when this is preferable to tap_element or app_action flows. However, no explicit when-not conditions, prerequisites (Root availability), or tool-alternative routing are 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 burden, and it does disclose non-obvious behavior: automatic PID resolution from a package name and the switch to the crash ring buffer. However, it never warns that clear_first wipes the log buffer — a destructive side effect only visible in the schema — and says nothing about permissions or device prerequisites. The presence of an output schema excuses it from explaining return values.

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

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

A single bracketed label followed by one dense sentence that front-loads the core capability and then lists the three distinguishing modes. Nothing is padded, though the bracketed Chinese tagline duplicates the tool name rather than adding 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 seven-parameter, fully optional tool with an output schema, the description covers the main operating modes adequately. What it omits is material: the destructive nature of clear_first, any guidance on combining filters, and any differentiation from the generic adb/shell siblings that could also read logs.

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 one of the seven parameters is already documented in structured form, which sets the baseline at 3. The description restates a few of them (package-based PID binding, crash_only, tag/keyword filtering) without adding format, precedence, or interaction rules — e.g. what happens when both package and grep_keyword are set.

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

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

The description names a specific resource (Logcat) and three concrete capabilities: automatic PID binding by package name, one-click crash stack extraction via crash_only=True, and filtering by Tag or keyword. An agent can tell this is a filtered log-read tool, not a generic shell or adb wrapper, even though no sibling (e.g. adb_command, shell_execute) is named as an alternative.

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: the mention of crash_only=True for 闪退 (crash) investigation hints at the crash-diagnosis scenario, but there is no explicit when-to-use statement, no when-not-to-use, and no routing to alternatives such as adb_command or shell_execute for raw logcat access. The agent must infer the context from the feature 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?

With no annotations, the description carries the full burden and does disclose real behavior: the operation is asynchronous (start returns job_id immediately), stop sends SIGINT specifically to finalize the MP4, and pull must follow completion. It omits permission/root requirements, where the artifact is written, and what happens if pull is called early, which keeps it below a 5.

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

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

Three terse sentences, front-loaded with the resource and action set, with no filler. The compressed 'start/status/stop/pull' notation and the trailing 'ROM screenrecord limits apply' are slightly telegraphic but each sentence carries distinct information.

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

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

An output schema exists, so return values need not be explained, and the description covers the async lifecycle and finalization constraint that an agent must respect. The remaining gap is operational prerequisites (root/permissions, output location) and the meaning of local_path, which is a real but limited omission for a device recording 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 0% across five parameters, so the description must compensate. It effectively enumerates the valid 'action' values (start/status/stop/pull) that the schema leaves as a bare string, and explains job_id's role in the lifecycle, but says nothing about seconds, bit_rate, or local_path beyond the vague 'ROM screenrecord limits apply'.

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

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

States a specific resource (background MP4 recording) and enumerates the four lifecycle actions (start/status/stop/pull), so the agent knows exactly what the tool does. It does not explicitly differentiate itself from sibling capture tools like screenshot_annotated or compare_screenshot, which is the only reason it falls short of a 5.

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

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

The sequence is implied rather than stated: 'Start immediately returns job_id' and 'pull after completion' tell the agent the correct ordering, but there is no explicit when-to-use guidance or named alternative (e.g., use screenshot_annotated for a single frame). Usage must be inferred from the lifecycle phrasing.

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 at all, the description carries the full behavioral burden. It does add real value by disclosing that execution happens through `su -c` at uid=0, which tells the agent a rooted device is required. What it omits is the risk profile: arbitrary root execution is destructive and irreversible, yet there is no warning, no mention of failure when root is unavailable, and no note on blocking/timeout behavior beyond the schema.

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

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

The capability statement comes first and the example command families follow, so it is front-loaded correctly. The '上帝模式直通车' framing is filler rather than information, but it costs only a few characters. Two short sentences for a two-parameter tool is proportionate.

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

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

An output schema exists and the parameters are fully described, so the return-value burden is lifted. What is missing for a tool of this power level is the operational envelope: required root state, expected failure modes, and any caution about irreversible system mutation. Adequate, but thin for an unrestricted root shell.

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 `command` and `timeout` are already fully documented in the schema, including the uid=0 execution context and the 20s default. The description adds no syntax, quoting, or multi-command guidance beyond what the schema states. 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: execute arbitrary Root-privileged shell commands via `su -c`, and lists concrete command families (resetprop/setprop, kernel/mount inspection, /data/ access, firewall). An agent knows exactly what it does. However, it never distinguishes itself from close siblings like `shell_execute`, `adb_command`, or `file_transfer_root`, so the boundary is inferred 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?

The enumerated examples imply the use case: operations that require uid=0. But there is no explicit statement of when NOT to use it or which sibling to prefer for non-root commands, which matters because `shell_execute` and `adb_command` overlap heavily. Usage is implied, not prescribed.

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 usefully discloses postconditions, on_error, bounded loops/deadline, trace, and warns against blind retries of non-idempotent actions, but it does not cover permission/root requirements, detailed failure behavior, or side effects.

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

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

Two dense sentences front-load the core operation and then summarize key capabilities. Every clause adds information without repetition or filler.

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

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

This is a complex nested workflow tool with no annotations and no schema property descriptions. The description lists actions and a few features, but it is not complete enough to guide correct construction of the nested workflow object without significant schema inspection.

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

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

Schema description coverage is 0% for a deeply nested workflow object. The description lists the action enum values, but it does not explain workflow-level fields like timeout, return_ui, or max_executed_steps, nor selector predicates, Condition kinds, or per-step semantics, leaving most parameter meaning to inference.

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: execute a prevalidated UI/Root workflow in one call, and lists the supported action types. It is clear what the tool does, but it does not distinguish itself from siblings such as batch_ui_actions, workflow_control, or saved_workflow.

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

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

The phrase 'in ONE call' weakly implies use over multiple atomic calls, but there is no explicit when-to-use guidance, no mention of alternatives like batch_ui_actions or workflow_control, and no conditions for choosing this tool over saved_workflow or individual action tools.

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

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

With no annotations, the description is the sole source of behavior, and it does disclose two genuinely useful traits: save validates all steps before atomic storage, and saved workflows survive MCP restarts. It says nothing about whether delete is recoverable, what run returns, whether concurrent runs are allowed, or what happens on a name conflict.

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 resource and operation vocabulary before the behavioral detail about validation and persistence. No filler, though the action list could be formatted more scannably.

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 heavy nested Workflow/WorkflowStep/Selector schema carries the bulk of the structural contract and an output schema exists, so the description only needs to frame the operations and key behaviors, which it largely does. The gap is per-action parameter requirements and the overlap with the run_workflow siblings.

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

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

Schema coverage is 0% and the action parameter is a bare string with no enum, so the list of action values in the description is doing essential work the schema does not. However, it does not explain how name and workflow must be supplied per action (e.g. that save requires a workflow, load/run/delete require a name), leaving the caller to infer the per-action contract.

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?

"Persist/reuse named workflows" states a concrete verb and resource, and the list/save/load/run/delete enumeration makes the multi-operation nature explicit. It does not distinguish itself from siblings like run_workflow or workflow_control, which appear to overlap on the run capability, so an agent cannot tell from the description alone which to pick.

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 names imply what the tool can do but there is no guidance on when to persist a workflow here versus executing it via run_workflow, workflow_control, or batch_ui_actions. No prerequisites, no mention of when a workflow should be saved at all or what a name collision means.

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 disclose a real behavioral constraint: secure layers / DRM can produce a blank image or a refusal. It also documents that annotation is on by default and that optional disk saving exists. Missing detail on whether the image bytes or a path is returned, which matters given there is no output 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?

Front-loaded with purpose, then limitations, then the default/annotation workflow, then the routing note. The exclamation marks and mixed brackets are slightly noisy but every sentence carries distinct information.

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

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

For a 3-parameter read tool with no output schema, the description covers the key gaps: DRM failure modes, the default annotation behavior, and the downstream action. Only the return shape (image payload vs. saved path) is left implicit.

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 meaning the schema does not: it explains why `annotate_elements=True` matters (indices feed directly into `tap_element`) rather than just restating the flag. `max_width` and `save_path` are left to the schema, which is adequate.

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 ('获取手机屏幕截图') and immediately adds the distinguishing capability: the Set-of-Mark `[#0]`, `[#1]` overlays. It also names `get_ui_tree` as the different sibling, so an agent can tell the two apart without opening a schema.

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

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

Explicit routing: prefer `get_ui_tree` for daily operations, use this only for Canvas / map rendering / games / visual verification. Both the when and the when-not are stated, plus the follow-up action `tap_element(index=编号)`.

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 supply one genuinely useful behavioral fact: 'Reports am errors even if exit code is zero,' which warns the agent not to trust exit status alone. It also flags the root/nonroot distinction. However, it says nothing about side effects of dispatching intents, permission requirements, or whether a failed dispatch partially applies.

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

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

It is a single dense, telegraphic sentence with no wasted filler, which is efficient. But the run-on colon-separated list is hard to parse and the capability enumeration is not front-loaded as a clear statement of what the tool does.

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 12-parameter, zero-annotation tool, the description covers a decent share of the surface (kinds, extras typing, MIME, categories, flags, root mode) and an output schema exists to explain returns. It still leaves wait and user_id unexplained and gives no example of a valid call, which is a meaningful gap for a tool this broad.

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

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

Schema coverage is 0% (titles and defaults only), so the description must compensate, and it does partially: it maps to kind, extras types (bool/int/long/float/string/null), flags, categories, mime_type, data_uri (DeepLinks), and package/activity (internal components). But action, wait, and user_id are never mentioned, so several of the 12 parameters remain opaque.

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 the tool name plus an enumeration of what the Intent can be (activity/broadcast/service/foreground_service/stop_service, internal components, DeepLinks, extras types), so an agent can tell this is the general-purpose Intent dispatcher. It does not explicitly differentiate itself from the sibling start_activity_root, which overlaps with the 'activity' kind, 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?

There is no when-to-use or when-not-to-use guidance. The description never says to prefer this over start_activity_root for simple activity launches, nor when root vs nonroot or wait=true should be selected, leaving the agent to infer routing from a feature 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?

With no annotations, the description carries the full burden and does well: it discloses that writes stop the app, preserve ownership/mode, back up the old XML, check its hash, and leave the app stopped. It does not cover permission/root requirements or error behavior, so it is strong but not complete.

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

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

The description is compact and front-loaded, with the core operation and write side effects stated immediately. There is minor redundancy between 'Writes stop the app' and 'leaves app stopped,' and the values notation is terse but 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 an 8-parameter tool with no annotations and 0% schema description coverage, the description is not complete enough to guide correct invocation. It explains the core behavior and values shape, but leaves most parameters and operational prerequisites undocumented; the output schema does cover return values.

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

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

Schema description coverage is 0% across 8 parameters, and the description only explains the values format and implies the action. Required parameters like package and file, plus keys, storage, user_id, and stop_app, receive no semantic explanation beyond their titles.

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 specific operations (read/set/delete) on a specific resource (typed private XML preferences) and lists supported value types. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as inspect_app_data, sqlite_database, or system_settings.

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

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

Usage is implied by the resource name and operations: use this for private XML shared preferences. However, there is no explicit when-to-use guidance, no exclusions, and no comparison to adjacent tools that also inspect or modify app 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, the description carries the full burden and does disclose real behavior: single shared process/session, per-command exit codes and output, and optional fail-fast. It omits important traits for arbitrary shell execution — whether root privileges are required, whether the session persists between calls, whether timeout applies per command or to the whole batch, and how 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?

Two sentences, front-loaded with the core action and scope, with the rationale clause last. No filler, and the hard 200-command cap is stated up front where an agent will see it.

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

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

An output schema exists, so return-value explanation is correctly omitted, and the batching model is conveyed. For a high-blast-radius arbitrary shell tool with zero annotations and zero schema descriptions, gaps around permissions/root requirement, timeout semantics, and output truncation leave the agent under-informed before invoking it.

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

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

Schema description coverage is 0%, so the description must compensate and only partly does: "1..200" clarifies the commands array bounds, "optional fail-fast" maps to stop_on_error, and "Root session" hints at root. It says nothing about timeout (per-command vs total), max_output_bytes truncation behavior, or the label field.

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 1..200 CLI commands") plus a scope constraint (all in ONE ADB process/Root session), which an agent can distinguish from a single-command tool. It stops short of naming the sibling to use instead (e.g., shell_execute or adb_command), which is what a 5 would require.

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?

"Avoids one subprocess/tool call per command" implies the use case is multi-command workloads and is a useful hint, but usage is only implied. There is no explicit statement of when to prefer shell_execute/adb_command for a single command, nor any exclusion or prerequisite condition.

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 execution is device-side only ("never invokes a host shell"), that timeouts are device-side when supported, that root is achieved via su uid=0, and that output may be truncated — but it omits what happens if the device is not rooted, whether commands are destructive, and permission/error behavior. The return-field listing largely duplicates the output schema, so real added value is moderate.

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

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

Three dense, front-loaded sentences with no filler; the key constraint (host shell exclusion) lands early. The telegraphic phrasing ("optionally su uid=0", "real exit_code/stdout/stderr") is efficient but slightly opaque to a non-expert reader.

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, unannotated, high-risk arbitrary-execution tool, the description covers the execution model and output shape but leaves side-effect risk, root prerequisites, and per-parameter tuning undocumented. The existing output schema offsets the need to explain return values in detail.