android_use

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 only declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the description carries real additional weight: full-plan validation before any action, the exact stop conditions (error, unmet condition, scroll miss, Enter submission, 25s budget), that in-flight RPCs may overrun the budget, and the resume/replay rule. That is exactly the operational context an agent needs before firing a mutation batch.

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 dense sentences, front-loaded with scope and validation, followed by stop conditions and the resume rule. Almost no waste; the parenthetical about in-flight RPCs is the only borderline detail, and it is genuinely useful for timeout reasoning.

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?

No output schema exists, and the description only indirectly reveals a return field via 'Resume from stopped_at'; it does not describe per-step results or error payload shape. Given the tool's mutation stakes and 20-step plan complexity, that is a small but real gap; everything else an agent needs to call it safely 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?

With schema description coverage at 0% and a nested args object that is schema-free (additionalProperties: true), the description compensates by explaining that args are 'each operation's normal args' - i.e., reuse the argument shape of the corresponding single-op tool. That resolves the biggest ambiguity, though it does not enumerate per-op required args.

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, 'Execute up to 20 known steps', plus the key scope constraint that each operation uses its normal args. This clearly separates it from the single-operation siblings (aua_tap, aua_swipe, ...) as a batched executor, but it never names the planning alternative aua_execute_goal, so the differentiation is inferential rather than 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 gives operational guidance for one scenario - resuming from stopped_at and never replaying completed or uncertain steps - which implies it is meant for known, pre-determined plans. It does not state when to prefer this over aua_execute_goal or the individual action tools, so usage is only partially implied.

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 readOnlyHint=false and idempotentHint=false, and the description adds genuinely new behavior: partial execution on failure (the first click may already have landed) plus the rule not to replay. It also clarifies that interval excludes RPC latency, which matters for timing-sensitive UI. It stops short of describing the return payload or what happens if both selector and x/y are 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 action and its targeting modes, with the safety warning placed last. No filler, though the telegraphic phrasing leaves a few terms undefined.

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

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

For a 9-parameter, non-read-only interaction tool with no output schema, the description covers the risky timing and failure semantics well but leaves most optional parameter groups (visual, variation, observation_id) unexplained. Adequate but not 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% across 9 parameters, so the description carries real weight, and it does define interval units/semantics and confirms wait_for and observe are supported. It says nothing about variation, visual, observation_id, or the precedence rule when selector and x/y are both given, so most parameters remain undocumented.

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 action (one intentional pair) with its two mutually exclusive targeting modes, selector or x/y display pixels, which is a real distinction agents need. It does not name aua_tap as the sibling it differs from, so the differentiation from a plain tap or long-press must be inferred.

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?

"One intentional pair" implies this is the semantic double-tap gesture rather than two separate taps, and "never replay automatically" gives failure-handling guidance. However, there is no explicit statement of when to prefer aua_double_tap over two aua_tap calls or over aua_long_press, and no prerequisites.

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 mutating, non-repeatable nature is partly covered. The description adds genuinely useful behavior beyond that: a single drag execution and 'No automatic replay', which tells the agent it must re-issue calls itself. It says nothing about timing side effects, failure modes, or what the returned observation 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 action and coordinate system before the modifier list. The trailing parameter enumeration is low-value filler but not verbose enough to hurt.

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?

Seven parameters with zero schema descriptions, no output schema, and an open-world mutating annotation set is a heavy burden the description does not carry. Four parameters are named without semantics and `variation` (with its bounded-randomization semantics) is never mentioned, so an agent cannot confidently compose a call with waiting or observation.

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% — the schema only supplies titles, ranges and defaults. The description merely lists four parameter names (duration, observation_id, wait_for, observe) without explaining what any of them do, what observe modes return, or what wait_for waits on, and it omits `variation` entirely. Only the start/end pixel units are meaningfully clarified.

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 concrete verb and gesture ('Drag once from start {x,y} to end {x,y}') and pins the coordinate system to Android display pixels, which is a real ambiguity resolved. It does not, however, distinguish itself from the close sibling aua_swipe or from aua_scroll_until, so an agent must infer the difference from 'Drag once' and 'No automatic replay'.

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?

