install_adb_package

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the description's job is to add context — and it does: the device is mutated, `replace` preserves app data, the tool records the host digest and byte size, and the device's own Success/Failure verdict with reason is passed through. It stops short of saying what happens when `replace` is false and the package already exists (fail vs. overwrite), which is the one behavior an agent still has to guess.

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: what it does and the adb equivalent first, then mutation semantics and output behavior. Nothing is repeated from the annotations and no sentence is 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?

With no output schema, the description usefully covers what comes back (device verdict plus reason, digest, byte size) and what gets mutated. The missing piece is preconditions — device reachability and the failure mode when `replace` is false against an existing package — leaving a small but real gap for a destructive 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%, including the `replace` semantics, so the schema carries the parameter meanings. The description reinforces the `replace` behavior and the 'local APK' constraint on apk_path but adds no format, resolution, or validation detail beyond the structured fields — baseline 3 is appropriate.

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

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

States a specific verb and resource ('Install one local APK on the device') plus the underlying adb command, and the 'one local APK' scoping separates it from pull_adb_package, push_adb_file, and uninstall_adb_package. An agent can pick this out from the many adb siblings without opening the 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?

The description gives clear context: local APK only, single package, and it explains when `replace` applies (re-installing over an existing package while keeping its data). It does not explicitly say when to prefer push_adb_file or what to do if the APK is not on the host, but the usage context is otherwise unambiguous.

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