adb_list_apps

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this tool may require an authorized/connected device, what happens on failure (offline device, no devices), whether output is large/needs filtering, or whether results are cached. For a read-only list operation, the risk is lower, but the absence of annotations plus minimal behavioral detail leaves transparency 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?

A single, compact sentence that conveys purpose and the key parameter nuance with zero waste. Every word earns its place.

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

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

For a simple list tool with 2 params and no output schema, the description is reasonably complete in purpose. However, there is no output schema and no annotation coverage, so the description could add value by noting return format (package names vs full package info) or clarifying what 'all packages' vs 'third_party=true' produces in output. The tool is simple enough that this is adequate but not complete.

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

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

Schema coverage is 50% (serial described, third_party not described). The description adds meaning to third_party ('user-installed only') which the schema lacks, compensating for the third_party gap. However, 'serial' is already fully described in the schema, and the description adds nothing about the omit-if-only-one-device behavior beyond what schema provides. Net: partial compensation only.

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

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

Description states a specific verb+resource ('List installed packages') and clarifies the meaning of third_party=true ('user-installed only'). It distinguishes from siblings like adb_install/uninstall, though it doesn't explicitly differentiate from adb_shell (which could also list packages).

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 use case of listing installed packages but provides no explicit guidance on when to use this vs adb_shell with pm list commands, and no context on device requirements (device must be connected/authorized). No exclusions or alternatives are named.

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