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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one useful behavioral fact beyond that: results are limited to third-party packages, so system apps will be absent. It says nothing about ordering, pagination behavior, or what happens when no apps match.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with the primary purpose front-loaded and the critical caveat attached via a semicolon. Every clause earns its place; nothing is padded or repeated from the schema.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter read tool with annotations covering safety and no output schema, the definition conveys what is returned (installed third-party package IDs) and the key matching caveat. The remaining gap is behavioral detail on limit/pagination and match semantics, which is minor but real given the 0% schema coverage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so the description carries the full burden. It does explain the most error-prone parameter (query targets package IDs, not display names), but leaves `limit` completely unexplained and does not clarify whether query is exact-match, prefix, or substring, nor that limit defaults to 100 and caps at 500.

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?

"List installed third-party package IDs" gives a specific verb (list) and a precisely scoped resource (third-party package IDs), which distinguishes it from the action-oriented siblings like aua_launch_app or aua_tap. It stops short of naming an explicit sibling to route to, but the scope 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 note that the query matches package ID rather than human app name is a genuine usage constraint that prevents a common misuse, implying this tool is a discovery step before launching apps. However, there is no explicit "use this when..." guidance, no mention of pairing with aua_launch_app, and no note that system apps are excluded.

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 flag mutation (readOnlyHint=false), open-world behavior and non-idempotence; the description goes well beyond that by disclosing pre-execution validation, the exact stop conditions (error, wait timeout, Enter submission, 25s budget), and resume/skip semantics. The main remaining gap is what the result contains (presumably a stopped_at marker), which is not stated.

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 short sentences, each carrying distinct information: capability, validation guarantee, stop conditions, and resume rule. Nothing is repeated from the schema or annotations, and the most load-bearing constraints (validation, stop, resume) are 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 single-parameter batching tool with open-world, non-idempotent semantics, the description covers validation, failure behavior, budget limits, and recovery. It is slightly incomplete in not describing the return payload or whether state must be primed first (e.g. via aua_ready), but no output schema exists to cover that.

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 single 'steps' parameter is only structurally constrained (minItems 1, maxItems 20, op enum, free-form args). The description partially compensates by capping the batch at 20 and telling the agent to use 'each operation's normal args', pointing args semantics back to the per-operation sibling tools, but it does not explain arg contents or ordering/dependency 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 names a specific verb and resource ('Execute up to 20 known steps') plus scope (batch of known ops, each using its normal args). It implicitly separates itself from the single-action siblings by stressing 'known steps' and 'entire plan is validated before actions', though it never names a sibling 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?

Usage is implied through 'known steps' (use when the plan is already determined, not when discovery is needed) and 'Resume from stopped_at; never replay completed/uncertain steps', which gives a recovery path. However, no alternative tool is named for discovery (e.g. aua_find) and there is no explicit when-not guidance, so the agent must infer the boundary 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?

Annotations already declare readOnlyHint, idempotentHint, and openWorldHint, so the safety profile is covered. The description adds one genuinely new behavioral fact — that it does not start a phone service — but says nothing about failure modes (no device attached, ADB not authorized) or what the inventory contains.

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 short sentences, front-loaded with the positive capability and followed by the single most useful negative constraint. No filler, no restating of the title.

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, read-only diagnostic with full annotation coverage, this is nearly sufficient — an agent knows it is a safe local inspection call. The remaining gap is that no output schema exists and the description does not hint at what 'inventory and configuration' returns or how it behaves when no device is connected.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. No syntax or scoping detail is needed or missing.

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: 'Read local ADB device inventory and configuration.' That distinguishes it from the action-oriented siblings (aua_tap, aua_launch_app, aua_screen_action) as a diagnostic/read tool, though it never names a sibling explicitly and 'aua_doctor' alone would be opaque without the sentence.

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?

