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

Annotations already cover read-only, idempotent, open-world, and non-destructive hints. The description adds valuable behavioral detail: that a not-installed package is a normal answer (installed:false with a note) rather than an error, which prevents the agent from misinterpreting a common outcome. It also mentions the underlying command (dumpsys package) and the cheapness, providing context beyond annotations.

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 description is a single paragraph, front-loaded with the main purpose and then details. It is informative without being verbose; each sentence contributes (purpose, fields, non-error behavior, cheapness). While not bulleted, it is well-structured and skimmable. Slight length keeps it from 5.

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 fully specifies the return values (version, SDK, paths, times, installer, system status, running state) and explicitly handles the not-installed case. It also provides usage context (cheap check). For a read-only inspection tool, nothing essential 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 description coverage is 100%, and both parameters have descriptive text (device serial context, package name pattern/example). The description adds minimal extra parameter meaning—only implying that package_name refers to an installed package, which is already in the schema. 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?

The description names a specific verb ('Read') and resource (facts about an installed package via dumpsys package), then enumerates exact fields (version, SDK, paths, times, installer, system status, running state). It clearly distinguishes from siblings like android_list_apps (list) and android_processes (processes) by specifying what it returns.

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?

It states a clear context: 'this is the cheap way to check a package name before acting on it,' guiding agents on when to use it. It does not explicitly name alternatives or exclusions, but the context is sufficient for selection among siblings.

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

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

Despite annotations already marking it as destructive and not read-only, the description adds substantial behavioral context beyond those flags. It reveals the exact signal mechanism (kill -3), the dependence on /data/anr/ permissions, the fallback to logcat-crash on production devices, and critical interpretation caveats (logcat-crash shows last crash, empty means no crash, not absence of stacks). This goes far beyond the boolean hints and materially improves an agent's ability to interpret results correctly.

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 description is long but every sentence adds value. The core action is front-loaded, followed by the mechanism, the fallback, and crucial interpretation warnings. While verbose, it is not padded; each clause covers a distinct operational or interpretational aspect. The only minor inefficiency is the extended prose on engine and note, but that is essential given the fallback's pitfalls.

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 must convey return structure. It mentions the engine and note fields and warns about logcat-crash semantics, but it does not fully enumerate the output fields or error scenarios. For a stack-capture tool, it provides enough to use and interpret results effectively, though a complete field list would make it exhaustive. The four parameters are all optional and well-covered.

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 each parameter already has a description. The tool description adds extra nuance: for package_name it explains pid resolution via pidof -s and the behavior when app is not running; for all_threads it clarifies what false does (keeps first thread block, typically main thread). These details enrich parameter understanding beyond the schema, justifying a score above the baseline of 3.

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 opens with a clear, specific verb-resource pair: 'Capture stack traces for an app.' It then details the underlying mechanism (kill -3, ANR trace) and the fallback to logcat-crash, making the tool's purpose unmistakable and distinct from siblings like android_logs or android_meminfo. No ambiguity remains about what this tool does.

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 explains the behavior and degradation but does not explicitly state when to choose this tool over alternatives, nor does it name sibling tools for contrast. It implies usage (when you need stack traces for a running app) but leaves the decision boundary implicit. No explicit 'use this when...' guidance is provided.

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

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

Annotations indicate a mutating, non-idempotent operation. Description adds that it primes the private frame source used for coordinate mapping, and discloses that MCP has no live DSH sidebar, steering to android_screenshot. This goes beyond annotations by describing side effects and limitation.

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 concise sentences, front-loaded with purpose, then input handling, then limitation/alternative. No 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?

For a single-parameter tool with no output schema, the description covers purpose, input selection, and a key limitation (no live sidebar). It implies its role in coordinate mapping but does not explicitly state that it must be called before interaction tools, which would be helpful. Otherwise it's fairly complete.

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% and the schema description already explains serial vs AVD and boot behavior. The tool description echoes this but adds no new semantic detail for the parameter. 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 ('Prepare') and resource ('an Android target'), and notes the launch/boot behavior. It distinguishes itself from android_screenshot by pointing out that it primes the frame source, so an agent can see it's not just for viewing.

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?

