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

With no annotations, the description carries the full burden. It does disclose scope (only launchable launcher activities, returned as a package+activity tuple, for the current device), which is useful. However it never states that this is a read-only operation, what happens when no device is selected, or any error/permission 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 sentence with no filler, front-loading the verb and the exact resource returned. Nothing to trim.

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 zero-parameter read tool with no output schema and no annotations, the description adequately conveys what is listed and in what form (package + activity). It is slightly incomplete about the dependency on a prior device-selection step and failure behavior, but nothing critical is missing for correct invocation.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the implicit reliance on the already-selected 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 ('List') and a precise resource ('installed launcher activities (package + activity)'), which separates it from phone_devices and phone_launch. It does not name a sibling explicitly, 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 phrase 'on the selected device' hints that a device must already be chosen (presumably via phone_connect/phone_devices), but there is no explicit when-to-use or when-not-to-use statement, and no pointer to phone_launch as the natural follow-up. 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 of behavioral disclosure. It only says it presses a button; it never mentions the implicit re-observation of UI state, the requirement of an active connection, or side effects of navigating back. The observe/settleMs parameters hint at behavior but the description itself adds nothing beyond the action verb.

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 padding; the action verb comes first and the qualifier is parenthetical. 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 simple action tool with no output schema and fully documented parameters, the description is minimally adequate but leaves out the connection prerequisite and the implicit post-action UI observation behavior. It is enough to call the tool, but thin on context.

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?

All three parameters have 100% schema description coverage, so the schema already documents observe, settleMs, and includeScreenshot fully. The description adds no parameter-level meaning, making the baseline 3 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 and target ('Press BACK'), which is unambiguous as an action on the device's back button. The parenthetical ties it to sibling phone_key as a specialized shortcut, giving partial sibling differentiation, though it never explicitly distinguishes from phone_home or explains what 'BACK' means in navigation terms.

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 'convenience wrapper around phone_key' note gives clear routing context: use this shortcut for the back action rather than configuring phone_key directly. It names the alternative but offers no explicit when-not conditions or prerequisites (e.g., a connected device).

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

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

With no annotations, the description carries the full behavioral burden. It discloses the composite behavior (enumerate, select, return a screen summary) and an env-var fallback, but says nothing about connection persistence across subsequent tool calls, what happens on ambiguous or missing device, or whether selection has 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?

Three short sentences, each earning its place: what it does, when to call it, and how to supply the device. The action and the "call this first" instruction are front-loaded.

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

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

For a one-optional-parameter tool with no annotations and no output schema, the description covers the action, the return value at a high level, and the parameter's dual supply path. The remaining gap is failure/persistence behavior, which is minor here.

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% and the schema already documents device as an ADB serial with an example, so the baseline is 3. The description adds real value beyond the schema by revealing the alternative supply path (ANDROID_SERIAL environment variable) and that the parameter is optional in that case.

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 concrete actions (list ADB devices, select one, return a screen summary) with a specific resource, so the agent knows exactly what happens. It is weaker on sibling differentiation: phone_devices also appears to enumerate devices, and the description never explains how the two relate.

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?

"Call this first" gives explicit sequencing guidance relative to the rest of the phone_* family, which is genuinely useful context. It stops short of naming an alternative or stating when-not to use it (e.g., when phone_devices should be used instead), so it is clear context without 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 full burden, and it does disclose the critical side-effect profile: the call is non-mutating (selection unchanged) and does not observe the UI, so an agent knows it is a safe, idempotent read. It stops short of describing the return shape or behavior when no devices are attached.

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 affirmative action front-loaded and the disqualifiers trailing. Every clause carries information; nothing is 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?

For a zero-parameter, annotation-free, output-schema-free read tool, this covers the essentials the agent needs: what it lists and what it will not disturb. The only missing piece is an explicit cue for when to call it versus the other phone_* tools.

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 the baseline is 4. There is nothing for the description to clarify at the parameter level, and it correctly does not spend words on inputs.

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 ("List connected ADB devices") and adds the scope qualifier that separates it from siblings: it does not change the selection and does not dump the UI, implicitly distinguishing it from phone_connect and phone_observe. An agent can identify it 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?

The negative constraints ("without changing the current selection or dumping the UI") imply this is a passive inspection call, but there is no explicit statement of when to reach for phone_devices versus phone_connect or phone_observe. Usage is inferable rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it is a single clause. It does not say the device state changes (navigating to the home screen), whether the action is safe/idempotent, or what the call returns.

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 zero filler; the action comes first and the clarifying note follows in parentheses.

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 zero-required-parameter action with fully documented schema and no output schema, the description is minimally sufficient. It leaves thin gaps around device-state effect and why the wrapper exists, but nothing blocks correct invocation.

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

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