'Drag once' plus 'No automatic replay' implies this is a single-shot gesture rather than a repeated or scroll-like motion, which weakly separates it from aua_swipe. There is no explicit when-to-use statement, no named alternative, and no precondition (e.g., element already located via aua_locate) before calling.

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

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

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), it discloses what data leaves the device (visible app UI text sent to TypeSafe in Jev mode, nothing sent in host mode), what happens after mutations (effect_timeout_seconds bounds observation; unresolved effects hand off without another mutation), and warns that status=handoff is not success and geometry-only changes do not prove an effect. That is unusually rich disclosure about side effects, data egress, and result interpretation.

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 first sentence is well front-loaded and the description is dense with useful substance rather than filler, but it reads as a run-on paragraph of terse fragments ('Compact semantic state and parallel operation/target questions share one Jev request per step') with no grouping by concern. Several sentences require re-reading to parse, which hurts scanability for a long definition.

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 16-parameter, non-idempotent, open-world tool with no output schema, the description does cover return statuses (decision_required, handoff, stop_reason=model_goal_achieved with an 'unverified: check it' caveat) and safety behavior well. However, the majority of tuning parameters are unexplained, and the one-time token workflow is described only in passing, so an agent still lacks enough information to set non-default parameters confidently.

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 16 parameters, so the description carries the full burden. It does explain goal, package, texts, completion/completion selector, decider, input_macros, max_steps ('counts candidate selections, with at most two native writes per input macro'), and effect_timeout_seconds, but leaves actions, observe, variation, min_margin, min_probability, max_model_calls, timeout_seconds, and completion_state entirely undocumented.

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 opening sentence states the mechanism clearly: an agent plans, a decision policy selects candidate IDs, and Android Use executes them, so the tool reads as a bounded goal-execution orchestrator rather than a primitive action. It also signals the boundary with primitive siblings via 'Keep existing tools for planning, unsupported controls and recovery,' though it never names a specific sibling tool.

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 routing conditions: decider=auto prefers Jev when enabled, falls back to host, and host mode returns status=decision_required that must be resolved with aua_goal_decide. It also states exclusions (password screens hand off, keep existing tools for planning/unsupported controls), but does not say when to prefer this over aua_screen_action or aua_batch for a given task.

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?

The annotations only flag that this mutates state, acts in an open world, and is not idempotent. The description adds far more: the tool re-reads the UI, discards the choice and returns previous_choice_stale=true if the screen changed, executes the candidate only once, then checks the effect and returns the next decision, completion or handoff. It also documents token lifetime rules and the fact that an unknown option ID keeps the token while any other outcome consumes it.

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?

It is dense and front-loaded: the first clause identifies the step and the required input, and the remaining sentences add failure modes, the return or handoff behavior, and timing constraints. Nothing is filler, but several sentences are run-on, and the jump from stale-choice handling to token lifetime forces careful reading.

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 tool with no output schema, the description covers everything needed to call it safely: input provenance, staleness handling, the possible outcomes (next decision, completion, handoff), and the fact that timeout_seconds counts device time only rather than host thinking time.

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?

Because the schema has no descriptions at all, the description carries the full burden. It maps token to the one-time token from the latest decision_required result and choice to an option ID from that result, and it explains how an invalid choice affects the token. It does not explain the 32-hex-character token format or the 40-character limit, which the schema already enforces.

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: 'send one option ID from the latest decision_required result with its one-time token', and frames the tool as the 'Host-decider step of aua_execute_goal'. That framing directly distinguishes it from the sibling aua_execute_goal, which is the tool that produces the decision in the first place.

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 precondition is explicit: it must be called with a choice taken from the latest decision_required result, and the token must come from the same MCP server process and be used within 5 idle minutes. It also implicitly routes the agent to aua_execute_goal to obtain the initial decision. The only gap is that it never names an alternative explicitly (for example resuming via aua_resume when the token has expired); the guidance is descriptive rather than prescriptive about which path to choose.

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, idempotentHint=false and openWorldHint=true; the description usefully reinforces the non-idempotent, non-destructive nature by stating it launches once and performs no force-stop or data reset. It does not disclose what happens on failure (package not installed, no launcher activity) or that the app is brought to the foreground, leaving real behavioral gaps.

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 core action front-loaded and no filler. The brevity is efficient, though it comes at the cost of the missing parameter and post-launch behavior detail rather than through disciplined editing.

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

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

