inspect_adb_package

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

The description ends with 'Read-only,' which directly contradicts the declared annotation readOnlyHint=false — the same semantic axis, opposite values. The other context it provides ('fixed projection of version-dependent output; unknown sections are ignored rather than guessed') is genuinely useful behavioral disclosure, but the explicit read-only claim conflicts with structured metadata and could mislead an agent about whether the call mutates state.

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, then the projection caveat, then the safety note. No filler, no restatement of the tool name, and the field enumeration earns its length by substituting for a missing output schema.

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?

There is no output schema, but the description compensates by listing the returned fields and by explaining that the projection is fixed and unknown sections are skipped — exactly the caveat an agent needs when parsing version-dependent dumpsys output. What's missing is any note on failure modes (package not installed, offline device) or result size, and the read-only claim is inconsistent rather than clarifying.

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 (serial, package, optional analysis_project_id) are already documented with patterns and semantics in the schema. The description adds nothing about parameter format, package-name syntax, or what retaining a result in an analysis project implies. Baseline 3 applies when the schema carries the burden.

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?

Specific verb ('Inspect') plus a bounded resource ('one installed package') and an explicit mechanism ('dumpsys package'). It also enumerates the exact fields returned (version name/code, install/update times, installer, user id, flags, permission count), so the agent knows the payload shape. It never names the sibling it is *not* (list_adb_packages, pull_adb_package, inspect_android_package), leaving that distinction to be inferred.

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 'Inspect one installed package' implies the unit of work and rules out bulk listing only by implication. There is no explicit when-to-use, no statement of prerequisites (device connectivity, package must be installed), and no pointer to list_adb_packages for discovery before inspecting or pull_adb_package when the artifact itself is needed.

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