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

No annotations exist, so the description carries the full behavioral burden. It does disclose the successful return payload (device model and Android OS version), which is genuinely useful. It says nothing about failure behavior (no device attached, timeout, adb not running) or whether the call blocks, leaving a meaningful gap for a connectivity probe.

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 purpose and the return value are both stated economically.

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 no annotations, so the description must cover the result — and it does by naming model and OS version. It is nearly sufficient for a zero-parameter probe, with only failure/timeout behavior left 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?

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline is 4. The description correctly implies no arguments are needed to probe the active device.

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 (check) and resource (connection status with Android device/emulator) and even names the payload returned. Against siblings that are all device-mutating actions (tap, swipe, screenshot, shell), an agent can tell this is the read-only connectivity probe without opening any schema.

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 explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. The intended usage (verify a device is reachable before issuing tap/swipe/shell commands) is only implied by the tool name and description.

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

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

With no annotations, the description carries the full disclosure burden. It usefully explains the mechanism (UI-hierarchy search, match on text or content description, tap the center), but omits failure behavior, ambiguous/multiple match handling, and any prerequisite that the target screen be visible. Partial transparency for a no-annotation 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 front-loaded sentence that states the mechanism and the action without waste. 'Smart-click:' is mild marketing framing rather than informative content, a small deduction.

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 action tool with no annotations and no output schema, the description covers the mechanism adequately but leaves the agent uninformed about the result of the tap, multiple-match behavior, and failure cases. Adequate but with clear 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 100% and there is only one parameter, so the schema already explains `text`. The description reinforces that matching accepts text OR content description, adding marginal meaning over the schema but no syntax, exact-match vs substring, or precedence rules.

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

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

States a specific verb (taps/clicks) and resource (an element matched by text or content description), and the mechanism ('searches the screen UI hierarchy') distinguishes it from coordinate-based android_tap. It is clear but never explicitly names a sibling, so differentiation is left implicit.

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 text-matching mechanism suggests using this when you know the label but not the coordinates, implicitly versus android_tap. There is no explicit when-to-use, when-not-to-use, or fallback guidance (e.g. what to do if no match is found).

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 implies a read-only inspection and discloses returned fields, but does not mention permissions, side effects, or explicit read-only behavior, leaving some uncertainty.

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 wasted words. It efficiently conveys both purpose and output in one clause.

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 tool with no output schema, the description covers what is inspected and returned. However, it does not clarify the hierarchical ('tree') structure or any limitations, leaving some gaps for an agent to infer.

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

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

The tool has zero parameters, so the baseline is 4. The description adds no parameter meaning because there are no parameters to explain.

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 'Inspect' and resource 'all visible UI elements on the current Android screen', and specifies the returned fields. It is clear but does not explicitly differentiate from siblings like android_screenshot or android_tap.

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 no guidance on when to use this tool versus alternatives such as android_screenshot or android_tap. It simply describes the function without context or 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?

No annotations are provided, so the description carries the full disclosure burden, and it discloses almost no behavior. It does not say what happens if the package is not installed, whether the call blocks until the app is foregrounded, whether it requires the device to be connected, or what an error looks like. For a device-mutating action tool this is a significant 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?

One sentence, front-loaded with the action and the required argument, and the inline example earns its place by demonstrating the package-name format. 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 simple one-parameter action with no output schema this is adequate but thin. Because there are no annotations to cover the safety and side-effect profile, the description should say at least whether the device must be connected and how failure (app not installed) is surfaced.

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 100% schema description coverage and a single parameter, the schema already does the documenting, so a 3 is the baseline. The description adds only the reverse-DNS example 'com.android.settings', which hints at the expected format but is marginal value.

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 ('Launch') plus resource ('Android app') and the identifier it operates on ('package name'), which is enough to distinguish it from android_stop_app and android_list_apps at a glance. It stops short of explicitly naming a sibling or contrasting behaviors, so it is clear but not fully 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?

There is no statement of when to use this tool versus alternatives such as android_list_apps (to discover a package name) or android_check_connection (to verify a device is reachable first). Usage is only implied by the verb itself, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full burden. It discloses the return content ('package names') but says nothing about ordering, whether it requires a connected device, or that the default behavior filters out system apps — a behavioral trait an agent must know.

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 zero filler; appropriate size for a one-parameter read tool. No structural problems, though there is no routing or constraint information to front-load beyond the core purpose.

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

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