For a tool with three parameters, a nested wait condition, and no output schema, the description should explain that `observe` controls whether a tree/screenshot is returned and that `wait_for` blocks until a selector appears or disappears. None of that is present, so an agent cannot predict the response shape or the blocking behavior.

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 only touches the required `package` parameter obliquely. The `observe` enum (none/tree/screenshot/both) and the nested `wait_for` condition with timeout are entirely unexplained, despite materially changing what the call returns and how long it blocks.

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?

"Launch an installed package's launcher activity" names a specific verb and resource, and "once" scopes the action. It does not name or differentiate from siblings such as aua_apps (package discovery) or aua_screen_action (post-launch interaction), so an agent must infer routing.

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 force-stop or data reset" implies a boundary condition (this is a plain start, not a restart/clear) and "once" warns against repeated calls, which gives implicit usage guidance. However, it never states when to prefer this over aua_apps or how it relates to aua_observe/aua_wait for post-launch inspection.

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?

Goes well past the readOnly/openWorld/idempotent annotations: it discloses that a masked screenshot leaves the device to a third party (TypeSafe), the exact opt-in toggle and env var, the jev_images_disabled failure, refusal of password/OTP screens and paused devices, and the five possible statuses. The remaining gap is that it does not say how long a request may take or what a masked upload costs in latency, though timeout_seconds hints at it.

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?

Front-loaded with the purpose and the strongest routing rule in the first clause, then prerequisite, then refusals, then output shape. The sentences are dense to the point of being comma-chained and some parenthetical detail (the Chinese toggle label) could be trimmed, but almost every clause carries usable 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 an open-world vision tool with no output schema, the description covers return shape (box, tap, status enum, ambiguous reason with tree_candidates), pixels vs. logical coordinates, and the honesty caveat that a located box is a model judgment rather than verification. Only the unlabeled numeric thresholds keep it short of 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% across 7 parameters, so the description has to carry semantics and only partly does: it explains region's default ('default full display'), masks ('masks blank sensitive areas before upload'), and the output box/tap pixel convention. It says nothing about min_presence, min_confidence, timeout_seconds, or the package pattern, which are the tuning knobs an agent would most likely set wrong.

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-only visual location of elements — and scopes it precisely to what the accessibility tree lacks (canvas, games, WebView images, unlabeled icons). That scope statement alone separates it from tree-based siblings like aua_find and from 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?

Explicitly says when not to use it ('small text such as prices or tags is unreliable, so select text with selectors') and closes with 'Prefer trees/selectors when they work'. It also names the prerequisite condition for use (Jev plus the images opt-in) and the fallback failure code when unmet.

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 mutability and non-idempotency are covered. 'No replay' and 'inspect uncertain results' add a modest verification warning, but nothing about failure behavior, blocking, or what an uncertain outcome 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?

Three short clauses, front-loaded with the verb and targeting modes, then capability flags, then a caution. 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?

For a 9-parameter tool with zero schema description coverage, no output schema, and opaque nested objects (visual/LocateArgs, variation, observation_id), the description explains only the targeting modes and duration. An agent cannot infer what visual matching, variation, or observation_id do from this text.

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 0% schema description coverage the description must carry the load, and it does cover the key semantic decision (selector versus x/y coordinates, mutually exclusive via 'OR') plus the duration range. It leaves visual, variation, observation_id, the observe enum values and all Selector fields entirely unexplained.

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: 'Long press once by selector OR x/y display pixels', with a duration parameter. The 'once' phrasing implicitly separates it from aua_tap and aua_double_tap, though no sibling is named 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?