Usage is implied (run it to inspect device state/health) and one useful exclusion is given: 'Does not start a phone service,' which separates it from setup/ready/launch flows. However, there is no explicit statement of when to prefer it over aua_ready, aua_setup, or aua_observe, which are the closest 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 declare readOnly, idempotent, and openWorld, so safety is covered. The description adds the important behavioral detail that ambiguous matches need an index and that 'bounds don't prove unobstructed access' - a hint that found elements may be occluded - but that phrase is cryptic and the description never says whether results come back as a list, how truncation interacts with limit, or what the returned payload looks like.

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, front-loaded and free of padding, which is good. But the second sentence is compressed to the point of ambiguity - 'bounds don't prove unobstructed access' reads like an internal note rather than actionable guidance - so brevity comes at the cost of clarity.

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 and only read-only/idempotent annotations, the description is the sole source for return shape, result ordering, and limit semantics, and it supplies none of these. For a query tool with a 10-field nested selector and a capped limit, an agent cannot predict what a call will yield.

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 carries the full load, yet it only covers the string-matching subset of the Selector fields. It never explains limit (default 20, max 50) or truncation behavior, and omits the boolean filters (enabled, focused, clickable), the meaning of index inside the selector, and how exact versus *_contains fields differ.

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 the lookup fields (text, description, resource_id, class_name, package) and mentions substring matching, so the general idea of a query-by-selector tool comes through. But it never says what is being found (UI elements/widgets) or what the tool returns, so the agent must infer the resource from sibling names like aua_tap and aua_observe.

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 clause 'Multiple targets require an explicit 0-based index' gives conditional guidance for the multi-match case, which is genuinely useful. However, no alternative is named: it never says whether to use this versus aua_observe for inspection or whether aua_tap can take a selector directly, so the routing decision against siblings is left to inference.

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=false, openWorldHint=true, idempotentHint=false; the description adds real value by clarifying that app state is preserved (no force-stop, no data reset) and that the launch happens only once. It omits error behavior when the package is not installed and says nothing about what the optional observation triggers.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence with the scope and the key non-behavior front-loaded; every clause carries information and nothing is padded.

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 core contract is conveyed, but with no output schema and zero parameter documentation, an agent still lacks guidance on the observe modes, on package-name discovery, and on failure modes. For a two-parameter tool with a required free-form-looking package argument, that is a meaningful 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 0%, so the description must carry parameter meaning, and it does not. The 'observe' enum (none/tree/screenshot/both) is completely unexplained — the agent cannot tell what each mode captures or how it affects cost/output, and the package format is only enforced via regex with no 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?

States a specific verb and resource — 'Launch an installed package's launcher activity' — plus scope ('once') and exclusions ('no force-stop or data reset'), which separates it from restart-style behaviors. It does not name a sibling (e.g., aua_apps for package discovery), so it falls short of full differentiation.

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 'once, no force-stop' phrasing implies the use case (bring an existing app to the foreground rather than cold-restart it), but there is no explicit when-to-use-vs-alternatives guidance. Nothing tells the agent how to obtain a valid package name, which the strict pattern makes non-trivial.

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 readOnly=true, idempotent=true, openWorld=true, so safety intent is covered. The description adds a genuinely useful behavioral note that action coordinates must be derived from image pixels via pixel_to_device, but it does not say where that value comes from or explain the max_nodes truncation behavior implied by the 500 cap.

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 short sentences with the core action front-loaded and no filler. The coordinate sentence is dense but earns its place, though 'pixel_to_device' is used without saying where it is obtained.

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 and 0% parameter documentation, the definition should describe what comes back (tree node fields, screenshot payload, how pixel_to_device is delivered). Instead it leaves the return shape and the parameter choices unexplained, which is a substantial gap for the observation primitive of an automation toolkit.

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 carries the full burden and largely fails: neither the mode enum values (tree/screenshot/both) nor max_nodes are explained. Only the coordinate convention is clarified, and that is about interpreting output rather than configuring these two 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?

States a specific verb (Read) and resource (current accessibility tree and/or screenshot), and the 'and/or' matches the mode enum. It does not differentiate itself from siblings like aua_screen, aua_screen_frame, or aua_find, so an agent must infer which read path to pick.

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?