Provides context that the device can be a serial or AVD, and that an AVD is booted. Recommends android_screenshot for seeing the device, but does not explicitly compare to interaction tools like android_tap_element or android_launch_app. The guidance is mostly about the input and viewing, not about sequencing relative to other boot tools.

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

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

Annotations already cover read-only and non-destructive behavior. The description adds valuable context beyond annotations: physical and network devices are hidden unless explicitly enabled and exact-allowlisted, which an agent needs to interpret results correctly.

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 concise sentences, with the core purpose front-loaded and policy detail following. No wasted wording; every sentence 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?

With no parameters, no output schema, and annotations covering safety, the description fully explains what the tool lists, the hidden-device policy, and the recommendation to run it first. Nothing critical is missing for an agent to use it correctly.

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 tool has zero parameters, so there is nothing for the description to explain. Baseline for 0 params is 4; no deduction needed.

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 clearly states a specific verb ('List') and resource ('Android devices'), and defines scope: devices allowed by server policy plus local AVD names. It distinguishes itself from sibling action tools (boot, screenshot, etc.) by being a listing operation.

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 instructs 'Run this first' and explains that every action uses an exact adb serial, giving the agent a clear prerequisite and context for the tool's role. It doesn't name an alternative tool, but the guidance is strong and unambiguous.

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

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

Despite annotations already declaring readOnlyHint=true and idempotentHint=true, the description adds substantial behavioral detail beyond annotations: it states the tool captures a fresh screenshot, requires a macOS host for Vision helper, returns a specific structure with confidence and rects, caps results at ~40KB with truncation behavior, and clarifies that rects are pixel coordinates aligned with android_ui_tree. No contradiction with annotations; it enriches 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?

The description is dense but well-structured: it leads with the core purpose and use cases, then moves to output structure and constraints. Every sentence contributes new information, but it is longer than strictly necessary—some details (e.g., compile path) could be trimmed without loss. Still, it's front-loaded with the most decision-relevant information and avoids redundancy.

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?

Given there is no output schema, the description fully compensates by detailing the return shape: {device, screen size in PIXELS, items:[{text, confidence, rect}]}, explains coordinate space (top-left origin, same as android_ui_tree bounds), confidence sorting, truncation behavior, and edge cases (icon-only controls). The agent has all information needed to invoke and interpret results correctly.

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% (all 3 parameters described), but the description adds practical meaning that goes beyond the schema: query is case-insensitive substring, serial defaults to currently streamed or only connected device, min_confidence defaults to 0.3 with guidance on raising/lowering to control noise. It also explains how parameters relate to the 40KB cap (narrow with query or raise min_confidence), which is not in the schema.

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 clearly states the tool performs OCR on the current Android screen using a Vision helper, and explicitly contrasts it with android_ui_tree by explaining it handles cases where UI tree labels are absent (Compose without semantics, Flutter, WebView, etc.). It specifies the resource (current screen), the action (OCR), and the distinguishing use case, making it unmistakable from sibling tools.

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?

It provides explicit when-to-use guidance: 'Use this when android_ui_tree returns no labels... for text rendered as graphics... or to independently verify what is on screen.' It also tells the agent what NOT to use it for: 'Icon-only controls carry no OCR text: look for their content-desc in android_ui_tree, or use android_ui_rows.' This is a model of prescriptive usage guidance with clear alternatives.

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

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

Annotations already mark this as destructive (destructiveHint=true) and not read-only. The description adds valuable context: device content is untrusted, and the agent should never guess ambiguous controls or enter secrets. It also notes that non-ASCII text requires ADBKeyboard, which is a significant behavioral caveat beyond the schema.

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 description is a single sentence but packs the core actions and a critical safety warning. It is front-loaded with the primary verbs. The sentence is long but not redundant; it earns its length.

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 9 parameters, only 1 required, and no output schema, the description adequately covers the interaction types, output (fresh screenshot), and safety constraints. It does not explicitly mention device selection, but that is fully documented in the schema. The description is sufficient for an agent to call it correctly.

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 input schema has 100% coverage of all parameters with detailed descriptions, including normalization, required conditions, and defaults. The description adds no new parameter semantics beyond what the schema already provides, so the baseline of 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?