'Inspect uncertain results; no replay' gives post-call guidance, but the description never says when to choose a long press over aua_tap, aua_drag or aua_swipe, nor when selector-based targeting should be preferred over raw coordinates.

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 declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the mutating, non-repeatable nature is covered structurally. The description adds real value by warning that Enter may submit something and requires user authorization, which is not in the annotations. It says nothing about the observation or wait side effects the tool can trigger.

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 second sentence is well placed as a safety caveat, though the phrasing is terse to the point of being cryptic about what 'authorize' requires.

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 a nested WaitCondition and no output schema, the description leaves two of three parameters undocumented and never explains what the call returns or how waiting/observation interact with the press. It covers the action and its risk but not the tool's full surface.

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, yet it only partially enumerates the 'name' enum and never explains the 'observe' (none/tree/screenshot/both) or 'wait_for' (selector + state + timeout) parameters. An agent cannot learn from the text that a press can also return a UI tree or screenshot or block until a condition holds.

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 ('Press') and names the concrete buttons: home/back/recent/enter/volume. It is distinguishable from siblings like aua_tap or aua_long_press, which act on screen elements rather than hardware/navigation keys. It slightly underspecifies by lumping volume_up/volume_down under 'volume'.

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 guidance on when to choose this over aua_tap, aua_screen_action, or aua_type_text, and no prerequisites beyond a passing note that Enter requires user authorization. The agent must infer that this is the tool for hardware/nav keys rather than screen coordinates.

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?

Adds substantial behavior beyond the readOnly/openWorld/idempotent annotations: OCR pixels are re-checked post-inference, missing or ambiguous values return NONE, decimal parsing is local, min_ocr_confidence is uncalibrated provider telemetry rather than accuracy, evidence_text is marked caller_provided_text and not verified as a phone read, and verified=false always requires Agent business verification. These are non-obvious trust and verification semantics an agent could not infer from the schema or annotations alone.

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?

Highly information-dense with essentially no wasted claims, but it is delivered as a semicolon-chained wall of text with no grouping by parameter or mode, and jargon-heavy phrasing ('code-owned', 'tree', 'hashing'). The most decision-critical rule (auto vs tree vs screen_ocr) is front-loaded, but the rest requires re-reading to map to individual parameters.

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 13-parameter, no-output-schema tool with zero schema description coverage, the description supplies return semantics (NONE on ambiguity), verification obligations, environment prerequisites, and the OCR cost model. The remaining gaps are the undocumented tuning parameters (min_probability, min_margin, timeout_seconds) and the meaning of 'package', which an agent must guess or trial.

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 0% schema description coverage, the description carries the parameter burden and does well for most: source modes, region limits in display pixels, ocr_masks excluding non-evidence from OCR and hashing, currency required for ambiguous symbols, sum_check validating same-currency Decimal sums, evidence_text provenance, and field kinds money/text/choice. However min_margin, min_probability, timeout_seconds, and package semantics are never explained anywhere, leaving four of thirteen parameters opaque.

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+resource ('Read-only Jev field judgments on current app text') and clarifies concretely with 'Extract code-owned money/text spans or classify supplied options, all fields in one request.' The term 'Jev' and 'code-owned' are unexplained jargon, but the second sentence makes the actual function intelligible and 'No visual clicks'/'no device actions' implicitly separates it from the aua_screen_action/tap family.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit mode-selection rules: source=auto uses the tree when text/expected_labels and money candidates suffice, otherwise captures a ROI and runs macOS Vision OCR; source=tree disables OCR, screen_ocr forces it, and OCR requires Xcode Command Line Tools. It also states a prerequisite ('Requires Jev enabled'). It never compares against sibling tools like aua_find or aua_observe, so there is no true alternatives guidance.

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

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

Annotations already declare readOnlyHint, idempotentHint and 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?

Beyond the annotations (readOnlyHint=false, openWorldHint=true, idempotentHint=false), the description discloses real behavioral traits: phone actions are suppressed during auth takeover, settings responses never expose credentials, and save runs a fixed synthetic Choice test before enabling. That is meaningful side-effect and safety context an agent could not infer from structured fields, though it stops short of saying what each action returns or which actions mutate local 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?

Four short telegraphic sentences with no filler, but the phrasing is jargon-heavy ('fixed synthetic Choice', 'local Jev settings') and the most decision-relevant information, the action list and parameter mapping, is absent. Compact, yet under-specified rather than tight.

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

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

