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

With no annotations and no output schema, the description carries the full disclosure burden, yet four words do not say what format the result takes (package string, activity string, object), what happens on the home screen or when no app is foreground, or whether any permission is needed. It adds only minimal behavioral information.

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 certainly terse and front-loads the key noun phrase, but the terseness crosses into under-specification: it is a fragment rather than a complete sentence stating what the tool does or returns.

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-arg query tool with no annotations and no output schema, the description should at minimum state that it returns the current foreground package and activity and what the shape of that result is. It gestures at the content but leaves the return format and edge cases entirely unspecified.

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 and the schema is trivially complete, so there is nothing for the description to clarify here. Baseline 4 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?

The phrase 'Foreground package and activity' names the exact resource and implies a read of the currently active app, but it is a noun fragment with no verb, so the agent must infer that the tool returns the current foreground package/activity rather than setting it. It is distinguishable from siblings like app_list or app_launch by implication only, not by any explicit statement.

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

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

There is no when-to-use guidance, no mention of alternatives such as app_list (installed apps) or observe (screen state), and no stated preconditions. The agent gets only a topic, not a routing rule.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing about what 'launch' means (cold start vs bring-to-front), what happens if the app is already running, whether it blocks, permissions, or failure modes. Only the 'by package name' detail adds anything actionable.

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 and an inline pointer to the helper tool. It is efficient, though the brevity comes at the cost of the behavioral and parameter detail noted elsewhere.

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?

An output schema exists, so return values need not be explained, and the required parameter is identified. However, for a three-parameter action tool with zero annotation coverage and zero schema descriptions, the definition leaves two parameters and the launch semantics entirely undocumented.

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 three parameters. The description clarifies only that 'package' is a package name discoverable via app_list; 'max_wait_ms' (default 6000) and 'observe_after' (default true) are given no meaning in either the schema or the description, leaving an agent to guess what is waited on and whether observation output is returned.

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 app') with the key discriminator 'by package name', which separates it from gesture/screenshot siblings. It does not differentiate from the closely related app_stop/app_current lifecycle tools, 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?

The parenthetical '(see app_list)' implies you should resolve a package name first, which is useful implied workflow guidance. But there is no statement of when to use this versus app_stop or app_current, no precondition (already running? foregrounded?), and 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?

No annotations are supplied, so the description carries the full disclosure burden. It implies a read-only enumeration but never states that it is non-mutating, whether system/preinstalled packages are included, whether results are ordered, or whether package-visibility permissions are required - all material for an agent on a device.

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 resource comes first and the optional filter second. It is terse to the point of leaving gaps, but nothing in it 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?

An output schema exists, so return-value explanation is not required, and the tool is simple with one optional parameter. Still, an agent cannot tell from this text whether the listing includes system apps or how results are ordered, which are the remaining things it would need before relying on the output.

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%, with the single 'contains' parameter left undocumented in the schema, but the description compensates by explaining that it is a substring filter. It does not say what the substring is matched against (package name vs. label) or whether matching is case-sensitive, so the meaning is only partially added.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific resource ('Installed packages') and the operation (listing, carried by the tool name app_list), which is enough to separate it from app_launch, app_stop and app_current. It stops short of explicitly contrasting itself with those siblings, so it is clear but not maximally differentiated.

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 'optionally filtered by substring', which describes a parameter rather than when to choose this tool over app_current or app_launch. There is no statement of preconditions, no when-not-to-use case, and no named alternative.

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

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

With no annotations, the description carries the full behavioral burden, yet it discloses nothing beyond "force-stop": not whether unsaved state is discarded, whether the app is removed from recents, whether an error is raised for a non-running package, or whether special permissions are needed. The "force" wording hints at an abrupt kill, but that is the only signal.

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

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

One short, front-loaded sentence with no filler. It is efficiently written, though the brevity edges toward under-specification rather than optimal concision for a tool with an undocumented parameter.

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?

An output schema exists, so return values need not be described, but the definition still leaves too much unsaid for a destructive-feeling operation: the package format, failure behavior, and effect on running state are all absent.

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

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

Schema description coverage is 0%, so the description must compensate, and it does not. The single required parameter `package` is never explained – an agent gets no hint that it expects a package identifier such as com.example.app rather than an app display name.

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?

"Force-stop an app" pairs a specific verb (force-stop, not merely stop) with a clear resource (app), so the action is unambiguous. It does not differentiate itself from siblings like app_launch or app_current, leaving the agent to infer that this is the inverse of launching.

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?