The description states a clear verb ('Tap, type, press, drag, or scroll') and resource ('allowed Android target'), and specifies it returns a fresh MCP screenshot. It is distinct from specialized siblings like android_tap_element or android_tap_row because it targets raw coordinates/gestures, though it does not name these alternatives explicitly.

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 this is the general raw-input tool, but it does not explicitly contrast with sibling tools such as android_tap_element or android_tap_text. The caution 'never guess an ambiguous control' gives some guidance but no direct 'use this when...' routing.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false; the description adds value by disclosing the force-stop-on-relaunch behavior and the monkey-command mechanism, and by documenting that ambiguous name fragments produce a candidate list rather than a guess. No contradiction with annotations — destructiveHint aligns with the optional force-stop. Full burden is met.

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?

Well front-loaded with core purpose and mechanism, followed by parameter rules and sibling routing. The stable-package list at the end is useful reference material rather than padding. Slightly long, but every sentence earns its place; nothing is redundant.

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?

Complete for a launch tool given strong schema and annotations. The description covers mutual exclusion, resolution ambiguity (candidate list), which sibling to use when, and fallback strategy for unknown packages. The only minor gap is no explicit return-value description, but with no output schema and a simple launch action, this is a small omission.

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% and each parameter is well documented, so baseline is 3. The description adds meaningful value beyond the schema: the case-insensitive fragment resolution rule, the candidate-list fallback behavior, and the first-party stable package-name list that lets an agent skip android_list_apps for common packages.

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 ('Launch an already-installed app by resolving its LAUNCHER activity') and distinguishes itself from android_build_run (build/install) and android_list_apps (listing). An agent can immediately tell what this tool does and what it is not for.

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 routes usage: 'Use this to OPEN an app; android_build_run is for building and installing one from source' and instructs 'run android_list_apps first when unsure' for unstable third-party package names. The EITHER/OR parameter rule is also spelled out ('Pass EITHER packageName OR name').

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false. The description adds valuable behavioral details: listing fails by throwing rather than returning empty, so count:0 is meaningful; user-installed only by default; concurrency-safe. These go beyond annotations and help the agent understand edge cases.

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 description is information-dense but every sentence carries purpose. It front-loads the core action and purpose, then dives into filtering and failure behavior. Slightly long, but no fluff; the structure (purpose → query warning → system packages → failure semantics → concurrency) is logical and easy to parse.

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 three parameters, no output schema, and moderate complexity, the description covers everything an agent needs: what it lists, what fields are enriched, filtering semantics, the failure mode, and concurrency. The rationale for not matching labels is especially helpful for agents interacting with non-English UIs. No missing critical information.

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 covers all parameters with descriptions (100%). The description adds extra nuance: query is case-insensitive substring against package name and explicitly warns that display labels will never match (since Android exposes no label over adb). It also clarifies the semantics of include_system and the default of device selection, which the schema already states but the description reinforces with real-world context.

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 and resource: 'List the packages INSTALLED on a device', and immediately clarifies it's an enriched pm list. It distinguishes itself from siblings by explicitly noting it should run before opening an app because package names cannot be guessed, which differentiates it from android_launch_app and android_app_info.

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 explicit when-to-use guidance: 'Run this BEFORE opening an app' and explains why (package name cannot be guessed). It also provides an alternative for opening by label (android_find_text + android_tap_text) when labels don't match. The include_system parameter is explained with the context of what 'open <app>' means, making usage clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, and the description adds substantial behavior beyond them: output is capped at ~300 lines/30 KB with a truncated:true flag plus a narrowing hint, the snapshot start timestamp is computed on the DEVICE clock (default last 2m), follow mode closes after duration_seconds and returns everything accumulated, and bundle_id requires a RUNNING process resolved via pidof. This is exceptionally transparent for an agent to reason about tool side effects and resource use.

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 description is long but every sentence carries a distinct behavioral fact — no filler, no repetition of the schema. It is front-loaded with purpose, then mode semantics, then narrowing, then output caps. Slightly dense, but each clause earns its place and nothing is repeated from the input-schema documentation.

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 9-parameter, 3-enum, bound-mode tool with no output schema, the description covers the essential contract: boundedness in both modes, return caps and truncation signal, clock semantics, buffer selection for crash/events, and the running-process prerequisite for bundle_id. Minor omissions exist (e.g., the exact full return shape beyond truncated:true), but nothing an agent needs to call 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 baseline is 3, but the description adds genuine behavior beyond the schema: it explains the ring-buffer persistence, default window semantics, the follow-window closing behavior, the --pid resolution mechanism behind bundle_id, and the truncation/narrowing response. These details are not in the schema and materially change how an agent would set parameters.

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 opens with a specific verb+resource: 'Read what an Android app prints while it runs, from logcat.' It also nails the scope precisely (bounded, never unbounded), and none of the 18 sibling tools are log readers, so it is unambiguous which tool an agent should pick for log inspection.

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?