This is a 13-action multi-purpose tool with 5 parameters, 20% schema coverage, and no output schema, so the description carries a heavy burden it does not meet. It omits action-by-action behavior and the x/y/direction/api_key applicability, leaving an agent unable to invoke most actions correctly without guessing.

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 only 20% – just api_key has a note – and the description adds only that users supply their own key in the screen UI. It never maps x/y to tap/swipe, direction to swipe, or api_key to jev_save/jev_test, leaving 13 actions' parameter requirements undocumented. With this low coverage the description should 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?

The description only characterizes the tool as 'App-only preview controls and local Jev settings' without a specific verb or enumeration of what the 13 actions do. It never distinguishes itself from siblings such as aua_tap, aua_swipe, or aua_screen, even though its action enum overlaps with those tools' purposes. An agent cannot predict what calling it will accomplish.

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 a constraint ('Phone actions are blocked during authentication takeover'), which implies a when-not condition but no when-to-use rule. Nothing tells the agent which of the 13 actions to pick, or when to prefer this tool over aua_tap/aua_swipe for the same tap/swipe operations.

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, the description discloses concrete termination semantics: bounded by max_swipes and timeout_seconds, halting after two unchanged regional snapshots or an app/display change. It also warns that no_progress does not prove list end, a non-obvious caveat. The swiping behavior is consistent with readOnlyHint=false and openWorldHint=true, but the return status/failure shape is never described and no output schema exists.

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?

Short telegraphic sentences, front-loaded with the primary action and termination rules, with zero filler. The 'no_progress' sentence is slightly opaque since no output schema documents that field, so the reference is under-anchored rather than wasteful.

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

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

For a 9-parameter, state-mutating, open-world tool with no output schema, the description covers stopping conditions and one key modifier (region) but leaves the observation modes, direction semantics, and result payload unexplained. It is adequate to call correctly in the common case but incomplete for the full parameter surface.

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 9 parameters, so the description carries the full burden and only partially meets it: it explains max_swipes and timeout_seconds as bounds, and region as the nested-list scoping mechanism. It says nothing about observe, direction (defaulting to 'up', which is surprising for scroll-to-find), duration, settle_seconds, or variation.

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 ('Find a visible selector') plus the mechanism ('swiping only if absent'), which distinguishes it functionally from a bare find or raw swipe. It never names a sibling tool, so an agent must infer which of aua_find/aua_swipe/aua_scroll_until to pick from behavior alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives a conditional scoping hint ('Use region for nested lists') and a post-condition constraint ('Does not click the result'), which implies the tool is for locating, not activating. However, it never states when to prefer this over aua_find or a manual aua_swipe sequence, and gives no exclusion for cases where the target is already known to be on screen.

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 declare readOnlyHint=false, openWorldHint=true and idempotentHint=false, so the mutation/non-repeatable nature is covered. The description adds genuinely new behavior: "No automatic retries" warns the agent it must re-issue failed swipes, and the direction note disambiguates finger-motion vs content-motion. It still omits what a swipe can destroy or what happens on a partial/no-op gesture.

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 action, no redundant wording. Slightly telegraphic phrasing ("observe for next-step context") costs a little clarity 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 7-parameter, mutation-capable, non-idempotent gesture tool with an optional observation/observation_id loop and a wait condition, the description is too thin. The relationship between observe and observation_id, and the role of wait_for after a swipe, are never explained, and there is no output schema to compensate.

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 7 parameters, so the description carries the full burden and only covers two: direction (finger motion, up reveals later rows) and region (display-pixel units). It says nothing about observe, observation_id, wait_for, duration or variation, leaving the most consequential parameters undocumented.

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 gesture ("Perform one swipe") and clarifies what direction means in terms of finger motion. It distinguishes a swipe from a tap or drag implicitly through the gesture name, but never contrasts it with siblings like aua_drag or aua_scroll_until.

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?

"Use display-pixel region if needed" and "observe for next-step context" give fragments of conditional guidance, but there is no statement of when this tool should be chosen over aua_scroll_until, aua_drag, or repeated aua_tap. The agent must infer the choice with no exclusions.

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

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

Annotations only declare non-read-only, open-world, non-idempotent; the description adds substantive behavior beyond that: visual taps only the box center when located, rechecks surrounding pixels first, is disallowed in batch, ambiguity returns candidates plus a screenshot, and failed wait_for timeouts are never replayed. Those are the safety-relevant facts an agent needs for a mutating tool. It stops short of describing the response of a successful tap or what permissions/context are required.

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?

