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

With no annotations, the description carries the full burden of disclosing behavior. It mentions the mechanism ('via top') and the outputs (CPU %% and MB), but doesn't state whether the operation is read-only, how the results are structured, or whether any device state is affected. For a monitoring tool this is minimally informative, but it leaves important behavioral questions unanswered.

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?

The entire description is one efficient sentence that front-loads the core action and resource, then adds the two usage modes. There is no filler or redundancy; every word earns its place.

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 simple 3-parameter snapshot tool with full schema coverage, the description covers the core function well. However, there is no output schema and no mention of the return format (e.g., a table or list), nor any edge cases like what happens when both topN and pkg are provided. It's adequate for an experienced agent but leaves some gaps.

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?

The schema already describes all three parameters at 100% coverage, giving a baseline of 3. The description adds meaningful interaction semantics: 'Top-N by CPU, or one app via pkg' clarifies that pkg overrides the top-N mode. This goes beyond the individual property descriptions and helps an agent reason about parameter combinations.

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?

The description states a specific verb ('Snapshot') and resource ('per-process CPU and memory for an Android device via top'), making the core function immediately clear. It also names the two operating modes (Top-N by CPU or single app via pkg). It doesn't explicitly compare against siblings, but the word 'Snapshot' naturally distinguishes it from android_performance_record_start/stop.

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 no guidance on when to prefer this tool over alternatives like android_performance_record_start/stop or ios_performance_snapshot. It only explains the two in-tool modes (top-N vs pkg), not the selection criteria or contexts where this tool should be used or avoided. An agent must infer usage entirely from the tool name.

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