The description mentions no parameters, but schema coverage is 100% with clear descriptions for observe, settleMs, and includeScreenshot. Baseline 3 applies when the schema fully documents the 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+resource ("Press HOME") and clarifies its relationship to the sibling phone_key as a convenience wrapper, which helps distinguish it. It does not, however, say how it differs from simply calling phone_key with a HOME keycode.

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?

By naming phone_key as the underlying operation, it implies this is a shortcut alternative, but it never states when to prefer this over phone_key directly or on which platforms/devices it applies. Usage is implied rather than specified.

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 exist, so the description carries the full burden. It does disclose the return shape ("Returns the resulting screen"), which is useful, but it says nothing about side effects of keys like POWER (screen off), or that re-observation happens by default — the latter only surfaces in the schema.

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 purpose and then the value list; nothing is padding. The key enumeration is long but earns its place as a usage hint, though it slightly buries the return-value statement.

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 4-param, mutation-style tool with no output schema and no annotations, the description covers what it does, valid inputs, and the return. Missing only side-effect caveats and sibling routing, which keeps 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 100%, so the baseline is 3, but the description exceeds it by enumerating concrete accepted key names (HOME, BACK, ENTER, DPAD_UP/DOWN/LEFT/RIGHT, PASTE) that the schema only refers to abstractly as "Key name or KEYCODE_* or numeric keycode".

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 an Android keyevent") and enumerates concrete key values, so an agent knows exactly what this does. It does not, however, distinguish itself from siblings that are effectively keyevent wrappers (phone_back, phone_home), leaving overlap unaddressed.

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 or when-not-to-use guidance and no routing to alternatives. With phone_back, phone_home, and phone_type present, an agent gets no signal about whether to call those dedicated tools or send BACK/HOME/PASTE through phone_key.

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 behavioral burden, and it discloses almost nothing beyond input formats. It does not state that the action executes on a connected device, what happens if the app is not installed or the alias is unknown, or whether launching is idempotent/side-effecting. The re-observation and screenshot behavior is only visible through parameter names, not explained in the description.

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 three accepted forms, with the alias enumeration appended as directly usable data. No filler or repetition.

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

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

For a 4-parameter tool with no annotations and no output schema, the description covers input formats well but is silent on the operational context (device connectivity, error cases) and does not hint at what the response contains. Adequate to call correctly, but thin on surrounding context.

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 baseline is 3. The description goes beyond the schema's terse 'Package, component, or alias' by enumerating real aliases (settings, chrome, camera, gmail...) and showing concrete package and component syntax, which meaningfully reduces input-format guessing.

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) and resource (an app) and enumerates the three accepted identifier forms with concrete examples (com.android.settings, pkg/.Activity, and the alias list). An agent immediately knows what the tool does. It does not explicitly contrast with siblings like phone_apps or phone_observe, but the launch-vs-list/dump distinction is self-evident.

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 imperative 'Launch an app' and the alias list gives practical guidance on valid inputs. However, it never states preconditions (e.g. a device must be connected via phone_connect first) or when to prefer this over phone_apps/phone_observe. No explicit when-to-use or when-not-to-use guidance is present.

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

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

No annotations are provided, so the description carries the full burden. It discloses the capture mechanism (uiautomator dump / accessibility-style tree), the return format (numbered element list for tapping), and a key limitation workaround (screenshot fallback for canvas/game/Chrome content). It does not explicitly state read-only safety, performance characteristics, or permission needs, but the observe/capture framing implies a non-mutating operation.

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

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

Two sentences, front-loaded with the primary action and mechanism, followed by the fallback condition. Every sentence earns its place and there is no redundant repetition of the schema or 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?

This is a simple read-only observation tool with one optional parameter and full schema description coverage. No output schema exists, but the description states the return format (numbered element list for tapping) and covers the important fallback behavior. It is complete enough for an agent to invoke correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema's 'Include a PNG screenshot in the response' by specifying when to set includeScreenshot: when the UI tree is not enough, such as games, canvas, or Chrome content. That is useful decision context for the only parameter.

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: capture the UI hierarchy via uiautomator dump and return a numbered element list for tapping. It distinguishes itself from the screenshot sibling by explaining the includeScreenshot fallback for non-tree content like games, canvas, and Chrome. An agent can tell what this tool does and why it exists relative to phone_screenshot without opening the 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?

Gives clear usage context: use this to capture the UI hierarchy and get a numbered element list for tapping, and explicitly set includeScreenshot when the tree is not enough (games, canvas, Chrome content). It lacks an explicit 'when not to use this' statement or named alternatives beyond the parameter fallback, but the guidance is concrete enough for selection.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the PNG format and that the current display is captured, but says nothing about how the image is returned (base64 payload vs. saved file path), which is critical since there is no output schema.

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 word 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 simple no-argument tool this is nearly adequate, but the absence of annotations and of any output schema means the return format remains unspecified, which is the one piece an agent would want before invoking a screenshot 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 per the baseline there is nothing for the description to clarify beyond what the empty schema already implies. No parameter meaning is 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?