Adequate for a simple listing tool with no annotations or output schema, but it omits the most decision-relevant fact — that third-party-only filtering is on by default — and gives no hint about the presence of a device connection requirement. Minimum viable rather than complete.

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

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

Schema coverage is 100%, so the only parameter (third_party_only, default true) is fully documented in the schema; baseline 3 applies. The description adds nothing about this filter and its wording ('installed applications') could actually imply all apps, mildly clashing with the default filtering behavior.

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 ('List installed application package names') and is clearly distinguishable from siblings like android_launch_app or android_stop_app, which manipulate rather than enumerate apps. It does not explicitly name a sibling to contrast against, but none of the siblings overlaps its purpose.

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

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

No guidance on when to use this versus alternatives such as android_shell (which could also enumerate packages) or android_get_ui_tree. No prerequisites or context about when a listing is the right call.

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

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

No annotations are provided, so the description carries the full burden. The effect of a key press is largely self-evident and the key set is enumerated, but nothing is said about required device state, whether the action blocks, or what the side effects of POWER/VOLUME keys are.

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 the verb, resource, and allowed values, and zero filler. Nothing could be trimmed without losing information.

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

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

For a one-parameter tool with no output schema, the description covers the action and the valid key set adequately. A minor gap remains: it does not indicate what the caller gets back or any precondition such as a connected device.

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

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

Schema description coverage is 100% and the single parameter is a fully enumerated string, so the schema already documents everything. The description merely repeats the enum values, adding no syntax, defaults, or format detail beyond the structured field.

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 ('Press an Android hardware/system key') and enumerates the exact keys, so the purpose is unmistakable. It implicitly separates itself from siblings like android_type_text or android_tap by scoping to hardware/system keys, though it never names an alternative explicitly.

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

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

Usage is only implied: an agent can infer this is for BACK/HOME/POWER-style system keys rather than text entry or coordinate taps. There is no statement of when to prefer it over android_tap or android_type_text, and no prerequisites (e.g., an active device connection) are given.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the return encoding ('base64 PNG'), but does not state device prerequisites (e.g. connection state), whether it is a side-effect-free read, image dimensions/size, or failure behavior.

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; every clause (capture, target device, output format, purpose) earns its place.

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

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