Information is front-loaded and each clause carries content, but the prose is compressed to the point of unreadability in places ("aua_locate args: Jev Box with the images opt-in", "never replays it") and mixes modes, error behavior, and context checks without structure. Restructuring into per-parameter sentences would lose nothing and gain 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?

For a mutating, open-world tool with 8 optional parameters and no output schema, the description covers the essential gaps: how targeting resolves, the ambiguity fallback (candidates + screenshot), post-action waiting, context validation, and the no-replay guarantee. The undeclared observe/variation parameters are a gap, but the agent can still call the tool correctly from what is written.

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 8 parameters, so the description must carry the load and it only partly does: it explains selector, x/y, visual (by reference to aua_locate args), wait_for, and observation_id, but never mentions the observe enum or the variation object. The wait_for semantics (visible/gone, timeout-not-replayed) and observation_id's runtime/app/display check are genuinely useful additions the schema does not convey.

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 scope ("Tap once by selector OR x/y display pixels OR visual") and names the three targeting modes, which separates it from siblings like aua_double_tap and aua_long_press. The clarity is dented by garbled phrasing ("Jev Box with the images opt-in"), which reads like an unresolved template variable and forces the agent to guess what visual targeting actually requires.

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 mode-selection guidance (selector vs pixel vs visual) and a negative constraint ("never in batch"), which is real usage information. However, it never states when to prefer this over aua_double_tap, aua_long_press, or aua_locate directly, and no prerequisites or preconditions are spelled out.

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

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

Annotations only declare readOnlyHint=false, idempotentHint=false, openWorldHint=true. The description adds real behavioral context: replace defaults to true (existing text is overwritten), no submit/Enter is pressed, verify performs an exact readback, the target app must support setText, and retries on uncertain input are discouraged. It doesn't say what happens on failure or how the field is chosen when selector is omitted.

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?

Five short sentences, front-loaded with the action and target, then prerequisites, defaults, and cautions. Every sentence conveys a distinct constraint; no filler.

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

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

For a 7-parameter mutation tool with nested Selector/WaitCondition objects and no output schema, the description leaves the selector and wait_for mechanics fully unexplained and gives no return-value expectations. The key safety and default behaviors are covered, but the parameter surface is only partially addressed.

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 covers text (Unicode, newlines require allow_newlines=true), replace (default true), and verify (exact readback), but says nothing about observe (none/tree/screenshot/both), selector, or wait_for, leaving three of seven parameters undocumented.

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 target: 'Set Unicode text on a focused, editable, non-password field.' The constraints (focused, editable, non-password) define exactly the class of element it targets and implicitly separate it from aua_tap, which is named as the focusing 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?

'Focus it with tap first' gives an explicit prerequisite and routes the agent to the sibling aua_tap, and 'Never blindly retry uncertain input' tells the agent what not to do. It stops short of naming alternatives for the input case (e.g., when to prefer press_button or batch), so not a full when/when-not/alternatives statement.

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

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

Annotations already cover read-only, idempotent, and open-world traits, and the description adds genuinely new context: the 20-second ceiling and the meaning of the two return fields condition_met and found. It does not say what happens when the timeout expires without the condition holding, which is the one behavior a waiting tool most needs to disclose.

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 compact sentences with the condition and time bound front-loaded and the return fields second. No filler 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?

With no output schema, the description usefully names condition_met and found, but it omits timeout failure behavior and any guidance on selector matching. For a three-parameter tool with a 0% described schema and a nested selector object, those omissions leave real gaps.

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

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

Schema description coverage is 0%, so the description must carry the load. It explains the state enum values (visible or gone) and the timeout cap, but says nothing about the nested Selector's twelve matching fields, leaving the most complex parameter undocumented in both schema and 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?

The description names a specific verb (wait) and resource (a selector reaching a visible/gone state) plus the hard time cap, which clearly separates it from aua_find or aua_locate. It stops short of naming any sibling explicitly, so the differentiation is 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?

The wait-on-a-condition framing implies the polling use case, but there is no statement of when to prefer this over aua_find, aua_scroll_until, or repeated aua_screen calls. An agent has to infer the alternative-selection rule.

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