The description states a specific verb ('Capture') and resource ('screenshot of the current display') with the output format (PNG), so the purpose is unambiguous. It does not, however, distinguish itself from siblings such as phone_observe, which may also return visual state, leaving the agent to infer the difference.

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 alternatives like phone_observe, nor any exclusions or prerequisites. The usage is only implied by the tool name, not stated in the description.

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

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

With no annotations, the description carries the full behavioral burden. It does disclose the return ("the resulting screen"), which is useful, but says nothing about what side effects the gesture has, what happens if neither coordinates nor direction are supplied, defaults for observe/settleMs, or the device-state impact.

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

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

Two short sentences with no filler, and the primary coordinate form is front-loaded ahead of the directional alternative. Efficient, though it could carry more substance for a 10-parameter tool.

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

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

For a 10-parameter mutation tool with no annotations and no output schema, the description is thin. It omits default behaviors, the zero-required-parameter ambiguity (what happens with no arguments), and how the observation-related parameters interact with the returned screen.

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 40%, and the four coordinate parameters plus direction and durationMs are undocumented in the schema. The description partially compensates by clarifying the (x1,y1)→(x2,y2) start-to-end ordering and the direction enum values, but leaves distance, durationMs, observe, settleMs, and includeScreenshot behavior 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 ("Swipe") and enumerates the two supported invocation modes: coordinate pairs and directional finger swipes. An agent can distinguish it from phone_tap or phone_type, 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?

The description explains the two ways to invoke a swipe but gives no guidance on when to swipe versus tap, key, or back, and no prerequisites or constraints. Usage context is left entirely 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?

With no annotations, the description carries the full behavioral burden. It does disclose a key trait — that the tool returns the resulting screen and that durationMs turns the tap into a long-press — which is valuable given there is no output schema. It omits other meaningful behavior, such as the default UI re-dump after each action (observe default true) and the settleMs wait, both of which affect timing and 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 tight sentences with zero filler: the action plus targeting modes first, then the long-press modifier, then the return behavior. Front-loaded and every sentence earns its place, especially the return-value statement given the absence of an output 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 13-parameter, annotation-free, output-schema-free tool, the description is only partially complete. It covers the targeting model and return behavior adequately, but leaves six parameters (including behaviorally significant ones like observe and settleMs) unexplained and does not describe failure modes when an element selector matches nothing.

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 77%, close to the high-coverage baseline, so the schema already documents most parameters. The description adds real semantic value by grouping the element selectors (index, text, resourceId, contentDesc) as alternatives drawn from the last phone_observe, but it says nothing about the remaining params (className, packageName, textContains, observe, settleMs, includeScreenshot).

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

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

States a specific verb and resource ('tap' on the screen) and explicitly defines the two targeting modes: pixel coordinates or an element from the last phone_observe. This clearly separates it from siblings like phone_swipe, phone_type, and phone_key, and it names the observe dependency that makes the element-targeting mode work.

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

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

Usage is implied through the two targeting modes and the note that long-press is achieved via durationMs, plus the prerequisite that element-based taps must reference the last phone_observe. However, there is no explicit when-to-use/when-not guidance and no routing to alternatives (e.g., phone_swipe for gestures, phone_type for text entry), so the agent must infer the boundaries.

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 meaningful internals: ASCII text goes through 'adb input text' while other characters use clipboard paste, and it returns the resulting screen. It stops short of warning about side effects such as clipboard contents being overwritten or failure modes for unsupported characters.

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

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

Four short sentences, front-loaded with the core action before implementation detail and return behavior. Every sentence contributes information with no 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?

For a 10-parameter tool with no annotations and no output schema, the description covers the action, the ASCII/clipboard split, and the return ('resulting screen'). It omits error behavior and clipboard side effects, which is a minor gap given the schema fully documents every parameter.

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 every parameter is already documented; the description adds only the hint that a selector can be tapped first, which the index/className/resourceId params already convey. Baseline 3 is appropriate since 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?

States a specific verb and target ('Type into the focused field') and clarifies the optional selector-tap prerequisite, so an agent can distinguish text entry from the sibling phone_tap. It never names a sibling tool explicitly, so differentiation is implicit 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?

Gives actionable context: use it for the focused field, and 'Optionally tap a selector first' tells the agent how to target a field that isn't focused yet. There is no explicit when-not-to-use or named alternative (e.g., use phone_tap for non-text targets).

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