No when-to-use or when-not-to-use guidance and no named alternatives among the many siblings. In particular, the description never says when to prefer mode=tree vs screenshot vs both, which is the main decision the caller must make.

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 this is a non-read-only, idempotent, non-destructive operation. The description adds genuinely useful scope information that annotations cannot convey — that the pause spans CLI/MCP processes and blocks reads as well as actions — but it omits how the pause is lifted, whether it expires, and whether it survives process restarts.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler. The phrasing 'Android Use reads/actions' is slightly compressed and would read more clearly as plain language, but nothing is wasted.

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 and no output schema, the description covers what the agent must supply, but for a global state-changing toggle it should say how the paused state is released and what the agent should expect on subsequent calls — the most consequential behavior is left implicit.

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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline 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 (pause) and object (Android Use reads/actions), plus the motivating scenario (user authentication takeover). It is distinguishable from the sibling set of action tools because it halts rather than performs device actions, though it never names aua_resume as its inverse.

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 'for user authentication takeover' implies the triggering condition, but there is no explicit when-to-use or when-not-to-use rule, no mention of pairing it with aua_resume, and no statement about whether other agents/sessions are affected.

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 flag this as a non-read-only, non-idempotent, open-world mutation, and the description usefully adds that it presses exactly once, that Enter may submit, and that an authorization is required. It stays silent on what the 'observe' capture returns and on failure/retry behavior for a non-idempotent 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?

Two short clauses, front-loaded with the action and scope, with no filler. The wording 'volume' rather than up/down costs a little precision but nothing is wasted.

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 two-parameter interaction tool with no output schema, it covers the action and the authorization caveat but leaves the second parameter and post-call observation behavior unexplained. An agent could call it, but could not predict the observe side effects from the description alone.

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 carry parameter meaning, but it collapses volume_up/volume_down into a single 'volume' and never mentions the 'observe' parameter (none/tree/screenshot/both), which materially changes what the call returns. Only the required key is partially covered.

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?

Names a specific verb (press) plus the exact key set, and 'once' distinguishes it from a long-press or repeat action. It is clearly separable from aua_tap/aua_screen_action since it requires no coordinates, though it never states that contrast 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?

Usage is implied ('press home/back/... once') and the note that 'Enter may submit' hints at when a press has consequences, but there is no guidance on when to pick this over aua_tap, aua_screen_action, or aua_type_text, and no stated prerequisites for the authorize step.

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 openWorldHint, so safety and repeatability are covered by structured data. The description adds genuine value beyond them by disclosing that it will not start or restart services and that the returned observation should be reused, but it is silent on what happens when verification fails (exception vs. negative result) and on cost/latency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, no filler, with the verification scope front-loaded and the constraints following. Slightly telegraphic phrasing ("Verify unlocked screen, UiAutomator, foreground, display" reads as a compressed list) but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, and the description only says to reuse "the returned observation" without indicating what that observation contains (device state, UI tree, screenshot when requested) or its shape. For a readiness gate whose output feeds subsequent calls, this leaves a meaningful gap, though the precondition list covers the core semantics.

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 single parameter 'screenshot' has 0% schema description coverage and its default of false is the only structured hint available. The description never mentions screenshots, so it does nothing to explain what enabling it captures or how it affects the returned observation; with low coverage the description was expected to compensate and does not.

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?