Gives clear mode-selection guidance (snapshot vs follow) with defaults and bounds, and explicitly routes crash reading to buffer:'crash'. It also advises narrowing before widening because an idle emulator emits hundreds of lines a second, and documents the fallback behavior when a bundle_id targets a non-running app ('suggests grep'). It doesn't name sibling alternatives, but no sibling competes for this job, so exclusions are unnecessary.

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

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

Beyond the annotations (readOnlyHint, idempotentHint, etc.), the description adds valuable behavioral details: it states the app must be running, otherwise the tool says so instead of returning zero, and it explains how to interpret PSS for leak detection. This adds context not present in annotations.

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 description is two sentences and front-loads the core function. The second sentence is somewhat long but packs useful interpretation and the running requirement without redundancy. Every sentence contributes value.

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 read-only metric tool with no output schema, the description adequately covers what the result means, how to interpret it, and a critical precondition. It does not enumerate every output field, but that is not required for correct invocation.

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 input schema already covers both parameters (`device` and `package_name`) with descriptions. The tool description does not add extra parameter-level meaning beyond what the schema provides, which is acceptable given 100% schema coverage.

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 clear verb ('Read'), a specific resource (`dumpsys meminfo <package>`), and explicitly names the key output metric (TOTAL PSS) and the breakdown categories. It is clearly distinct from sibling tools like android_processes or android_app_info, avoiding ambiguity.

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 provides concrete guidance on when to use the tool (for detecting memory leaks by watching TOTAL PSS trend) and a key prerequisite (the app must be running). It does not explicitly name alternative tools, but the context of memory leak analysis makes its intended use clear.

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

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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description adds valuable context: the failure mode ('throws with the reason rather than returning an empty list') and the naming convention for app processes, which aids interpretation of results. No contradiction with annotations.

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?

Four sentences, each earning its place: purpose, naming context/usefulness, filter usage, and failure behavior. Front-loaded with the core purpose and scoped with practical guidance. No fluff.

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 listing tool with no output schema, the description covers the return values ('pid and process name'), the naming convention, filter behavior, and error handling. An agent can call this tool correctly with full confidence. Nothing essential 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 description coverage is 100%: both `device` and `filter` are fully documented in the input schema, including default behavior and examples. The description restates the filter behavior but does not add new semantic detail beyond what the schema provides. Baseline of 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 ('List') and resource ('processes running on a device'), then clarifies the exact purpose: 'this is how you confirm an app is actually running and find the pid other tools want.' This clearly distinguishes it from sibling tools like android_list_apps, which lists installed apps, not running processes.

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?

