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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions video sampling (fps, max_frames) but omits side effects, error behavior, required external services (LM Studio), and whether the operation is read-only or modifies anything. This is a significant gap for a tool that could have failure modes.

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 with a clear one-line purpose followed by a compact argument list. It is efficient and front-loaded, though the argument list could be slightly more terse. Overall, 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?

For a tool with 6 parameters and no output schema, the description explains the inputs well but omits what the tool returns (e.g., the VLM's answer text) and any runtime prerequisites (e.g., VLM server running, media files existing). Given the complexity, more guidance on expected output and preconditions would be needed for full completeness.

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 0%, so the description must fully explain parameters. It does so comprehensively: each of the six parameters (question, images, video, fps, max_frames, model) is given a meaningful, context-specific explanation, including defaults and purpose. This fully compensates for the schema's lack of descriptions.

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-resource pair: 'Ask the local LM Studio VLM about images or a video already on disk.' It distinguishes this tool from siblings like android_screenshot or android_ui_dump, which capture/display UI rather than analyze media. The scope is specific and unambiguous.

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 ('already on disk') but provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions. It doesn't mention prerequisites like having the VLM running or how this relates to media capture tools. Usage is inferable but not clearly stated.

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?

With no annotations provided, the description carries the transparency burden. It discloses the key behavioral trait—the screenshot is sent to LM Studio rather than returned into context—and specifies the return contract of PASS or FAIL. It does not mention failure modes or prerequisites like LM Studio availability, but the most surprising behavior is well covered.

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 compact and front-loaded: the first sentence states the core purpose, the second adds the cost/behavior context, and the Args list is terse. No redundant or filler text is present.

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-parameter tool with no output schema and no annotations, the description covers purpose, return values, and argument defaults. Minor gaps remain around error handling and the local VLM configuration prerequisite, but the essential information for a normal call 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 0%, so the Args section is the only source of meaning. It clarifies question as a yes/no claim with an example, states device as a serial defaulting to the first physical device, and identifies model as an LM Studio model id defaulting to the configured one. This strongly compensates for the bare 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 opens with a specific verb+resource: 'Check a claim about the current screen using the local VLM' and states the concrete outcome 'Returns PASS or FAIL'. This clearly differentiates it from capture/dump siblings like android_screenshot and android_ui_dump by focusing on assertion rather than raw output.

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 'cheap oracle' framing and the statement that 'the screenshot goes to LM Studio, not into your context' give clear context for when to use this tool: cheap screen verification without polluting the conversation. It does not explicitly list exclusions or name alternatives, so it stops short of full 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?

With no annotations, the description carries the full burden and meets it by disclosing daemon behavior, waiting, lock naming, uninstall data wiping, and idle daemon release. It also details the failure report contents, including source snippets and a markdown brief path for a fixer subagent.

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 organized into a terse imperative summary, a bold routing warning, failure-report detail, and a labeled Args block. Every sentence earns its place by providing selection guidance, behavioral transparency, or parameter meaning.

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 complex build tool with no output schema, the description explains both return behavior and all parameters, plus side effects like installation and locking. It leaves no significant gap an agent would need to guess about before invoking the tool.

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?

Despite 0% schema description coverage, the 'Args:' section explains all 10 parameters with defaults and intent, including task derivation and an example. It adds semantically rich guidance—such as release_locks not touching busy builds and allow_uninstall wiping data—that is not inferable from the bare 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 states a specific action—'Build the project with Gradle'—and immediately distinguishes the tool from sibling alternatives by emphasizing safety 'alongside Android Studio'. It also specifies the tool's unique failure-report behavior, making its role unmistakable.

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 routing guidance: 'ALWAYS use this instead of running gradlew in a terminal', with a concrete rationale about R.jar locking. It also advises on fast compile-only checks and lock release, giving agents actionable decision criteria.

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?

With no annotations, the description carries the full burden, and it does well by disclosing stack-frame-to-source mapping and the creation of a self-contained markdown brief for a fixer subagent. It also clarifies the 'only since last check' state and the physical-device default. It stops short of stating whether any persistent state is modified, but 'Show' strongly signals a read-only operation.

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 tightly organized with a two-sentence behavioral overview followed by a compact Args block. Every sentence adds information; there is no filler, and the most important output behavior is front-loaded.

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 no annotations, this description is remarkably complete: it covers all parameters, defaults, what output looks like, and how it benefits a fixer subagent. Nothing needed to invoke or interpret the tool's result is left unexplained.

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 0%, so the description must compensate, and it does. Every one of the five parameters gets a meaningful one-line explanation beyond its schema name, including important defaults and behavioral nuances such as 'project_dir' being the Gradle root for frame mapping and 'only_new' referencing automatic checks by interaction tools.

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 and resource: 'Show recent crashes and ANRs...with stack traces.' It explicitly enumerates Java exceptions, native signals, and not-responding, which sharply distinguishes it from general-purpose siblings like android_logcat. The added detail about mapping frames to source files and writing a fixer brief makes the tool's role unmistakable.

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 tool for crash/ANR investigation and gives useful defaults, but it does not explicitly state when to choose it over alternatives such as android_logcat or android_analyze. The only_new parameter offers partial usage context by mentioning interaction tools check automatically, but no direct 'use this when...' guidance is present.

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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only listing operation and explains default-device selection. However, it doesn't describe output format, potential failure modes (e.g., no devices attached), or whether the command can trigger side effects like AVD boot. The description adds some context but omits these details.

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 first sentence front-loads the action and resource, and the second adds practical usage guidance. Every clause 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 zero-parameter, no-output-schema discovery tool, the description is largely complete. It covers purpose, default-device behavior, and usage timing. Minor gaps (e.g., what happens when nothing is connected, or whether output includes AVD/device status) are not critical 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 tool has zero parameters, so the schema provides nothing to augment. The description compensates by explaining what is listed (physical devices and AVDs) and the default-device logic. This is a reasonable baseline for a parameterless tool, and the added context gives meaning beyond the empty 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 states a specific verb ('List') and resource ('attached Android devices and bootable emulator AVDs'). It also explains the default-device selection logic, distinguishing this tool from siblings like android_emulator_start and android_prepare. The purpose is unambiguous.

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 clear guidance: 'Call this first when unsure what is connected.' It also explains how the default device is selected (first physical device, or ANDROID_AGENT_DEVICE if set). While it doesn't explicitly name alternatives or exclusions, this is sufficient for a zero-parameter discovery tool.

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?

With no annotations, the description must convey behavior. It does so by explaining that it blocks until boot is complete, and the parameters 'wait' and 'timeout' clarify the waiting behavior. It does not mention side effects like resource consumption or failure handling, but the essential behavior is disclosed.

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 extremely concise: a single sentence stating the purpose, followed by a clean, bulleted list of parameters with one-line explanations. Every word earns its place, and the key action is front-loaded.

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 that boots an emulator, the description covers the main behavior (boot and wait), the parameters, and even references a related sibling for listing AVDs. It lacks explicit failure behavior or what happens if the AVD doesn't exist, but given no output schema and the simplicity of the action, it is adequately 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?

The schema only provides parameter names and defaults, so the description's Args section adds crucial meaning: 'avd' is described as a name from android_devices, 'wait' blocks on sys.boot_completed, and 'timeout' sets the maximum wait. This compensates well for the lack of schema descriptions.

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 ('Boot') and the resource ('emulator AVD'), and explains the core behavior of waiting until ready. This distinguishes it from sibling tools like android_screenshot or android_tap, which operate on a running emulator rather than launching one.

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 for starting an emulator, and the reference to 'android_devices' for the AVD name provides context. However, it does not explicitly state when to prefer this over alternatives, such as when an emulator is already running or if you just need to check device status.

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?

With no annotations, the description carries full responsibility for behavioral disclosure. It clearly indicates that the tool lists daemons, identifies lock holders, and can optionally stop idle daemons. It also discloses safety constraints: busy daemons and the IDE are never stopped, and it explains the 'foreign' daemon concept. This is sufficient transparency for a diagnostic and conditional destructive tool, though it does not detail the output format or side effects beyond stopping.

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 front-loaded with the main purpose and then provides targeted context (the R.jar issue) and an Args section that explains parameters. Every sentence contributes to understanding when and how to use the tool. It could be slightly tighter, but the explanatory scenario adds practical value and is not 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?

Given no annotations and no output schema, the description covers the essential information: what the tool does, the common problem it addresses, parameter semantics, and safety guarantees. It does not specify the return format or behavior when project_dir is absent, which would be useful but not strictly necessary for a list/stop tool. Overall, it is complete enough for an agent to invoke 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?

Since the schema provides only parameter names and types with 0% description coverage, the description must add full meaning. It does: 'project_dir' is explained as 'Gradle root whose build outputs to check for locks,' and 'stop' lists all valid values with their meanings ('lockers', 'foreign', 'all-idle') and the default (None). This compensates well, though it leaves minor ambiguity about what happens when project_dir is omitted.

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 starts with a clear verb/resource: 'List Gradle and Kotlin daemons, show which ones lock a project's build outputs, optionally stop some.' It also explains a specific use case (the R.jar lock) and differentiates from sibling Android tools, none of which handle daemon management. This is a specific, well-scoped purpose.

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 ties the tool to a diagnosis scenario: 'Explains the classic "R.jar is being used by another process"' and details when each stop option is appropriate (e.g., 'foreign' for daemons that Studio can never reuse). It also states a safety boundary ('Busy daemons and the IDE are never stopped'), which guides appropriate use. However, it does not explicitly mention alternatives or when this tool should *not* be used, though none are apparent 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?

With no annotations provided, the description carries the full behavioral burden and does substantive work: it flags the destructive consequence of allow_uninstall with 'WIPES APP DATA', discloses that device 'defaults to the first physical device', and explains grant_permissions via '-g'. The critical side effects are surfaced, though some behaviors (e.g., behavior with no connected device, failure output) go unmentioned.

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?

One front-loaded summary sentence followed by a terse Args block. Every line earns its place: the data-wipe warning, the device default, and the -g flag are all packed in without filler. Slightly list-like formatting, but it is the minimal efficient size for a 7-parameter tool with zero schema descriptions.

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 7-parameter mutating tool with no annotations and no output schema, the description covers everything needed to invoke it correctly: all params explained, the destructive side effect called out, and defaults specified. Minor gaps (return value shape, prerequisite of a running device/emulator) keep it from a 5.

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 0%, yet the description documents all 7 parameters with operational meaning: the project_dir vs apk alternation, the 'Gradle root' relationship, the variant/module scoping, device defaulting, and the conflict-resolution semantics of allow_uninstall. This fully compensates for the empty 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?

Opens with a specific verb + resource: 'Install an already-built APK', and immediately disambiguates from the Gradle build lifecycle with '(no Gradle involved)'. In a sibling set containing android_build and android_prepare, this clearly positions the tool as the install step.

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 'already-built APK (no Gradle involved)' gives clear contextual usage: this is the post-build install step, and the agent should not expect compilation here. It states an exclusion but never names the alternative explicitly (e.g., 'use android_build to compile first'), so selection is clear context rather than explicit 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?

With no annotations, the description carries the full behavioral burden. It discloses that the KEYCODE_ prefix is auto-added and a raw keycode number works, and that a screenshot can be returned. However, it does not describe side effects of pressing (e.g., navigation), error conditions, or device selection behavior beyond the default, which is a notable gap for a tool with zero 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 compact and front-loaded with the purpose, followed by a clearly formatted argument list. Every sentence earns its place; there is no fluff or redundant content. The structure makes key details instantly scannable for an agent.

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 press-action tool with no output schema, the description covers core parameters well. However, it omits return value details (e.g., what happens when screenshot is false), potential errors, and any prerequisites like device connectivity. Given the simple nature, it's adequate but not fully 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?

Given the 0% schema description coverage, the description effectively explains each parameter: key lists valid values, device specifies serial default, screenshot indicates a screenshot return, and scale defines screenshot resolution. It adds meaning beyond the raw schema types, though it could be more exhaustive (e.g., valid key list is incomplete).

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 presses a hardware/system key, using a specific verb and resource. It distinguishes from sibling tools like tap, swipe, and type by focusing on hardware keys, though it doesn't explicitly name alternatives. The list of example keys adds specificity.

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 for hardware/system keys when touch or typing is not appropriate, but it does not explicitly state when to prefer this tool over android_tap, android_swipe, or android_type. No exclusions or preconditions are mentioned, leaving the agent to infer the context from the tool name and description.

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?

With no annotations, the description carries the full behavioral burden.; it does so well by disclosing that clear_first clears the buffer instead of reading and returns immediately, that grep is applied after retrieval, and that device defaults to the first physical device. It could go slightly further by describing the output shape, but the core behavioral traits are covered.

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 compact and well-structured: a one-sentence summary, a targeted routing note, and a clean args list. No sentence is wasted, and the most important behavioral facts are front-loaded before the parameter details.

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 and no annotations, the description covers all parameters principal behavior, defaults, and the key alternative tool. It does not explicitly describe the return format, but for a log-reading tool the output is largely self-evident; the completeness is high.

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 0%, so the description must fully compensate for parameter meaning, and it does. Each parameter gets a meaningful explanation: package scopes to the app's pid, device is a serial with a default, lines are trailing lines, grep is case-insensitive and post-hoc, and clear_first changes the action from reading to clearing.

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 and resource: 'Read recent logcat', and immediately states a key scoping detail ('scoped to one app's process by default'). It also distinguishes itself from the sibling android_crashes by naming the crash/ANR use case, so an agent can tell the tools apart without inspecting schemas.

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 'For crashes and ANRs prefer android_crashes', giving a clear when-not-to-use condition and an alternative. It also clarifies how to broaden or narrow scope ('Omit for all output' vs package scoping), which is practical usage 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?

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that it sets specific appops and permissions, optionally enables an accessibility service, and is safe to call repeatedly. It does not mention potential prerequisites (e.g., device connectivity, app installation) or the return value, but the core side effects are clearly stated. The repeated-call safety note adds practical value.

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 compact and front-loaded. The first line states the core purpose, the second lists concrete actions and safety, and the args block provides per-parameter clarity. There is no redundancy or filler—every sentence serves a purpose.

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 sparse annotations, the description covers the essential aspects: what it does, what it sets, and parameter meanings. It omits details like return value or setup requirements, but these are less critical for a permission-granting tool. Overall, an agent can reasonably infer how to invoke 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?

Schema coverage is 0%, so the description must explain all three parameters. It does so effectively: 'package' with an example, 'device' with a default behavior, and 'accessibility_service' with a fully-qualified service example. This goes beyond the bare parameter names and adds practical guidance, though it could benefit from noting format constraints or validation rules.

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 ('Grant'), a specific resource ('special permissions that pm grant cannot'), and enumerates the exact permissions it sets (usage-stats, overlay appops, POST_NOTIFICATIONS, optional accessibility service). It is unambiguous and distinguishes itself from all sibling tools, which deal with emulator control, UI interaction, or device info rather than permission management.

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 frames when to use it: when `pm grant` cannot grant the needed permissions, to make an app testable. It also notes that it is safe to call repeatedly, which implies idempotency. It does not list alternative tools or explicit 'when not to use' cases, but given the unique scope and clear purpose, the context is sufficient for an agent to select it appropriately.

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?

No annotations are provided, so the description carries the full burden. It discloses the max_seconds hard cap (180s), the device default, and that size shrinks the capture. It could add more about side effects or failure modes, but the disclosed traits are meaningful.

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 short and front-loaded, with a one-line purpose, a workflow sentence, and a compact args list. No filler; 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?

For a start tool paired with android_record_stop, the description covers the invocation and workflow sufficiently. It lacks explicit notes on invalid inputs or output handling, but with no output schema those are less critical.

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 0%, so the description must compensate. It does so by adding meaning to all three parameters: device default, max_seconds cap, and size format/purpose. This goes well beyond the bare 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 opens with 'Start recording the screen', a specific verb-resource pair, and names the companion android_record_stop, which distinguishes it from siblings like android_screenshot and android_ui_dump. The purpose is immediately clear.

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 workflow guidance: record first, interact, then stop. However, it does not state when to prefer recording over alternatives like screenshots or when not to use it, so it stops short of a full 5.

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?

No annotations are provided, so the description carries the burden. It discloses that video is sampled into frames, sent to LM Studio, and returns a paragraph, which is meaningful beyond the stop action. It doesn't cover side effects like whether the recording file is deleted, but the main processing behavior is transparent.

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 appropriately sized, front-loads the purpose, and uses a concise bulleted Args section. Every sentence adds value, including the rationale about avoiding context flooding.

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 no output schema and no annotations, the description covers purpose, process, parameters, and expected output (a paragraph). No critical call information 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 0%, so the description must compensate. It does: the Args section explains handle, analyze, fps, max_frames, and model with defaults and semantics, fully covering the parameters beyond 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?

States the specific action (stop a recording) and the subsequent VLM analysis, clearly distinguishing it from the sibling android_record_start. The verb-resource combination is unambiguous and the purpose is not a tautology.

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 reference to handle coming from android_record_start implies the tool is the counterpart to the start tool, but it doesn't explicitly name alternatives like android_analyze or state when not to use it. The usage context is clear but lacks explicit 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?

No annotations are provided, so the description carries the full burden. It mentions that the full-res image is saved to disk, which is useful, and that 'analyze' runs the shot through a VLM. However, it doesn't disclose potential side effects (e.g., does it alter device state? does it require a connected device?), the exact return format (though it says 'image you can look at'), or any latency/rate concerns. This is a gap for a tool with no 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 concise and structured with a clear summary sentence then bullet-like parameter info. It front-loads the primary purpose and keeps each line focused. No wasted words.

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 the tool's moderate complexity (3 optional params, no output schema, no annotations), the description covers the essentials: what it does, how to control scale, and the optional analyze feature. It doesn't mention error conditions or return format details, but for a screenshot tool that's acceptable. The save-to-disk behavior is disclosed. It feels nearly 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?

The schema has no descriptions for any parameters (0% coverage), so the description must compensate. It does: 'Device serial; defaults to the first physical device', 'Long-edge px for the returned image (full-res is saved to disk regardless)', and 'Optional question - also runs the shot through the local LM Studio VLM'. These add meaning beyond the schema's type/default.

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 ('Capture') and resource ('the screen'), and mentions it returns an image. It distinguishes itself from siblings like android_ui_dump (which dumps UI hierarchy) and android_record_start (which records video), though it doesn't name alternatives explicitly. It could be more specific by contrasting with these 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?

The description implies usage: it's for capturing a screenshot for direct visual inspection. It mentions optional parameters like scale and analyze, but doesn't explicitly say when to use this vs alternatives (e.g., when you need to see visual state vs UI hierarchy). No exclusions are 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does well: it explains the side effects of reinstall (build+install), fresh (pm clear wiping data), and the conditional behavior on build failure (full build report) and crash (stack trace mapped to source). It also notes that activity is resolved automatically if omitted. It doesn't mention whether the session holds locks or how long it runs, but the disclosed behaviors are substantial and directly useful.

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: a concise opening sentence, a clear 'main entry point' statement, return-value explanation, failure-mode handling, and a compact parameter list. It is slightly long but every sentence earns its place, and the parameter list is scannable. The only minor issue is that the parameter explanations could be more compact, but overall it is appropriately sized for an 11-parameter tool.

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 the tool's complexity (11 params, no output schema, no annotations), the description covers the essential context: what it returns, failure modes, and parameter semantics. It doesn't describe the exact format of the UI dump or how the screenshot is returned, but the description explicitly says the screenshot is 'an image you can see directly,' which is enough for an agent. The lack of an output schema is partially compensated by the return-value description, so this is solid but not perfect.

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 0%, so the description must compensate, and it does. It explains the meaning of package, activity, device, project_dir, reinstall, fresh, module/variant, release_locks/allow_uninstall, and scale in plain language, adding context beyond the bare schema titles. It doesn't give exact formats for device serial or project_dir, but the explanations are sufficient for an agent to invoke the tool correctly.

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 ('Start a driving session') and resource (Android app session), and clearly distinguishes it as 'the main entry point' from siblings like android_screenshot, android_ui_dump, android_build, and android_install. It also explains what the tool returns (screenshot + UI dump) and how it handles failure cases, making its purpose unmistakable.

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 says 'This is the main entry point,' which signals when to use it relative to siblings. It also explains that reinstall requires project_dir and that crash stack traces are mapped only when project_dir is provided. However, it does not explicitly state when NOT to use it or name alternative tools for specific sub-tasks (e.g., use android_screenshot for just a screenshot), so it falls short of a 5.

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?

With no annotations, the description carries the behavioral burden. It does add useful context: direction gestures are scroll-sized to the screen, 'down' moves content downward while the finger moves up, longer durations are gentler, and a screenshot can be returned. However, it does not disclose whether the action is synchronous, whether it can trigger navigation or other side effects, or any required session/device 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?

The description is a compact two-part structure: a one-sentence purpose statement followed by a concise argument list. Each line is informative and there is no filler. The most important scope information is front-loaded.

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 parameters and some behavioral nuances, but several gaps remain: the coordinate system is unspecified, the mutual exclusivity of direction and coordinates is only implied, and no mention is made of prerequisites like an active Android session or device selection guarantees. For a complex 9-parameter tool with no annotations or output schema, this is adequate but not fully 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 0%, so the description is solely responsible for parameter meaning. Every one of the 9 parameters is explained in plain terms, often with valuable detail: direction options and their semantics, coordinates as start/end points, duration gentleness, device default, and screenshot scale meaning. This goes well beyond the bare 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 states a specific verb ('Swipe or scroll') and the resource (screen/device), and immediately clarifies the two modes: by direction or by explicit coordinates. This clearly distinguishes it from sibling tools like android_tap, android_type, and android_key without needing to inspect schemas.

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 explicit guidance on when to use swipe versus alternatives such as tap or type. It explains how to configure the gesture but not under what circumstances an agent should choose this tool over a sibling. The only usage hint is the implied 'used when direction is omitted,' which is parameter-routing, not tool-selection 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?

With no annotations present, the description carries the full behavioral burden: it states the tap action, how stale refs are re-resolved, that a screenshot can be returned, and the screenshot's scale behavior. It does not mention side effects or preconditions, but for a UI tap tool the core behavior is disclosed.

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 one-sentence purpose is front-loaded, then a compact Args block covers the parameters without fluff. Every sentence provides operational detail; no repeated or irrelevant information.

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 mutating interaction tool with no output schema, the description is mostly complete: it defines the targeting modes, device default, and screenshot options. A minor gap is that it does not explicitly state that one of ref/text/coordinates is required, which would fully prevent an empty call.

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 0%, and the description fully compensates by explaining all seven parameters, including the source of ref ('android_ui_dump'), the matching semantics of text (visible text or content-desc), default device behavior, and the screenshot/scale meanings. Each parameter's purpose is concrete with an example.

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 concrete action ('Tap the screen') and enumerates the three supported targeting modes (ref, text, coordinates), making the tool's resource and behavior unambiguous. It is clearly distinguishable from sibling input tools like android_swipe or android_type.

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 practical selection guidance among modes (ref from a dump, text/content-desc, or raw coordinates when the hierarchy exposes nothing tappable). It does not explicitly contrast this tool with swipe/type/key siblings, so a small exclusion-based guidance gap remains.

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?

With no annotations provided, the description carries the full burden and does disclose key behaviors: ASCII-only limitation, optional pre-tap via ref, ENTER submission, screenshot return, and device defaulting. It could add what happens with unfocused fields or invalid refs, but the disclosed constraints are sufficient for safe invocation.

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 tightly structured: a one-sentence behavioral summary, a critical limitation, then a bullet-style arg list. Every line adds necessary information; there is no filler or redundant restatement of schema fields.

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 6-parameter tool with no annotations and no output schema, the description covers the essential selection and invocation context: what it does, the ASCII constraint, all parameter meanings, and screenshot behavior. It does not document error cases or the exact return payload beyond the screenshot, but it is largely complete for practical agent use.

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 0%, so the description must compensate, and it does: every parameter (text, ref, device, submit, screenshot, scale) receives a concise semantic explanation beyond its name/type. It clarifies defaults, side effects, and the meaning of scale as long-edge pixels, which is high-value guidance.

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 and resource: 'Type text into the focused field, optionally tapping a field first.' This clearly distinguishes the tool from siblings like android_tap (taps only) and android_key (sends key events), making its purpose unambiguous.

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 clearly states the tool is for typing text into a focused field and that a ref can optionally be tapped first to focus it. It does not explicitly name alternatives or when not to use it, but the usage context is clear and actionable. The ASCII-only note also helps the agent avoid sending unsupported input.

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?

No annotations are provided, so the description carries the full burden. It discloses the output format (table with ref, text, content-desc, class, centre point, bounds), the Compose limitation (no resource-ids), and the failure behavior (no nodes -> fallback). It does not explicitly state that the tool is read-only, but the verb 'Dump' and the output description imply a non-mutating inspection. The behavioral context is strong, though it could explicitly state that this is a safe/read-only operation.

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 compact and front-loaded: the first sentence states the core function, the second explains the output rows, and the following sentences add usage guidance and parameter details. Every sentence earns its place, and the structure moves from what to how to when. No fluff or repetition.

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 2 optional parameters, no output schema, and no annotations, the description covers the essential context: what the output looks like, how to use the refs, the Compose caveat, and the fallback path. It could be slightly more complete by explicitly stating the read-only nature and any prerequisites (e.g., an active session/device), but the core information an agent needs to select and invoke the tool correctly 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 0%, so the description must compensate. It explains 'device' (serial, defaults to first physical device) and 'compact' (show only interactive/labelled nodes, recommended). Both parameters are meaningfully described beyond their schema definitions. The only minor gap is that it doesn't specify the exact format of the device serial or what 'first physical device' means in a multi-device setup, but the guidance is sufficient for an agent.

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'), a specific resource ('on-screen accessibility hierarchy'), and the output form ('table of tappable refs'). It also distinguishes itself from pixel-coordinate guessing and from sibling tools like android_screenshot and android_tap by explaining what the refs are for. This is a clear, non-tautological purpose statement.

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 says when to use this tool ('Prefer this over guessing pixel coordinates') and provides a fallback path ('If a screen returns no nodes, fall back to android_screenshot and tap by x/y'). It also gives a practical tip for Jetpack Compose apps (match on text/content-desc). This is strong usage guidance with both a when-to-use and a when-not-to-use/alternative.

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?

No annotations are provided, so the description carries the burden of behavioral disclosure. It explains that calls are recorded in a specific file (~/.android-agent/vlm-calls.jsonl) and that images are saved next to it, which is useful context. However, it does not describe the return format or pagination behavior, and it doesn't mention any side effects or limitations. The description gives some insight into behavior but is not comprehensive.

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 with a clear opening sentence, followed by a paragraph on storage details, and a list of arguments. It is front-loaded with the main purpose. However, the storage details are a bit verbose and might not be essential for the user's immediate understanding of how to use the tool. The argument list is efficient, but the overall length could be trimmed without losing 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?

Given the tool's moderate complexity (3 parameters, no output schema), the description covers the main aspects: purpose, storage location, and parameter meanings. It also mentions which tools use the local model, which is helpful for context. However, it lacks details on the return format or how to interpret the output, which could be important for an agent deciding how to use the tool. But overall, it's fairly complete for the tool's scope.

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 0% description coverage, meaning the schema provides no descriptions for the parameters. The description does help by explaining what 'last' means (how many recent calls to show) and what 'call' accepts (an id or run/id combination). However, it doesn't clarify the 'full' parameter's effect (it says 'Show full prompts and answers' but doesn't detail the format). The description partially compensates for the lack of schema descriptions but could be more detailed.

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's purpose: showing local-model (LM Studio) calls made by which tool, and what the model saw and said. It uses a specific verb ('Show') and a specific resource ('local-model calls'), and it distinguishes itself from siblings by focusing on VLM log details. It names which tools use the local model (android_screenshot, android_assert, android_record_stop, android_analyze), making its scope explicit.

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 clear context on what the tool does and mentions the tools that use the local model, but it does not explicitly state when to use this tool versus other logging or inspection tools (like android_logcat). There is no alternative mentioned or guidance on when not to use it. The use case is implied (debugging VLM calls) but not contrasted with 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?

With no annotations provided, the description must carry the full burden. It discloses the core behavior (waiting for delay or condition) and the polling nature, but it omits important details like what happens on timeout, whether errors are raised, and whether the tool returns a value. The timeout_ms parameter is mentioned but not explained in terms of consequences when exceeded. This is a moderate gap given the lack of 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 concise and well-structured: a one-sentence summary of functionality, a usage tip, and a clear arg list. Every sentence adds value, and the most important information (purpose and alternative usage) is front-loaded. No fluff or 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 the tool's moderate complexity (5 optional params, no output schema), the description covers all parameters and the core behavior. However, it lacks guidance on edge cases like what happens when both ms and until_text are provided, or the exact timeout behavior (exception vs silent return). These are minor gaps but would help an agent anticipate outcomes. Overall, it is nearly 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 description coverage is 0%, but the description compensates fully by explaining each parameter: ms (fixed sleep), until_text (poll until present), until_gone (poll until absent), timeout_ms (give up after), and device (defaults to first physical device). This adds meaning well beyond the schema's bare types, clarifying units, defaults, and semantics.

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 and resource: 'Wait for a fixed delay, or until some text appears or disappears.' It explicitly differentiates itself from screenshotting mid-animation and lists three modes, making its purpose unambiguous. The mention of 'content-desc' and 'poll' further distinguishes it from sibling tools like android_screenshot and android_ui_dump.

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 a specific usage scenario: 'Use this instead of screenshotting into the middle of an animation.' It also explains the three polling modes, which implies when each should be used. However, it does not explicitly state when not to use the tool or mention alternative tools beyond screenshotting, so it's not fully comprehensive but gives clear context.

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