There is no guidance on when to use this versus app_launch or a graceful stop, no preconditions (must the app be running?), and no stated consequences. Usage is only implied by the verb itself.

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

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

No annotations are supplied, so the description carries the full behavioral burden and adds almost nothing. It doesn't say whether the call blocks, what 'observe_after' triggers, whether the hold is interruptible, or what side effects a long press produces (context menus, drag initiation).

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 short sentence with no waste and the essential resource front-loaded. The brevity is efficient but leans into under-specification rather than earned concision.

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?

An output schema exists, so return values needn't be explained, but for a 4-parameter interaction tool with zero annotation coverage the definition leaves timing, waiting, and post-action observation behavior unexplained. An agent cannot confidently set hold_ms or observe_after 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?

Schema description coverage is 0%, so the description must compensate, and it only clarifies the 'target' format ('element handle or "x,y"'). The three optional parameters (hold_ms, max_wait_ms, observe_after) remain entirely undocumented in both schema and description, leaving their semantics to guesswork.

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 ('press and hold') and the accepted target forms ('an element handle or "x,y"'), which is more specific than the bare name. It doesn't explicitly contrast with the sibling 'tap', which is the key ambiguity, so it stops short of 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?

No guidance on when to choose long_press over tap, tap_text, or swipe, and no preconditions stated. The agent must infer that this is the 'hold' variant purely from the name.

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

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

No annotations are supplied, so the description must carry the full behavioral burden. It does disclose the payload content (interactive and labelled elements plus handles), which is meaningful, but omits that this is a read-only/non-mutating operation, anything about cost or latency, and whether the returned handles remain valid across subsequent calls.

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 tightly packed sentences with the purpose front-loaded and the optional behavior second. No filler, no repetition of the title or 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?

With no output schema the description does need to describe return content, and it does in brief (elements with handles). But the role of handles, the meaning of width, and whether this is a safe read are all absent, leaving the definition only partly sufficient for a tool that sits at the core of an automation loop.

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 for both parameters. It only accounts for 'screenshot'; the 'width' parameter (with its non-obvious 540 default) is never mentioned, leaving an agent unable to judge what width affects in the captured image or in the coordinate space.

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: 'List interactive and labelled elements on screen with handles', which is distinct from the sibling 'screenshot' that returns an image. It never names a sibling explicitly, so differentiation is inferable rather than stated, keeping it below 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?

'Optionally attach a screenshot' implies the common pattern of inspecting and capturing in one call, and the mention of handles implies this precedes tap/tap_text. However, it gives no explicit when-to-use-vs-screenshot rule and no prerequisites or 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?

With no annotations, the description must carry the burden; it does disclose the emulator-only constraint and the centering behavior (handle, "x,y", or screen centre), which is meaningful context beyond structured fields. It stays silent on timing/observation behavior such as max_wait_ms and observe_after, leaving a gap for a gesture tool.

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 dense sentence that front-loads the gesture and effect, followed by the constraint. Every clause contributes information; 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?

An output schema exists, so return values needn't be explained, and the gesture semantics plus target formats are covered. But for a 4-parameter gesture tool with no annotations, the unexplained timing/observation parameters leave it short of fully complete.

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

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

Schema coverage is 0%, so the description must compensate: it usefully clarifies that zoom takes 'in'/'out' and that target accepts a handle or "x,y" with screen-centre fallback. The remaining two parameters (max_wait_ms, observe_after) receive no explanation, so compensation is only partial.

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 gesture (two-finger pinch) and its effect (zoom 'in' or 'out'), which clearly differentiates it from single-finger siblings like swipe, scroll, and tap. It lacks an explicit contrast statement to those siblings, keeping it just below 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?

The 'Emulator gRPC only' note is a useful precondition, and the zoom framing implies when to reach for it versus swipe/scroll. However, it never explicitly says when not to use it or names alternatives for zooming, leaving usage 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?

No annotations are supplied, so the description carries the full burden, yet it says nothing about side effects, whether pressing power/delete is disruptive, or what the observable result is. The only behavioral insight is the keyboard-action-key explanation, leaving the mutation/safety profile and the effect of the wait/observe parameters undisclosed.

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 the core key list front-loaded and the special-case explanation following. The parenthetical alternatives are slightly dense but each adds real disambiguation value.

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

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