Provides explicit context for when to use it: 'confirm an app is actually running and find the pid other tools want.' It also specifies filter behavior and omitting the filter to list everything. No exclusion or explicit alternative is named, but the usage scenario is clear enough for an agent to route correctly.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, destructiveHint=false. The description adds the cleanup behavior of the temporary PNG file, which is not captured in annotations, providing extra transparency about side effects beyond the safety profile.

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 sentences with no filler. The primary purpose is front-loaded in the first sentence, and the cleanup note is a concise second sentence that adds valuable context without redundancy.

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 read-only tool with one optional parameter and no output schema, the description sufficiently explains what is returned and the cleanup behavior. The schema handles parameter details, and annotations cover safety, leaving no critical information missing for correct invocation.

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% for the single parameter 'device'. The description adds no additional semantic detail beyond what the schema already provides, so the baseline of 3 applies.

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 'capture' with resource 'Android display' and explicitly mentions the return format (ImageContent plus structured metadata). Clearly distinguishes from UI-tree or interaction tools among siblings.

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?

Implied usage for visual capture, but no explicit when-to-use or when-not-to-use guidance. Does not reference any of the 18 sibling tools or conditions that would select this tool over android_ui_tree or android_interact.

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

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

Annotations declare destructiveHint=true and readOnlyHint=false, and the description does not contradict that. It adds behavioral detail beyond annotations: it stops the 'private frame source' and insists that physical devices are refused. These specifics give the agent a clearer picture of what will happen, though it doesn't mention side effects like data loss, which are implied by 'power off'.

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 description is two sentences with no filler. The primary action is front-loaded ('Stop the private frame source and power off'), and the exclusion (physical devices) is a single, compact second sentence. 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 one-parameter destructive tool, the description covers the essentials: what it does, that it targets emulators only, and that it refuses physical devices. It could mention that the emulator must be running or that the action is irreversible, but those are predictable from the tool's nature. Given the schema and annotations, it is sufficiently complete.

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%: the device parameter already has a descriptive text ('Emulator serial to power off, e.g. "emulator-5554" (from android_devices).'). The tool description itself adds no parameter-level information, so with full schema coverage the baseline of 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?

The description clearly states the action ('Stop the private frame source and power off') and the resource ('an Android emulator'), and explicitly distinguishes from physical devices by saying they are 'always refused'. This is a specific verb+resource pair that separates it from siblings like android_boot or android_devices.

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?

It gives a clear exclusion: physical devices are refused, implying it is for emulators only. This is useful when-to-not-use guidance. However, it does not explicitly name alternative tools or state when to use this instead (e.g., for cleanup after testing). The context is clear from the purpose, so it earns a 4 rather than 3.

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

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

Annotations only indicate destructive=true and non-readonly. The description adds extensive behavioral details: exact-match-then-substring matching, duplicate collapse to outermost clickable node, on-screen/enabled restrictions, allow_offscreen behavior, tap on center, ~300ms screenshot delay, and the polling mechanism with expect_text/expect_gone. It even specifies failure behaviors (actionable message) and disabled-node refusal. This far exceeds what annotations provide.

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 description is long but every sentence serves a purpose, covering matching, duplicate handling, failure modes, and assertion guidance. It is structured logically: purpose, matching rules, tap behavior, confirmation methods. While verbose, the complexity justifies the length; it is front-loaded with the core purpose and avoids fluff.

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 explains the return shape (screenshot summary like android_interact, expected.matched field), covers error scenarios, and gives actionable alternatives. It fully equips an agent to invoke the tool correctly, including edge cases (offscreen, disabled, duplicate matches, assertion polling). Nothing important 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?

The input schema has 100% coverage with detailed descriptions for every parameter (e.g., exact match then substring, default serial logic, mutually exclusive expect params, allow_offscreen semantics). The tool description reinforces some of this but adds little new per-parameter meaning. Since the schema already carries the load, a baseline 3 is appropriate; no major gaps exist.

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 (tap) and resource (a view on an Android device/emulator) and explicitly differentiates from raw-coordinate approaches by saying 'by IDENTITY instead of raw coordinates'. It also names the matching criteria (resource-id, label, content-desc) and is clearly distinct from siblings like android_tap_row or android_tap_text.

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 usage context: it's for tapping by identity rather than coordinates, and it explicitly instructs how to confirm a tap using expect_text/expect_gone instead of image comparison. However, it doesn't explicitly name sibling alternatives (e.g., android_tap_row) or state when NOT to use this tool, leaving some inference. Still, the context is clear enough for correct selection.

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

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

