adb_command

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.