For a zero-parameter tool with no output schema, the description covers what the agent most needs: what is returned and in what encoding. Only minor gaps remain (device-connection precondition, error 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?

The tool takes zero parameters, so there is nothing to document and the baseline is 4. The description correctly adds no spurious parameter detail.

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

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

States a specific verb ('Capture'), resource ('current screen of the Android device'), and output form ('base64 PNG image'), which makes it clearly distinct from text-oriented siblings like android_get_ui_tree. It does not explicitly name a sibling, but the purpose is unambiguous.

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

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

The phrase 'for visual analysis' implies the intended use case, distinguishing it from tree/text inspection tools, but there is no explicit when-to-use/when-not-to-use guidance or named alternative. Usage is only 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?

No annotations are provided, so the description carries the full burden. It does not disclose whether the command runs as a specific user, sandboxing, timeout, output capture, error handling, or whether it is destructive — all critical for an arbitrary shell executor.

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?

Single, front-loaded, zero-waste sentence.

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 arbitrary shell execution tool with no annotations and no output schema, the description omits essential behavioral context (result format, limits, permissions, risk profile) an agent needs to invoke it safely.

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

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

Schema coverage is 100% with a single documented 'command' parameter. The description adds no syntax guidance or examples beyond the schema baseline, so 3 is appropriate.

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

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

States a specific verb (Execute) and resource (ADB shell command on the Android device). Clearly distinct from siblings like android_tap or android_screenshot which target specific interactions rather than arbitrary shell execution.

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 use this versus the many specialized sibling tools. An agent cannot tell whether to prefer android_shell for a task that a dedicated tool (e.g., android_list_apps, android_get_ui_tree) also covers.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Force-stop' implies a destructive, process-killing action, but the description does not state whether it clears app data, requires root permissions, affects other running instances, or what side effects occur.

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 zero waste. It immediately conveys the core action and scope without unnecessary elaboration.

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 one-parameter tool with full schema coverage and no output schema, the description is minimally adequate. However, with no annotations and no behavioral detail about the force-stop operation's side effects or prerequisites beyond the word 'running,' it leaves some contextual 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 100%, and the single parameter 'package_name' is fully documented in the schema as 'The app package name.' The description adds no further parameter meaning, so the baseline score of 3 applies.

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

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

The description states a specific verb ('Force-stop') and resource ('Android application'), making the tool's action clear. However, it does not explicitly differentiate itself from siblings like android_launch_app or android_shell, so it falls short of the sibling-distinguishing standard for 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 guidance on when to use this tool versus alternatives such as android_launch_app or android_shell. It only implies usage through the action itself, with no exclusions, prerequisites, or alternative-routing information.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, yet it only restates the gesture. It does not say whether the call blocks until the gesture completes, whether coordinates are device pixels or density-independent units, or whether the gesture can be interrupted.

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 zero filler that states the action and the two endpoints immediately. Nothing is padded or redundant.

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

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

For a simple 5-parameter gesture tool with no annotations and no output schema, the description is minimally sufficient but leaves notable gaps: coordinate space, blocking behavior, and how duration_ms affects gesture speed/fling are all unaddressed.

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

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

Schema description coverage is 100%, so the four coordinates and duration_ms are already documented in the schema; the description merely mirrors the (x1, y1) to (x2, y2) mapping. Baseline 3 is appropriate when the schema does the heavy lifting.

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 ('swipe or drag') and resource (a gesture between two coordinate pairs), plus the exact direction of the motion. It naturally distinguishes itself from android_tap, but it never explicitly names or contrasts with that sibling, so it lands just below the top band.

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 to use a swipe versus a tap, drag, or shell input command, and no prerequisites or constraints. An agent must infer the use case entirely from the phrase 'swipe or drag'.

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 about requiring an active device/session, whether the tap waits or returns immediately, or what happens on out-of-bounds coordinates. For a UI-interaction tool with zero annotation coverage this is a significant 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?

A single front-loaded sentence with no filler or redundancy. It is efficiently sized, though so terse that brevity shades into under-specification.

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 touch-input primitive with no annotations and no output schema, the description omits anything about connection requirements, failure behavior, or return values. An agent cannot tell from this text alone what preconditions the call needs.

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

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

Schema description coverage is 100% (both x and y are documented in pixels), so the schema already does the heavy lifting. The description merely restates '(x, y)' and adds no detail such as coordinate origin or screen-resolution dependence, matching the baseline 3 for high-coverage schemas.

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 clear verb (tap) and resource (screen coordinates), so the basic action is unambiguous. However, it does not differentiate itself from the sibling android_click_by_text, which is the obvious alternative for the same intent, so it falls 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?

There is no guidance on when to tap coordinates versus using android_click_by_text, nor any prerequisite such as an active device connection or needing a screenshot first. The agent is left to infer usage entirely.

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 does not say whether existing text is replaced or appended, what happens if no field is focused or an IME is blocked, or what errors/results to expect. For a mutating input action this is a notable 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?

One tight sentence with the action and target front-loaded and no filler. It is appropriately sized for a single-parameter tool, though it stops short of adding the extra operational detail that would make the brevity fully earned.

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

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

The core action is complete for a simple one-parameter tool, but with no annotations and no output schema the description omits focus prerequisites and failure/return behavior. Adequate but leaves clear gaps for an agent invoking it blind.

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 has full schema description coverage ("The text string to type") and there is nothing to clarify about format, so the baseline of 3 applies. The description adds no semantics beyond what the schema already provides.

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 (type) and resource (a string of text) plus the target (currently active input field), which cleanly separates it from android_click_by_text or android_press_key. It does not explicitly name any sibling, but the action 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 phrase "currently active input field" implicitly signals the prerequisite that a field must already be focused, but there is no explicit when-to-use, when-not-to-use, or pointer to alternatives (e.g., android_click_by_text to focus a field first). Usage is only inferable.

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