The annotations already flag destructive/non-idempotent behavior, but the description adds substantial context: the safety gate with out-of-range failure, the ~800ms verification delay, the refusal when the counter key is absent, and the explicit 'do not screenshot-and-compare pixels'. It discloses real consequences and verification semantics well beyond the structured metadata.

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 description is fairly long but every section serves a purpose: purpose, usage, safety, verification, and anti-screenshot guidance. It is front-loaded with the main capability and then layers details logically. While not terse, the length is justified by the tool's complexity and the need to convey safety-critical behavior.

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 5-parameter tool with a nested object and no output schema, the description covers all essential aspects: the coordinate system, the row index handling, the serial parameter, expect_count's semantics and failure modes, and the meaning of the verification result. An agent has everything needed to call it correctly and interpret outcomes.

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 covers all parameters with descriptions, giving a baseline of 3. The description adds value by clarifying the meaning of x/y fractions relative to the row frame, the semantics of row index (exact match, fail on out-of-range), and the detailed behavior of expect_count including the refusal logic and countCheck.verified result. It enhances comprehension without redundancy.

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 ('tap') and resource ('one visible list row reported by android_ui_rows') and precisely defines the input as a 0-based row index plus fractional coordinates. It explicitly contrasts with identifiable-element tools, making its purpose unambiguous and distinct from siblings.

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?

It clearly states when to use this tool: to reach per-item controls that are NOT identifiable elements, contrasting with element-based tapping. It also advises preferring expect_count whenever counters exist, and explains that without it the tap still works but is unverified. This gives actionable selection criteria and a strong recommendation.

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

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

Annotations already mark destructiveHint=true, but the description adds crucial context: 'On a real phone every tap has real consequences (posts, likes, purchases, messages): NEVER tap an unidentified control to find out what it does.' It also explains the matching rules, the 300ms wait, the screenshot refresh, the polling behavior for expect_text/expect_gone, and the pixel-coordinate detail (no scale/rotation inverse). This goes well beyond the annotations by describing exactly what happens during execution, which is essential for a destructive action.

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 description is dense but well-structured. It front-loads the core action, then layers matching rules, usage guidance, cautionary notes, technical pixel details, and confirmation method. Every sentence adds value; there is no redundancy or filler. Despite its length, it remains readable and purposeful.

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?

This is a complex tool (OCR, tapping, polling, ambiguity handling) with no output schema, so the description must carry the burden of explaining behavior and return values. It does: it mentions the fresh screenshot summary shape (same as android_interact), the expected.matched report, and the candidate-list error for ambiguous matches. It also covers the safety stop condition. For an agent to call this correctly, nothing essential 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 covers 100% of parameters with descriptions, so baseline is 3. The description adds meaningful semantics for the key parameters: it explains the query matching rules (exact → case-insensitive-contains → candidate-list ambiguity), and clarifies the purpose of expect_text/expect_gone as a single-round-trip confirmation mechanism. It doesn't repeat schema details but enriches them with usage context, justifying a score above baseline.

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 exactly what the tool does: OCR the current screen and tap the center of the best text match, with specific matching rules that mirror android_tap_element. It also clearly differentiates this tool from its sibling by specifying it works for text the view hierarchy cannot see, and explicitly says to prefer android_tap_element when resource-id or content-desc exists. This is a specific verb+resource+scope that leaves no ambiguity.

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 explicit guidance on when to use this tool vs android_tap_element: 'Prefer android_tap_element whenever the control HAS a resource-id or content-desc: identity beats pixels.' It also warns against using this tool on unidentified controls and tells the agent to STOP and report instead. Additionally, it explicitly says not to screenshot-and-compare pixels to verify a tap, steering the agent to use expect_text/expect_gone instead. This is comprehensive usage direction.

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

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

