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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds essentially nothing beyond restating the likely return value (foreground package and activity), which the output schema already covers. No mention of refresh/latency, multi-device behavior, or what happens when no app is in the foreground.

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 zero filler, front-loaded and easy to scan. It is efficient, though its brevity is closer to under-specification than genuine economy.

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?

Although an output schema exists (so return structure need not be described), the definition leaves the device-selection parameter unexplained and gives no indication of when in a workflow this check should be used. For a device-automation tool with 12 siblings, that is a meaningful gap.

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

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

There is one parameter, 'serial', with 0% schema description coverage and a default of empty string. The description never explains that this selects the target device or what the empty default implies (e.g., default device). With one undocumented parameter, the description fails to compensate for the coverage 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?

The phrase 'Package and activity in the foreground' identifies the resource being queried (the foreground app's package/activity), which is distinct from siblings like list_apps or launch_app. However, it is a noun fragment with no verb, so the agent must infer that this is a read/query operation rather than a state change. Minimum viable but not explicit.

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

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

No guidance is given about when to call this versus alternatives such as list_apps or screen_elements, nor any prerequisites or ordering constraints within a device-automation flow. The agent must guess whether this is a precondition check for tapping/typing or a standalone query.

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

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

Annotations declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds that it lists adb-visible devices, which is contextual value, but doesn't mention output format or any behavioral nuances beyond what annotations provide.

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, efficient phrase that front-loads the resource and enumerates returned fields without any fluff.

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?

Given no parameters and an output schema, the description needn't explain return values. It's nearly complete but lacks usage context relative to siblings.

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

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

With 0 parameters, the baseline is 4. The description correctly implies no parameters are needed.

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 resource ('devices') and what it returns ('serial, model and state'). It's clear what the tool does, though it doesn't distinguish itself from siblings like list_apps or screen_elements beyond the resource name.

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 or in what context. The purpose is implied but there's no explicit when/when-not.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value by noting that existing app data is preserved (unlike a clean reinstall), but it says nothing about permissions, failure modes (e.g. signature/downgrade rejection), or which device is targeted when serial is empty.

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; the operative action and its most surprising behavior (data retention) appear immediately.

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 annotations cover safety. However, for a mutating tool with 0% parameter coverage, descriptions of the path/serial semantics and the multi-device targeting behavior are missing, leaving an agent to guess how to invoke it 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 0%, so the description must carry the burden. 'APK from this computer' usefully implies path is a local host file path, but the serial parameter is entirely unexplained — no hint that it selects a device, its adb-style format, or what the empty default means.

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 (install/update), a specific resource (APK), the source (this computer, i.e. the host filesystem rather than the device), and a key semantic (keeps the app's data). No sibling tool performs installs, so the purpose is unambiguous; the only gap is the absence of any device-targeting context.

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 when-to-use guidance: nothing says whether this requires a connected device, how it relates to launch_app/list_apps (e.g. install before launch), or how to choose between the default device and the one named by serial. The 'install or update' phrasing only weakly implies context.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds no behavioral context beyond that — nothing about starting an activity, foregrounding behavior, failure modes for an unknown package, or device targeting.

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 the action and its key input front-loaded; no filler or redundancy. It earns its place entirely.

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 mutation-free annotation set keeps the safety story short. Still, the unexplained 'serial' parameter and the absence of any install-state or failure behavior leave the definition only minimally adequate.

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

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

Schema description coverage is 0%, so the description carries the full burden. It clarifies the 'package' parameter (a package name, discoverable via list_apps) but says nothing about the 'serial' parameter, leaving half the parameters undocumented in both schema and description.

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

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

States a specific verb+resource ('Open an app') and names the identifying key ('by its package name'), which is enough to distinguish it from install_apk, list_apps, and current_app. It cross-references list_apps but does not explicitly contrast its scope with those siblings.

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 list_apps)' gives useful implied guidance on how to obtain a valid package name. However, there is no explicit when-to-use vs when-not guidance, no note that the app must already be installed, and no mention of what happens if the package is absent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds nothing beyond that: it says nothing about which device is queried, whether results are affected by serial/include_system, or how the listing is scoped.

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 the key qualifier front-loaded. It is efficient, though the terseness borders on under-specification for a three-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?

An output schema exists, so return values need not be described, but the description leaves the device-selection parameter and the system-app toggle undocumented. For a tool with three optional params and zero schema coverage, this is not complete enough.

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, so the description must compensate and does not. Only 'filter' is mentioned (vaguely, as a containment match), while 'serial' and 'include_system' are entirely unexplained in both schema and description.

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

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

The description names the resource ('Installed packages') and the tool name supplies the verb 'list', so an agent can tell it apart from siblings like launch_app and install_apk. It is clear but slightly elliptical, reading as a noun phrase rather than a full statement of 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?

There is no explicit when-to-use or when-not-to-use guidance, nor any mention of alternatives such as current_app or devices for related questions. The optional-filter behavior is the only usage hint.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful scope context (results are 'recent', filterable by app and to errors only), but says nothing about volume limits, truncation, or how log lines are ordered.

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

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

A single compact sentence with the resource front-loaded and the usage cue following. No filler, though the colon-dependent clause structure slightly buries the filtering semantics.

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 format need not be described, and annotations cover the safety profile. For a low-complexity four-param read tool the description is nearly sufficient; only the serial and lines parameters remain opaque to the agent.

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% for all four params, so the description carries the burden and only partially meets it: 'one app's lines' maps to package and 'only errors' maps to errors_only, while lines and serial are left entirely unexplained in both description and schema.

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 resource (recent system log) with explicit scope modifiers ('optionally only one app's lines and only errors'). It is clearly distinguishable from the device-automation siblings since none of them retrieve diagnostics, though it never states this distinction 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?

Gives a concrete trigger context — 'the place to look when an app crashes' — which tells the agent when this tool is the right choice. No alternatives or exclusion conditions are named, but none of the siblings overlap meaningfully, so little is left to inference.

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

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

Annotations already declare the safety profile (readOnlyHint=false, destructiveHint=false, openWorldHint=false), so the description need not restate that. Beyond the list of key names it discloses nothing about behavior: no effect description, no requirement for a connected/foreground device, and no note on what happens on failure.

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

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

A single front-loaded sentence with zero filler; every token is the actionable list of valid keys. 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a 0%-coverage two-parameter tool the description omits the `serial` parameter entirely and gives no indication that a target device is required.

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% and there are no enums, so the description carries real weight by enumerating the accepted values for `key` (back, home, recents, enter, delete, tab, volume_up/down, power, menu, search). However, the second parameter `serial` is entirely undocumented in both schema and description, leaving device targeting 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 (press) and enumerates the exact key values accepted, which makes the action unambiguous. It does not distinguish itself from siblings like tap_element, type_text, or tap, so an agent must infer that this issues hardware/navigation key events rather than touch or text input.

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 tool versus tap, tap_element, or type_text, and no stated prerequisites (e.g., an active device connection). The enumerated list implies valid inputs but gives no routing context 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?

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=false), so the description is not the sole source of truth. It adds real behavioral value beyond them: the cost/precision trade-off versus screenshotting and what the returned elements consist of. It does not mention failure modes such as a missing or unreachable 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?

Two compact sentences, no filler: the payload definition comes first and the routing hint second. Every clause carries information.

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

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

An output schema exists, so return values need not be re-explained, and the description appropriately covers purpose and alternative selection. The only gap is device targeting via the undocumented 'serial' 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?

There is one parameter ('serial') with 0% schema description coverage, and the description never mentions it or explains that an empty default means 'current/default device'. With an undocumented optional parameter, the description should compensate and does not.

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

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

States a specific resource ('each visible text or touchable element') and enumerates the returned fields (centre, type, id, state) in a single front-loaded clause. It also names the sibling tool it competes with (screenshot) and the axis of comparison, so an agent can pick it apart from the other read tools immediately.

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?

'Cheaper and more precise than a screenshot for tapping' gives a clear selection condition against a named alternative. It stops short of an explicit when-not (e.g. view this only when visual appearance or rendering matters), leaving the converse inference to the agent.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond what the annotations provide: no statement of the return format (raw image, path, base64), no latency/size caveats, and no note that an image result differs qualitatively from screen_elements' structured output.

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 sentence, front-loaded with what the tool produces and followed by its application scope; there is no filler. It is appropriately sized for a simple tool, though the terseness leaves gaps that other dimensions penalize rather than this one.

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 read-only single-parameter capture tool with no output schema, the minimum needed is stated purpose and rough usage, both of which are present. However, since the tool's entire output is an image, the absence of any hint about what form that image takes (data blob vs. file reference) and what 'serial' does leaves it only minimally viable.

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 'serial' parameter, and the description never mentions it, so the agent gets no explanation that it selects which device to capture. With one undocumented optional parameter, the description fails to compensate for the coverage gap. This is above the floor only because a single optional field is a small burden.

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

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

The description names the concrete resource (a picture of the screen) and immediately scopes it against a sibling, stating it covers layout, images, and content absent from screen_elements. An agent can distinguish it from screen_elements and tap_element without opening a schema. It stops short of a 5 because 'a picture of the screen' largely restates the tool name rather than introducing a new action or scope nuance.

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

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

It gives a positive when-to-use ('for layout, images') and routes the agent away from a named alternative via 'anything not in screen_elements'. That is a clear selection rule. It lacks an explicit when-not condition or guidance on which sibling to prefer for interactive elements.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavioral semantics (direction-to-scroll mapping, distance as a fraction of screen), but says nothing about side effects, whether the gesture can trigger navigation/activation, or device/serial targeting 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 that is front-loaded with the action and then packs the direction semantics and distance units into the same breath. Every clause earns its place; nothing is redundant.

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

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

An output schema exists, so return values need not be described, and annotations cover the safety profile. The remaining gap is the unexplained serial parameter; otherwise the description is sufficient to invoke this simple gesture tool 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 coverage is 0%, so the description must carry the load. It does explain direction (all four values) and distance ('a fraction of the screen'), which is meaningful compensation, but the serial parameter — how to target a specific device — is left completely undocumented in both schema and description.

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

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

States a specific verb+resource ('scroll by swiping') and immediately resolves the ambiguity in the direction values by mapping each to its scroll effect. It is clearly distinct from the sibling set (tap, tap_element, type_text, press_key), though it does not explicitly name an alternative gesture tool.

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

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

Usage is only implied: the reader infers 'use this to scroll/gesture-navigate.' There is no explicit when-to-use, when-not-to-use, or pointer to a sibling (e.g., tap_element for clicking a target), so the agent must infer the context 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?

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered. The description adds only the pixel unit; it says nothing about where the coordinate origin is, whether out-of-range coordinates error or are clamped, or whether the tap blocks until the UI settles — all relevant because the call mutates device state.

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

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

One sentence, zero filler, and the key qualifier ('in pixels') is placed immediately after the action. Nothing is buried 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?

An output schema exists so return values need no prose, but for a 3-parameter tool with 0% schema coverage the definition is under-specified: the serial parameter, coordinate origin, and error behavior are all absent. An agent can guess the happy path but not the edge cases.

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

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

Schema description coverage is 0%, so the description must carry the burden, yet it only clarifies that x/y are pixels. The origin and axis direction are unstated, and 'serial' — the device selector on a multi-device tool — receives no explanation at all in 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 ('touch the screen at a point') and adds the coordinate unit ('in pixels'), which implicitly separates it from element-based tapping. It does not name tap_element or otherwise call out the distinction, so the agent must infer it from the sibling list.

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 and no exclusion. With a sibling literally named tap_element, the single most important routing decision for this tool — coordinate tap vs. element tap — is left entirely to inference. Nothing indicates when a raw pixel tap is preferable or required.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=false, so the mutation/safety profile is partly covered. The description adds the matching criteria (text/description/id), which is useful, but says nothing about what long_press does, failure behavior when no element matches, or the multi-device serial parameter.

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 waste. It is efficient, though terse enough that it could have afforded a clause about the other parameters.

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

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

An output schema exists, so return values needn't be explained. However, for a mutation tool with two undocumented optional parameters (serial, long_press), the description omits device-targeting and long-press side effects that an agent needs to call it 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 coverage is 0%, so the description must carry the load. It explains the required 'query' parameter well (matches text, description, or id) but leaves 'serial' and 'long_press' entirely undocumented, so it only partially compensates for the coverage 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 verb ('Touch') and resource (the element matching by text, description, or id), which distinguishes it from coordinate-based 'tap' and from 'screen_elements'. It does not explicitly name the sibling it differs from, 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?

There is no when-to-use or when-not-to-use guidance. An agent gets no help choosing between tap_element, tap, or screen_elements, and no prerequisite context is 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?

Annotations already declare the safety profile (non-readonly, non-destructive, closed-world). The description adds a valuable behavioral constraint about ASCII-only input, but does not explain the effects of the serial or submit parameters, nor what happens if no field is focused despite the tap-first warning.

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 written sentences with the primary action and prerequisite front-loaded, followed by the critical ASCII limitation. No wasted words.

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

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

The tool is simple and an output schema exists, so return values need not be described. However, for a three-parameter tool with zero schema description coverage, the description is incomplete because serial and submit are never explained.

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

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

Schema description coverage is 0%, so the description must compensate. It only implicitly covers the text parameter via the ASCII constraint and does not explain the serial (device selection) or submit parameters at all, leaving two of three parameters undocumented.

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

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

States a clear verb and target: 'Type into the focused field.' The parenthetical '(tap it first)' distinguishes this from tapping siblings, but no sibling tool is named explicitly. Clear but lacks explicit sibling differentiation.

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

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

Provides the key prerequisite ('tap it first') and a critical constraint (ASCII only) that explains when the tool will silently fail. No explicit when-not guidance or named alternative tool is given, so it stops short of the highest bar.

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