Prefer a wireless device transport

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

Annotations declare destructiveHint=false and idempotentHint=true but leave readOnlyHint=false unexplained; the description resolves that by stating 'Read-only by default' and disclosing the mutation's side effects — adbd restarts on the device, the cable is needed once, and `adb usb` reverses it. That is material behavior beyond what the annotations convey, and it does not contradict them.

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

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

Three sentences, front-loaded with the read-only report behavior before the promote path and platform caveats. Dense but essentially waste-free; the clause about the VM Service tunnel is justification, not filler, though the sentence count could be trimmed slightly.

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 tool with no output schema and an optional state-changing mode, the description covers the return signal (adbAvailable:false on unsupported platforms), the mutation's preconditions and reversibility, and the default safety posture. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that promote performs `adb tcpip`/`adb connect`, and that serial selects which USB device to promote. Port is left to the schema, which fully documents it, so this is a modest but genuine uplift.

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 ('Report Android device transports and recommend one, preferring wireless') and then scopes the mutation mode ('With promote:true it runs adb tcpip and adb connect'). No sibling tool overlaps this behavior, so an agent can route to it unambiguously.

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 frames when the tool matters (a `flutter run` on USB loses its VM Service tunnel when the cable moves), what the default is (read-only), when to escalate (promote:true), when it does NOT apply (iOS, desktop, web), and how to undo it ('reversible with `adb usb`'). This is when/when-not/alternative guidance in full.

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