Annotations already mark readOnlyHint and idempotentHint, but the description adds rich behavioral detail: row detection heuristics, counter parsing and round-tripping, offscreen row exclusion (omittedOffscreen), and the specific reason hints when no rows are found. This far exceeds annotation coverage.

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 description is dense but every sentence earns its place, covering purpose, row structure, usage guidance, and edge cases. It is front-loaded with the core function and then dives into specifics without redundancy.

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?

Despite having no output schema, the description fully explains the output structure (index, frame, label, counters), the row detection algorithm, counter round-tripping expectations, and the offscreen behavior. All critical context for correct invocation is present.

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% for the single serial parameter, and the description adds nothing beyond what the schema already states. Baseline 3 is appropriate since the schema fully documents the parameter.

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 clearly states the tool reads visible list/feed rows as ROWS instead of a raw view tree, differentiating it from android_ui_tree. It specifies the exact resource (rows) and the output structure, so an agent can instantly understand the tool's role.

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?

It explicitly says to use this for RecyclerView/ListView/LazyColumn screens and explains why android_tap_element fails on unlabeled controls within rows, while android_tap_row is the right companion. It also defines what qualifies as a row, giving implicit when-not-to-use guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds substantial behavioral context: flag reporting semantics (only interesting states), output cap at ~40 KB, truncation behavior, display size in pixels, and the installation-free nature. No contradiction; it enriches the annotation.

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?

Although lengthy, every sentence serves a distinct purpose: purpose, usage, flag semantics, truncation, troubleshooting, and related tools. The purpose is front-loaded, and the structure flows logically from operation to edge cases. Nothing is redundant.

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?

The description covers all essential aspects: what the tool returns, how to interpret flags, how to handle truncation, and what to do when no labels are present. Since there is no output schema, this level of detail is necessary and sufficient for correct invocation.

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 descriptions cover 100% of parameters, establishing a baseline of 3. The description adds value beyond the schema: filter also keeps ancestors, max_depth is contextualized with typical depth (15–30 levels), and serial default behavior is clarified. This justifies a score above baseline.

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 ('Dump') and resource ('the frontmost window's view hierarchy') and immediately differentiates itself from siblings by mentioning android_tap_element, android_ui_rows, and android_find_text. An agent can clearly understand what this tool does and how it differs.

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 instructs when to use the tool ('find a control by identity and tap it with android_tap_element') and when to avoid it (if no labels, 'only the last points at android_find_text'). It also directs the agent to android_ui_rows and android_tap_row for scrolling lists, leaving no ambiguity about the decision boundary.

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

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

The description adds non-obvious behavioral details beyond the annotations: it polls every ~600 ms, and a timeout is a normal matched:false answer, not an error. It also reveals that it uses the same capture+OCR pipeline as android_find_text, which helps set expectations. These are valuable clarifications that the readOnly/idempotent annotations do not cover.

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 description is well-structured and front-loaded with the core purpose, then explains polling, timeout semantics, and modes. Every sentence serves a purpose, and it is appropriately sized for the tool's complexity without redundancy.

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?

The description is quite complete for a 5-parameter tool with no output schema. It describes the polling behavior, timeout semantics, modes, and mentions the match result fields (text, confidence, pixel rect). However, it could be slightly more explicit about the exact return structure on non-match (e.g., whether 'matched' is always present), though it implies the shape via 'matched:false'. This is a minor gap.

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 repeats default values (e.g., timeout_ms default 8000, mode default 'appear') and serial fallback behavior, but adds little new meaning beyond what's in the parameter descriptions. It does provide helpful context around modes, but that's already in the schema. No significant extra value is added.

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 clearly states the tool waits until text appears or disappears on a connected Android device, using OCR polling. It explicitly contrasts with android_find_text (which does a one-shot search) and mentions the OCR pipeline, making it easy to distinguish from siblings like android_find_text and android_tap_text.

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 explicitly recommends using this tool to gate an action on a condition, instead of looping android_find_text or sleeping a guessed number of seconds. It also explains when to use 'appear' vs 'disappear' with concrete examples (screen loaded, toast, spinner, dialog), providing clear usage context.

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