"Verify unlocked screen, UiAutomator, foreground, display and a nonempty tree" gives a specific verb plus an explicit checklist of preconditions, which is far more informative than the opaque name aua_ready. It does not, however, name or contrast itself with any sibling such as aua_doctor or aua_observe, so an agent must infer the boundary.

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 clause "Does not start/restart services" establishes one clear exclusion, and "Reuse the returned observation" implies the result should be carried forward rather than re-checked. There is no explicit statement of when to call this versus aua_doctor (diagnostics) or aua_observe (state capture), leaving the primary routing decision to inference.

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 that this is a non-read-only, idempotent, non-destructive operation. The description adds useful behavioral context—auth confirmation is required and a fresh observation is returned—but does not explain what 'resume' actually changes (e.g., unpausing an action queue) or what state is resumed.

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, front-loaded sentence with no wasted words. It puts the critical precondition first and the resulting action second, making it easy to scan.

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 tool with annotations covering safety, the description covers the essential gating condition and outcome. It is still somewhat incomplete because it never clarifies what 'resume' means operationally or how it differs from aua_observe, which may leave an agent guessing in ambiguous pause/resume scenarios.

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 no parameter semantics to clarify. The baseline for zero-param tools is 4, and the description appropriately avoids empty parameter discussion.

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 action ('Resume') with a specific precondition ('only after user confirms authentication is finished') and a follow-up effect ('get a fresh observation'). It does not explicitly distinguish itself from siblings like aua_observe or aua_pause, but the verb and condition are specific enough for an agent to understand the tool's core 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 provides one clear when-to-use condition: after the user confirms authentication is finished. However, it offers no guidance on when not to use it, what to do if authentication is not finished, or how it relates to alternatives such as aua_pause or aua_observe.

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 idempotentHint=true and readOnlyHint=false; the description adds meaningful context beyond them by disclosing the transport (H.264 stream), the external ffmpeg dependency, and that calling it reuses an existing panel rather than spawning a new one. It stops short of describing failure behavior if ffmpeg is absent.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences with the core action front-loaded and the differentiator and dependency following in priority order. The telegraphic, uppercase 'READY' reference is slightly cryptic but costs no extra 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 no-parameter, no-output-schema tool whose main risks are environment prerequisites, the description covers the dependency and the reuse semantics well. It leaves open what the caller receives back (a panel handle or stream reference) and what happens when ffmpeg is missing, which matters for an agent deciding whether it can rely on this 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The schema coverage is 100% with an empty object, consistent with the description.

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 concrete verb and resource: 'Open/reuse the Android live screen sidebar.' It implicitly differentiates itself from polling-based siblings by noting it uses 'an independent H.264 video stream, not screenshot/tree polling', but never names aua_screen_frame or aua_observe directly.

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?