Key value semantics are covered thoroughly and an output schema exists so return values needn't be described. But with no annotations and two unexplained optional parameters, the definition doesn't fully arm an agent to invoke it with non-default wait/observe 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% across three parameters, and the description only adds meaning for 'key'. The optional max_wait_ms and observe_after parameters are completely undocumented in both schema and description, so an agent must guess at their units and effect.

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 ('Press a key') and enumerates the accepted key names, including the special 'enter'/'search'/'go' family, so an agent knows exactly what the tool targets. It stops short of differentiating from siblings like type_text or tap, which is why it falls short of 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?

Provides a useful conditional rule for the 'enter' variant ('when the keyboard is shown, which submits most search boxes and chat inputs'), which is genuine when-to-use guidance. However, it gives no guidance on when to choose press_key over type_text, tap, or tap_text, nor any prerequisites or 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?

With no annotations, the description carries the burden and does useful work: it discloses that rotation is a request that may silently not take effect, and tells the agent to confirm by reading the `orientation` header. It does not explain what max_wait_ms or observe_after do behaviorally, which limits it short of a 5.

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 with the action and its values, then the one behavioral caveat that matters. The "like a person turning the phone" analogy is slightly decorative but clarifies direction semantics rather than padding.

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?

An output schema exists, so return values need not be spelled out, and the description still notes the header field worth checking. However, for a 3-parameter tool with 0% schema coverage, the two timing/observation parameters are left undefined, which an agent needs to set sensibly.

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% with three parameters, so the description must compensate. It does this well for `orientation` by supplying the allowed values the schema omits, but `max_wait_ms` and `observe_after` remain entirely undocumented, leaving a meaningful gap for a tool where observe_after likely controls post-rotation capture.

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 ('Turn the device') plus the exact set of accepted values ('portrait', 'landscape', 'reverse_portrait', 'reverse_landscape'), and the phone-turning analogy fixes the meaning unambiguously. No sibling in the list (tap, swipe, screenshot, etc.) overlaps, so an agent can route here without checking schemas.

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

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

Sets clear preconditions for effective use: the display only follows if auto-rotate is on and the app permits it, and the agent should verify via the returned header. There is no competing alternative tool to exclude, so the lack of explicit "use X instead" wording is not a real gap.

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

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

With no annotations, the description carries the full burden, and it does disclose the output format (JPEG), the default device width (1080), and the important behavioral consequence that coordinates derived from the image must be scaled back. It omits whether the full screen or a cropped region is captured, and any size/rate limits.

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, tightly packed sentence: what is returned, how it is sized, and the practical implication for coordinates. Nothing is wasted and the return format is front-loaded.

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

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

For a one-parameter, read-only capture tool with no output schema, the description covers the essentials: format, sizing, and coordinate mapping. A brief note on screen coverage or how it differs from sibling visual tools would make it 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%, so the description must explain the single parameter, and it does: 'width' is the target pixel width, with the note that the device is usually 1080 wide and that coordinates must be scaled back. That adds meaning well beyond the bare integer schema and default of 540.

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 concrete resource and result: 'Current screen as JPEG', so an agent knows immediately this captures a visual snapshot. It does not explicitly distinguish itself from the sibling 'observe' tool, which likely also returns screen state, leaving some ambiguity about which 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?

Usage is only implied: the note about scaling coordinates back hints that this tool is used to locate elements before tapping. There is no explicit statement of when to use this versus 'observe' or when to prefer text-based element lookup over a pixel screenshot.

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

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

With no annotations supplied, the description carries the full disclosure burden and does add real behavior: the scroll is page-sized with deliberate overlap, and fling introduces coasting that can skip items. It does not disclose what happens if no scrollable element exists, nor how timing/waiting parameters affect blocking or observation, leaving notable 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?

Two tightly packed sentences with the action and its scoping stated first and the fling trade-off immediately after; every clause carries information. Minor noise from quoting the direction names adds little, but the text is otherwise economical.

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?

An output schema exists, so return values need no explanation. For a seven-parameter gesture tool with zero annotation coverage, the description covers the core action semantics and the main behavioral trade-off, which is enough for an agent to call it correctly; the undocumented timing params are defaults that rarely need changing. This is adequate rather than exhaustive, but nothing critical to a correct call is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: direction, distance (fraction of height/width), fling, and the handle-vs-screen notion of target are all given meaning. Three parameters — duration_ms, max_wait_ms, and observe_after — get no explanation at all, so roughly half the surface remains 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 description names a specific verb (scroll) with its four directions and scopes it to either a scrollable handle or the whole screen, so the resource and action are unambiguous. It does not explicitly differentiate itself from the sibling gesture tools such as swipe, which keeps it from 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?

