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

No annotations are provided, so the description carries full burden of behavioral disclosure. It reveals the source tool (`top`), which is useful as it implies sampling at the moment of call (snapshot, not continuous). However, it does not disclose what the output format looks like, whether this is a passive read, typical latency, or behavior on multiple matching processes for pkg filter. For a read-only performance snapshot with no annotations, more detail would be valuable.

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, dense sentence that packs substantial information: the tool's purpose, the underlying mechanism (top), metrics captured (CPU%, MB), and both operational modes. Zero filler, every clause earns its place. Front-loaded with the primary action.

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 3-param tool with no output schema and no annotations, the description covers the essentials: what it does, how it does it, and the two modes. However, it doesn't document the output shape (agent doesn't know what result format to expect), doesn't address edge cases (e.g., no pkg match, topN behavior), and lacks detail on when this is preferable to the record_start/record_stop siblings for time-series measurement. Adequate but with clear gaps given zero annotation coverage.

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 the baseline is 3. The description adds value by clarifying the DEFAULT of topN (implied 15 is in the schema) and how pkg behaves ('filter to processes whose name contains this package' — substring matching, not exact match). The description's mention of 'Top-N by CPU, or one app via pkg' ties the parameters to the tool's two operational modes, adding context beyond the schema fields.

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 ('Snapshot' CPU%/memory via 'top') with two clear modes (Top-N by CPU or one app via pkg), distinguishing it from related siblings like android_fps and android_performance_record_start/stop which cover different metrics/durations. It clearly identifies the mechanism (top) and units (%, MB). Slight deduction for not explicitly differentiating from ios_performance_snapshot, though the 'Android device' qualifier handles this.

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 two usage scenarios (top-N aggregate snapshot vs filter to a single package) but doesn't explicitly state when to prefer this over alternatives like android_performance_record_start for continuous measurement. The parameter `serial` reference to `device_list` hints at a prerequisite but it's implied rather than explicit. No exclusions or when-not-to-use guidance given.

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