Usage is implied by the contrast with screenshot/tree polling, and the 'READY also links the same panel' note hints at a relationship with aua_ready. However, there is no explicit when-to-use statement, no exclusion naming a sibling, and no guidance on when to prefer this over aua_screen_frame.

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=false, openWorldHint=true and idempotentHint=false, so the mutation and non-idempotence profile is covered. The description adds one genuinely new behavioral constraint, the auth-takeover block, but says nothing about how tap/swipe coordinates are interpreted or what side effects the toolbar actions (home, back, refresh, save) have.

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 short sentences with no filler, so it is concise, but the brevity comes at the cost of under-specification rather than tightening a complete statement. The blocking constraint is placed after the vague purpose sentence rather than 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 four-parameter tool with two enums, zero schema documentation and no output schema, the description leaves the core semantics unresolved: which actions need x/y, whether direction is required for swipe, and what tap versus press_button means. Only the auth-takeover restriction is fully explained.

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% across four parameters, so the description carried the full burden and added none. It never mentions x/y coordinate meaning, when direction applies (presumably only for swipe), or what each of the six action enum values does.

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 two loose categories ("preview toolbar" and "pointer actions") that map only vaguely to the six enum actions, and it never explains what a "preview toolbar" is. It overlaps almost entirely with siblings aua_tap, aua_swipe and aua_press_button without giving any basis for choosing between them.

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 only guidance is the exclusion "Blocked during authentication takeover", which is useful but narrow. There is no statement of when to use this tool rather than aua_tap, aua_swipe, aua_press_button or aua_screen, all of which appear to do overlapping work.

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 the safety profile (readOnlyHint, idempotentHint, openWorldHint=false), so credit here goes to added behavioral detail: 'cached' signals the frame is not freshly captured (and may be stale), and 'app-only' scopes it to the app rather than the full screen. That is meaningful disclosure beyond the annotations, though staleness/freshness semantics could be spelled out more explicitly.

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 short fragments, zero padding, with the resource and the exclusion front-loaded. It is efficient, though the extreme terseness borders on under-specification rather than disciplined brevity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description should explain the return value (image payload, format, resource reference) but does not, and the one parameter is left undefined in both schema and description. For a simple read-only tool this is a notable gap, not a fatal one.

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 sole parameter 'after_seq' has 0% schema description coverage and the description does not mention it at all. With low coverage the description must compensate for the gap, but it supplies no meaning for the parameter (sequence semantics, cursor behavior, or what happens when 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 fragment 'App-only cached video frame' identifies the resource (a video frame) and its scope (app-only), but omits a verb and never says it returns/retrieves image data. The second sentence distinguishes it from screenshot and UI-tree tools, which helps, but the core action remains implied rather than stated.

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?

Negative guidance ('Does not query UI trees or capture screenshots') implicitly steers an agent away from this tool when it needs a UI tree or a fresh screenshot, which is real value. However, it never names an alternative sibling (e.g., aua_screen, aua_observe) or states positively when this tool is the right choice over them, leaving usage for inference.

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 it adds real context: start pushes a pinned JAR and reuses or starts UiAutomator, and it notes no root or keyboard APK is required. However, for a mutating tool (readOnlyHint=false, idempotentHint=false) it does not describe what state is changed on the device, whether the push is repeatable, or what happens on failure.

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 dense sentences, front-loaded with the first-use sequence, with no padding. The telegraphic style ('configure selects a serial') borders on cryptic but every clause carries 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?

With no output schema and no annotation detail, the description would need to explain return states and failure modes. It covers sequencing and per-action meaning, which is the core need, but leaves error handling, side effects, and what 'ready' actually guarantees unstated.

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 carry the load and it largely does: status/discover are tied to first use, configure is tied to selecting a serial, and start is tied to the JAR/UiAutomator behavior. discover and status are still not individually explained, so the mapping is slightly 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 never plainly states 'prepares the device for automation'; the purpose must be inferred from the action list and the note about pushing a JAR and starting UiAutomator. Individual actions (configure selects a serial, start pushes a pinned JAR) are concrete, but the overall verb+resource framing is missing.

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 prescribes a first-use sequence: run status/discover, start once if needed, then proceed to ready. That is strong ordering guidance an agent would otherwise have to guess. It stops short of specifying when not to call it or naming aua_ready/aua_doctor as the explicit 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 disclose readOnlyHint=false, openWorldHint=true and idempotentHint=false. The description adds genuinely new behavioral context with 'No automatic retries' and the observation-for-next-step hint, but says nothing about what the swipe affects on screen, failure modes, or what the observation_id does.

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 short sentences, front-loaded with the core action and no filler. The telegraphic style ('observe for next-step context') is slightly terse at the cost of clarity, but 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?

For a five-parameter interaction tool with no output schema and no parameter descriptions, the description should explain duration units/bounds and the role of observation_id. It covers only part of the surface, leaving an agent to infer how to correlate an observation with a prior 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%, so the description carries the full burden. It loosely clarifies direction (finger motion, up = later rows), region (display-pixel coordinates) and observe (next-step context), but duration and observation_id are left entirely unexplained, leaving two of five parameters with no semantic guidance anywhere.

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: 'Perform one swipe', which is more precise than the bare tool name and clarifies that a single gesture is executed. It does not differentiate from siblings such as aua_screen_action or aua_tap, which could plausibly also produce gesture input, so it stops short of a 5.

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 offers usage hints ('up usually reveals later rows', 'observe for next-step context') that help an agent pick a direction and decide whether to request observation. It never states when to prefer this over aua_screen_action or aua_batch, nor any preconditions, so guidance is implied rather than explicit.

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=false, openWorldHint=true and idempotentHint=false, so mutation and non-idempotence are covered structurally. The description adds real context: ambiguity yields candidates plus a screenshot, observation_id validates the same runtime/app/display, and there is no automatic replay. That is useful but still leaves undefined what a successful tap returns and whether both targeting modes may be supplied.

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 short sentences, front-loaded with the core action and targeting modes, with no filler. The observation_id and replay notes follow logically and each conveys distinct 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 five-parameter, zero-required mutation tool with no output schema, the description covers targeting, ambiguity handling, context validation and the absence of replay. The remaining gap is the unspecified precedence when both selector and coordinates appear, or when neither is given.

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?

With schema description coverage at 0%, the description carries the burden and does explain the role of selector, x/y and observation_id. It adds nothing about the 'observe' enum (none/tree/screenshot/both) or the eleven Selector sub-fields (text_contains, resource_id, enabled, etc.), so a majority of parameter semantics remain unstated.

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 ('Tap once') and enumerates the two targeting modes, selector or x/y display pixels, which is enough to separate it from sibling tools like aua_find or aua_screen_action. It stops short of naming any sibling 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 selector-vs-coordinates choice is implied, and 'No automatic replay' hints that retry logic belongs to the caller. There is no explicit guidance on when to reach for this versus aua_screen_action or aua_find, nor on what to do when ambiguity comes back.

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 the tool as mutating and non-idempotent; the description adds important context beyond that: no submit, replace defaults to true, verify triggers exact readback, and uncertain input should not be blindly retried. It could further explain replace=false behavior, but the extra behavioral detail is substantial and consistent 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?

Seven short sentences, front-loaded with purpose then prerequisites and flags; no filler. The density is appropriate for a tool with several behavioral constraints.

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 six-parameter mutation tool with no output schema, the description covers the core action and key flags, but omits selector and observe semantics that an agent needs to invoke it fully. It is adequate but incomplete for the tool's complexity.

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 carry parameter meaning. It explains text, verify, replace, and allow_newlines, but never mentions the observe enum or the complex selector object, leaving two parameters and the nested selector schema undocumented. That partial coverage merits a 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 specific verb and target ('Set Unicode text on a focused, editable, non-password field'), making the operation and its scope immediately clear. It does not name a sibling alternative, but the scope constraints distinguish it adequately from generic action tools like aua_screen_action.

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 concrete prerequisites ('Focus it with tap first'), default behavior, app-support requirement, newline handling, and a caution against blind retries. It never states when not to use this tool or explicitly names an alternative such as aua_screen_action, so it is clear but not fully 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 readOnlyHint, idempotentHint and openWorldHint, so safety is covered; the description adds real value by clarifying that 'found=false means timeout, not business failure' — a semantic distinction an agent would otherwise misread as an error. The 20-second ceiling is repeated from the schema's maximum, which is mildly redundant but harmless.

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 tight sentences with no filler; the action and its bound come first, followed by the critical interpretation note about the return flag. Nothing could be removed without losing 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?

With no output schema, the description carries the burden of describing the return value, and it explains only the 'found' flag while leaving the rest of the response shape unstated. For a tool whose selector is a large undocumented nested object, more guidance on matching behavior is needed, though the timeout semantics are adequately 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 0% and the selector is an 11-field nested object (text, index, enabled, focused, package, clickable, class_name, description, resource_id, text_contains, description_contains) with no explanation anywhere of matching semantics or whether fields combine as AND. The description only restates the timeout ceiling already encoded as the schema maximum, adding essentially nothing about 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?

Specific verb (wait) plus resource (selector) and a hard bound (20 seconds), so an agent immediately knows this is a blocking conditional wait rather than an instantaneous lookup. It does not explicitly name the sibling it replaces (aua_find for immediate checks, aua_pause for fixed delays), so differentiation is inferable rather than stated.

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 20-second cap and 'found=false' phrasing imply this should be used when an agent needs to block on an element appearing, which hints at the when-to-use case. However, there is no explicit guidance versus aua_find or aua_pause, and no statement of what happens after a timeout in terms of next steps.

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