There is clear conditional guidance for one parameter: fling=True is recommended for long lists but warns that items can be skipped, which is useful trade-off guidance. However, there is no statement about when to use scroll versus swipe, or when a scroll is inappropriate (e.g., nothing scrollable 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?

With no annotations, the description carries the full burden. It implies a read-only informational call via the listed fields, but never states that it is non-mutating, whether it requires an active session/device connection, or what the payload looks like beyond three named items. For a zero-annotation tool that is a meaningful gap.

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 a single short phrase with no wasted words, but the fragmentary style leaves the action ('reports/returns') unstated and the three listed items are not clearly framed as return values. Brevity here edges toward under-specification rather than efficiency.

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 parameterless diagnostic tool with no output schema, naming the three returned items is minimally sufficient. It does not indicate whether the list is exhaustive (e.g., also device/session state) or the format of values like 'pacing', so an agent cannot fully predict the response.

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 beyond what the empty schema already shows. Baseline 4 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?

The description lists the content of the report ('which backends are in use, screen size and pacing'), which distinguishes it from the action siblings like tap or screenshot. However, it is a noun-phrase fragment with no verb ('Returns...' / 'Reports...'), so the operation itself is only implied.

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?

There is no statement of when an agent should call this versus the other diagnostic siblings (observe, app_current, app_list). No prerequisites or exclusion conditions are given, leaving the agent to infer that this is a setup/debugging probe.

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

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

No annotations are supplied, so the description carries the full disclosure burden. It explains the hold_ms press-then-drag behaviour, but says nothing about duration, timing/wait semantics, or that this performs a real input action on the device with side effects.

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 tight sentence with the core action front-loaded and no filler. The trailing 'i.e. drag' is slightly redundant given the hold_ms explanation but costs little.

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?

An output schema exists so return values need not be described, but for a 6-parameter gesture tool with no annotations and zero schema coverage, half the parameters (duration, wait, observe) and the side-effect profile are left unexplained.

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

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

Schema description coverage is 0% across 6 parameters, and the description only adds meaning for start, end (accepted formats) and hold_ms. duration_ms, max_wait_ms and observe_after remain undocumented anywhere, so compensation is only partial.

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: 'Swipe from `start` to `end`', with the coordinate format clarified. It is clearly distinguishable from tap, long_press and pinch, though it does not explicitly contrast with the sibling 'scroll'.

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 rather than stated; the note that 'hold_ms > 0' turns the swipe into a drag gives one concrete condition for choosing behaviour. There is no explicit guidance on when to prefer scroll, pinch or long_press instead.

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

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

No annotations are supplied, so the description carries the full burden for an action that mutates UI state, yet it discloses nothing about blocking behavior, what max_wait_ms bounds, or what observe_after=true actually does after the tap. The default observe_after=true is a meaningful behavioral trait (it presumably captures a post-tap state observation) that the description leaves entirely unexplained.

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 tight sentence with the two accepted input forms front-loaded and no filler. It is well-formed but so terse that the terseness trades away needed detail rather than achieving efficiency.

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?

An output schema exists, so return values needn't be described, and the target formats are covered. However, for a state-changing interaction tool with zero annotations, silence on timing/waiting and the observe-after behavior leaves the agent guessing about side effects and post-call state.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies only the required target parameter's accepted formats and says nothing about max_wait_ms (units, what it waits for) or observe_after (what gets observed and returned). Two of three parameters remain semantically 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?

The description gives a concrete verb ("tap") and states the two accepted target forms with literal examples ("e7" for an element handle, "540,1200" for coordinates). That is enough to distinguish it from sibling tap_text, which presumably taps by visible text rather than handle or coordinates, though the distinction is only implied.

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?

There is no explicit guidance on when to use tap versus tap_text, long_press, or swipe, and no prerequisites or failure conditions are stated. The target format examples hint at usage but do not constitute when-to-use guidance.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It discloses that matching is substring-based and that the first match is tapped, but it says nothing about failure when no element matches, timeout behavior, whether tapping mutates state, or what observation follows the tap.

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 definition is a single front-loaded sentence with no redundant wording. It is concise and easy to parse, though its brevity contributes to gaps elsewhere.

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 tool has four parameters with no schema descriptions and no annotations, and the description covers only the matching semantics of one parameter. The output schema means return values need not be described, but the missing timeout, exact-match, observation, and failure behavior leave the definition substantially incomplete for a UI interaction 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?

Schema description coverage is 0%, so the description needs to explain the four parameters. It adds useful meaning for 'text' by clarifying substring and content-description matching, but it does not explain 'exact', 'max_wait_ms', or 'observe_after' at all.

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 uses a specific verb, 'Tap', and a specific target: the first element whose text or content description contains the supplied text. This clearly distinguishes it from coordinate-based 'tap' and text-entry 'type_text'. It does not explicitly name sibling alternatives, which keeps it just 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?

The description gives no explicit when-to-use guidance, no exclusions, and no comparison with siblings such as 'tap' or 'wait_for'. Usage is only implied by the tool name and the one-sentence behavior 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?

With no annotations, the description carries the burden and does disclose useful traits: focus requirement, Unicode acceptance, and that clear=True replaces rather than appends. It says nothing about what max_wait_ms or observe_after do behaviorally, nor about typing into non-editable targets, which is a meaningful gap for an unannotated mutation tool.

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, front-loaded with the core action and its precondition, with zero filler. Every clause conveys actionable 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?

An output schema exists, so return values need not be described, and the core action and clear semantics are covered. But half the parameters are unexplained and there is no failure-mode context (no focused field, non-editable target), which is thin for a four-parameter interaction 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?

Schema description coverage is 0%, so the description must compensate, and it only explains text and clear. The two timing/observation parameters (max_wait_ms, observe_after) get no meaning at all from either schema or 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 specific verb and resource ('Type into the focused field') and distinguishes itself from a plain tap by noting the field must be focused first. It does not explicitly name the tap_text sibling it competes with, so routing still requires inference.

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 parenthetical '(tap the field first)' gives a concrete precondition for use, which is genuine when-to-use guidance. However, it never states when to prefer this over tap_text or what to do if no field is focused, leaving the main alternative unaddressed.

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

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

With no annotations, the description carries the full behavioral burden and leaves out the most consequential details: what happens when the timeout elapses (exception, false, silently continue), whether the tool polls, and what observe_after actually toggles. It only states the waiting condition.

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, which is the right size for a simple wait primitive. The 'and/or' construction is the one piece of wording that costs clarity rather than saving space.

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?

An output schema exists, so return values need not be described. However, for a blocking/conditional tool with zero annotation coverage and no documented parameters, the definition is missing timeout semantics and the effect of observe_after, which an agent needs before calling it reliably.

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

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

Schema coverage is 0%, so the description must compensate for all four parameters. It adds real meaning for `text` ('label ... contains', matching text or content description) but says nothing about `timeout` (units, default 5, failure mode) or the non-obvious `observe_after` boolean.

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 gives a specific verb ('wait until ... appears') plus the matching criteria (label text or resource id), which is enough to distinguish it from wait_idle in the sibling list by inference. It stops short of explicitly naming that sibling or stating that no other tool blocks on a specific element.

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?

There is no guidance on when to prefer this over wait_idle or observe, nor on what to do if the element never appears. The 'and/or' phrasing also leaves the agent unsure whether both criteria are ANDed or ORed when both are supplied.

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

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

With no annotations, the description carries the full burden: it discloses that the call blocks until idle and yields an element list, which is genuinely useful. However, it never says what happens on timeout — whether it returns the list anyway, raises, or returns a partial/stale list — which is the single most important behavior for a waiting tool that has a max wait.

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

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

One compact sentence with the condition front-loaded before the parenthetical example and the return value. Efficient, though the nested parenthetical slightly interrupts the core instruction.

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?

An output schema exists so return values need not be spelled out, and the description correctly says it returns the element list. But for a blocking tool with a user-configurable timeout, the absence of any timeout or failure-mode statement leaves 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% for the single parameter max_wait_ms, and the description never mentions it at all. The timeout parameter is exactly the semantics that needs explanation (whether exceeding it causes failure or a best-effort return), so the description fails to compensate for the schema gap.

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 action (wait) with a precise termination condition (screen stops changing, nothing loading) and what it returns (the element list). The trigger phrase 'when the element list says `loading`' cleanly separates it from immediate-observation siblings like observe or screenshot.

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 an explicit entry condition tied to observable state ('loading' in the element list, e.g. a page still coming in). It does not name alternatives such as wait_for or explain when to prefer a fixed wait over this idle-based wait, so the exclusion side 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.