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

With no annotations, the description carries the full burden and only discloses that output is returned. It says nothing about the fact that arbitrary shell commands can mutate device state, whether the device must be connected/unlocked, whether there is a timeout, or how failures are surfaced — all critical for a raw escape-hatch 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 with no filler, which is appropriate for a one-parameter tool. The parenthetical '(advanced)' is the only soft spot — it's a vague qualifier that would be better spent on a concrete usage condition.

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 raw, unannotated, potentially destructive shell tool with an undocumented parameter and no output schema, the definition is far too thin. An agent can call it, but cannot predict safety, device preconditions, output format, or failure behavior — all of which this tool needs since nothing structured fills the gap.

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

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

Schema description coverage is 0% for the single required 'command' parameter, and the description adds no meaning: it doesn't clarify whether the string is the full shell line including arguments, how quoting/escaping works, or whether multi-command sequences are allowed. The one sentence 'Run a raw adb shell command' essentially restates the parameter name.

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

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

States a specific verb and resource ('Run a raw `adb shell` command on the phone') and signals the return ('return its output'), which clearly separates it from the high-level primitive siblings like tap, swipe, and type_text. It stops short of 5 because 'raw' and '(advanced)' are not elaborated on, so the actual scope of what can be run stays 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?

The parenthetical '(advanced)' is the only hint that this is a fallback, and the description never says when to prefer adb_shell over the dedicated tap/type_text/open_app siblings or when to avoid it. There are no prerequisites, no device-state requirements, and no exclusions, leaving the agent to infer routing 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?

No annotations are provided, so the description carries the full behavioral burden. It states the connection method and prerequisite, but omits success/failure behavior, whether the connection persists, ADB pairing/auth requirements, timeouts, and return value.

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 a useful parenthetical prerequisite. There is no unnecessary wording 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 simple one-parameter connection tool, the description covers purpose, address format, and the key prerequisite. It still lacks failure/return behavior and the relationship to device selection, which matters given no annotations or output schema.

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 schema has 0% description coverage and only an 'Address' title. The description compensates by giving an example address format (IP:port) and the phone prerequisite, though it does not explain hostnames, IPv6, or default ports.

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

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

States a specific action and target: connect to a phone over Wi-Fi ADB. It does not explicitly distinguish itself from siblings such as select_device or list_devices, so differentiation is only 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?

Gives the prerequisite that wireless debugging must be on and provides an example address. However, it does not explicitly say when to use this versus select_device/list_devices or when not to use it.

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

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

No annotations are supplied, so the description carries the burden alone. 'Return' implies a safe, side-effect-free read, and it discloses the scope of the answer, but it says nothing about edge cases such as no foreground app, a launcher/home screen, or whether a device must be connected.

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

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

A single front-loaded sentence with no filler, and it states the return scope immediately. Nothing could be removed without losing meaning.

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 zero-parameter read, but there is no output schema, so the description should say what the return looks like (a package name string, or a package/activity pair) rather than leaving 'package/activity' ambiguous. Adequate, but a real gap for an agent that must parse the result.

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 argument semantics to explain; the baseline of 4 applies. The description correctly refrains from inventing 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?

The description gives a specific verb (Return) and a precise resource (the package/activity currently in the foreground), so an agent knows exactly what query is being answered. It does not explicitly distinguish itself from siblings like list_apps or open_app, which would have raised it to 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?

Usage is only implied: an agent can infer this is the way to check what is on screen right now, but the description never says when to prefer it over list_apps or get_ui_elements, nor states any prerequisite such as an active device connection.

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. It usefully discloses that the result is a numbered text list with no image and that the call is cheaper, but it does not cover prerequisites such as device connection state, whether element numbers are stable, or how they map to tap_element.

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 deliver the purpose, return format, and cost comparison with no wasted wording. The key distinction from screenshot is front-loaded.

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

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

For a simple zero-parameter inspection tool, the description is mostly complete: it explains what is returned and why it is cheaper than a screenshot. It could add how the numbered elements relate to tap_element, but the core invocation context is sufficient.

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 and no parameter semantics are needed in the description. The schema and description are consistent.

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 and resource: "Get the numbered list of on-screen elements." It further specifies the element types (text, buttons, inputs) and distinguishes the tool from the sibling screenshot tool by saying it returns no image and is cheaper.

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 than screenshot" clearly signals when this tool is preferable to taking a screenshot. However, it does not explicitly mention alternatives such as tap_element or state exclusions, so it falls short of full when/when-not guidance.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the return content (package names) but says nothing about whether a device connection is required, whether results cover all installed vs only launchable apps beyond the name, or whether output is ordered or truncated. For a no-annotation tool this leaves meaningful gaps.

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

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

Two short, front-loaded sentences with no wasted wording. The brevity is efficient, though it borders on under-specification given the zero annotation coverage.

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 single-optional-parameter read tool with no output schema, so the bar is modest and the description covers purpose and return type. It still omits device/auth preconditions and the exact filter target, which an agent needs to invoke it confidently.

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

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

Schema description coverage is 0%, so the description must compensate. It does add real meaning by declaring the parameter optional and that it performs a substring match, but it never says which field the substring matches (package name vs display label) or whether matching is case-sensitive.

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 launchable apps') and even discloses the return value shape ('package names'), which distinguishes it from siblings like open_app or list_devices. It does not explicitly name a sibling, so it falls just short of a 5.

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

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

Usage is only implied: an agent can infer this is the discovery step before open_app, but the description never says when to call it, when not to, or which sibling to prefer. No prerequisites (connected device, ADB availability) are mentioned.

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

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

No annotations are supplied, so the description carries the full burden. It usefully discloses that the result includes transport type and which device is currently selected, but says nothing about behavior when no devices are connected, ordering, or whether devices must be authorized/enabled for ADB.

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 still conveys resource, transports, and returned selection state.

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-argument read tool with no output schema, the description covers what is enumerated and the key piece of returned state (the selected device). Only the response shape and empty-result behavior are left unstated, which is minor at this complexity.

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 no parameter meaning the description needs to compensate for.

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 resource ('Android devices'), plus the connection transports (USB or Wi-Fi) and that selection state is included. An agent can distinguish it from select_device, which changes the selection rather than reporting it.

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 description suggests this is a discovery call before acting on a device, but it never says when to call it versus select_device or connect_wifi, nor whether it must precede other device tools.

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 does usefully disclose the beep/vibration cues, waiting for speech, and stopping after a pause. It still omits other behavioral details such as what happens on silence, permission requirements, and how max_seconds bounds the interaction.

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 front-loaded with the core purpose and then provides parameter-specific notes in reasonably compact form. The default environment variable notes are useful rather than redundant, though the formatting is slightly inconsistent.

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

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

For a tool with no annotations, no output schema, and 0% schema description coverage, the description covers enough to understand the main recording flow. It is still incomplete regarding max_seconds, silence/error behavior, and any permission or device-specific constraints.

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 supply parameter meaning. It explains mic choices, language format and the wait_for_speech behavior, but leaves max_seconds entirely unexplained even though it is a schema 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?

The description states a specific verb and result: listen to the user's voice and return spoken content as text. It is clear what the tool does, but it does not explicitly distinguish itself from sibling voice tools such as voice_command or voice_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?

The purpose implies when to use it: capturing speech as text rather than executing a voice command. However, it gives no explicit when-not guidance or direct comparison to alternatives like voice_command or speak.

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?

There are no annotations, so the description carries the full behavioral burden. 'Show' implies a read-only listing, and the description usefully states that it reports the microphone used by `listen`, but it does not describe output format, permissions, or whether any state changes 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 compact sentence with no wasted wording. The main purpose is front-loaded 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?

For a zero-parameter, read-only listing tool, the description is nearly sufficient: it says what is listed and highlights the `listen`-related selection. It could be slightly stronger by clarifying whether all microphones are returned or only available/selectable ones.

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

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

The tool has zero parameters, so there is no parameter semantics to explain. The baseline for a parameterless tool is 4, and no contradictory or confusing parameter information is present.

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: showing PC microphones. It also clarifies a scope detail by saying which microphone `listen` uses, which helps distinguish it from the speaker-related sibling.

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 mention of `listen`, suggesting this is useful before choosing or checking the active microphone. However, it does not explicitly say when to use this versus list_devices or how to act on the result.

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; "Show" implies a safe read but this is never stated outright. It does add useful behavioral context by naming the TTS_OUTPUT configuration knob, but it says nothing about failure modes (e.g. no audio device present) or the shape of the returned speaker list.

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 main purpose front-loaded and the remedial hint tucked into a parenthetical. No filler, no repetition of the tool name, 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 zero-parameter read tool with no output schema, the description covers what is listed, which entry is the active one, and how to change it. The only gap is the return format, which is implied rather than stated and is minor at this complexity.

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 and there is no parameter meaning to compensate for. The TTS_OUTPUT mention describes external configuration rather than an argument, which is still helpful orientation.

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 ("Show the PC speakers") and adds scope, namely that it also reports which speaker voice output plays through. It is distinguishable from list_microphones and list_devices by the audio-output framing, though it never names those siblings 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 parenthetical "set TTS_OUTPUT to change" tells the agent what to do when the desired speaker is not active, which is genuine routing guidance. It gives no explicit when-to-use vs list_devices or list_microphones and no conditions under which calling it is unnecessary.

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

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

No annotations are supplied, so the description carries the full burden. It does not say whether the call blocks until the gesture completes, what it returns, whether it requires an active device connection, or how the press duration behaves by default — the `ms` control is never acknowledged.

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 zero filler, and the gesture and its two targeting modes are front-loaded. Nothing is redundant or padded.

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

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

With no annotations, no output schema, and 0% schema coverage across four parameters, the description is too thin for an interaction tool. The duration parameter, return behavior, and prerequisites all go unexplained.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully defines `index` as an element number and pins x/y to screenshot pixels, which is real added meaning, but it is silent on `ms`, the parameter that actually defines a long press.

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 (long-press) and two concrete targeting modes (element `index` or x/y point), which lets an agent separate it from the tap/tap_element siblings by gesture type. It stops short of naming those siblings explicitly, so differentiation is implied rather than stated.

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

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

The word 'or' hints at the two targeting modes but there is no guidance on when a long press is appropriate versus tap/tap_element, nor when to prefer `index` over coordinates. No preconditions (connected device, UI elements already fetched) are mentioned.

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

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

No annotations are supplied, so the description carries the full behavioral burden, yet it says nothing beyond input format. It does not state what happens if the app is not installed, whether the call waits for the app to foreground, or what it returns; for a launch action with zero annotation coverage that is a real 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 sentence that front-loads the action and packs the format guidance into one parenthetical. Nothing is wasted and nothing needs to be moved.

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 this is close to sufficient on inputs, but with no annotations and no output schema the description should still say what a call returns or how failure looks (app missing, device not ready). The input side is complete; the outcome side is absent.

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

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

Schema description coverage is 0% and the single `name` parameter is a bare string, so the description does the work by explaining that it accepts either a display name or a package identifier. The parenthetical examples ("whatsapp", "camera", "com.whatsapp") give the agent an unambiguous format to imitate; only edge cases like partial matches are unaddressed.

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 ("Open an app") and immediately disambiguates the input form with concrete examples of both a friendly name and a package name. It does not name sibling tools such as list_apps or open_url, so the reader must infer the boundary, which keeps it 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?

Usage is only implied: an agent can infer it should call this when it wants an app launched rather than a URL or a raw shell command. There is no explicit when-to-use versus open_url or list_apps, and no prerequisite such as a selected/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?

No annotations are provided, so the description carries the full behavioral burden and does not meet it. It never says whether tel: actually initiates a call, whether geo: hands off to a maps app, whether the device must be unlocked or already selected via select_device, or what the call returns on failure. The scheme examples hint at side effects but do not disclose them.

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 verb and resource, with the scheme examples parenthesized rather than sprawling. 'On the phone' is not filler here since the sibling set includes list_devices/select_device, so it clarifies the target device.

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 is nearly adequate, but with no annotations and no schema descriptions at all, it should still say whether the target device must be selected first and roughly what a successful versus failed invocation does. Those omissions matter in a device-control 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 coverage is 0% — the single 'url' parameter is a bare string with no description. The description partially compensates by listing accepted schemes (https://, tel:, geo:, whatsapp://), which is real meaning beyond the schema, but it gives no format rules, encoding guidance, or failure behavior for malformed input.

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 ('open') and resource ('a URL or deep link') and enumerates example schemes (https, tel, geo, whatsapp), which makes it clearly distinct from the app-launching sibling open_app. It stops short of naming that sibling explicitly, but the scheme examples do most of the disambiguating 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 only implied: the scheme examples suggest when this is appropriate (web links, phone numbers, map coordinates, app deep links) as opposed to open_app for launching packages. There is no explicit statement of when not to use it, no prerequisite such as device selection or unlocked screen, and no alternative named.

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

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

With no annotations, the description must carry the behavioral burden. It discloses the supported key values and KEYCODE_* flexibility, but it does not state device-targeting expectations, whether a device must be selected or unlocked, or what the tool returns or blocks on.

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 a compact, necessary enumeration of supported values. There is no filler or redundant wording.

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 output schema, the description gives enough to invoke it correctly by specifying valid keys. It could be more complete by mentioning the current selected device or any required device state, but the core invocation details are present.

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

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

Schema description coverage is 0%, so the description must define the single parameter. It does so well by listing concrete accepted key names and allowing any KEYCODE_* name, which adds substantial meaning beyond the bare string 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?

The description states a specific verb and resource, 'Press a key,' and enumerates the supported key names. It is clear what the tool does, but it does not explicitly distinguish itself from siblings such as type_text, tap, or adb_shell.

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 list of valid keys implies when the tool is appropriate, but there is no explicit guidance on when to use it instead of type_text, tap_element, or adb_shell. Alternatives and exclusions are 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?

No annotations exist, so the description carries the full burden and does disclose the key non-obvious behavior: the default mode overlays numbered boxes on the image and returns a matching numbered list, and list coordinates are in image pixel space. It omits things like image format/size, whether the screenshot requires an active device session, and latency/cost, which are meaningful 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?

Front-loaded with the core action, then the mode-dependent output, then the follow-up call to make — a clean cause-to-effect ordering with no filler. The opening clause 'so you can see what is on screen' is mildly redundant with 'screenshot', but the rest earns its space.

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

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

For a one-parameter, no-output-schema tool this covers the essentials: what is captured, what is returned in each mode, and how to act on it. The main gap is session prerequisites (device selection/connection) given the presence of list_devices and select_device 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?

Schema coverage is 0% and the single parameter has no schema description, but the description fully compensates by naming the default value and explaining exactly what True does and what the agent should do with the resulting numbering. It only leaves implicit what False returns besides a bare image.

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 ('Take a screenshot of the phone') plus the observable outcome ('see what is on screen'). It also implicitly distinguishes itself from get_ui_elements by describing the combined image + numbered-element-list output that no other sibling produces.

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

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

Explicitly routes the agent into the intended workflow: with show_elements on, 'use tap_element(number) to press one', and pass listed coordinates to tap(x, y). It does not state when to prefer this over get_ui_elements or note prerequisites such as select_device being called first, which keeps it below a 5.

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

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

No annotations are supplied, so the description carries the full behavioral burden and does little with it. It does not say whether this is a touch gesture or a wheel event, what happens at the top/bottom of a page, whether the scroll animates or waits, or what the tool returns; only the amount unit ('of the screen') is disclosed.

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, front-loaded with the action, then parameters in the order they matter. The phrasing 'down (see content below)' is slightly cryptic but no sentence 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 two-optional-parameter gesture tool with no output schema and no annotations, the description covers the parameter space adequately but leaves the behavioral contract (edge-of-page behavior, gesture vs. wheel, any resulting state) unstated. It is minimally sufficient 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 0% – the schema lists only bare types and defaults – so the description must compensate, and it does: it supplies the four valid direction values (down, up, left, right) and constrains amount to 0.1-0.9 as a fraction of the screen. It does not restate the defaults or say what the 0.5 default means in practice, keeping it just short of 5.

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

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

The description names a specific verb and resource ('Scroll the screen') and enumerates the directions, so an agent knows exactly what the tool does. It does not distinguish itself from the sibling 'swipe' tool, which is the nearest alternative for moving content, so it stops short of full 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?

The parenthetical '(see content below)' implies the typical case of scrolling down to reveal off-screen content, but there is no explicit statement of when to use scroll versus swipe, tap, or get_ui_elements. Usage is only inferable from the direction enumeration.

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

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

With no annotations, the description carries the full behavioral burden, and it discloses almost nothing about effects. It doesn't say whether the selection persists across calls or is per-session, whether it fails on an unknown serial, or whether it changes state for subsequent sibling tools like tap or screenshot.

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

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

It is a single well-formed sentence with the condition front-loaded and no wasted words. Brevity is appropriate here, though the space saved is not redirected to anything informative.

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 state-changing selection tool with no annotations, no output schema, and an entirely undocumented parameter, the description leaves too much out. An agent still lacks the serial's format and source, the persistence of the selection, and error behavior, all of which the definition alone must supply.

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% and the single parameter 'serial' has no title or description in the schema. The description does not compensate at all: it never says the argument is a device serial string, that it is required, or where to obtain a valid value (e.g. from list_devices).

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 ('Choose') and resource ('device to control'), making the tool's role legible. It only weakly differentiates from the sibling 'list_devices', which is the natural pairing, but an agent can still tell this is a selection action rather than a listing one.

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 one clear condition, 'when more than one is connected', so usage context is implied rather than fully spelled out. It never names 'list_devices' as the way to discover valid serials, and it doesn't say what to do if only one device is present or whether selection is required before other tools work.

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

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

No annotations are supplied, so the description carries the full behavioral burden. It does disclose that output is audible on the machine's speakers, but says nothing about whether the call blocks until speech finishes, what happens if no speaker is selected or the device is muted, or whether it fails silently — significant gaps for a tool with an externally observable side effect.

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

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

A single tight sentence with the action front-loaded and the use case bracketed at the end; nothing is redundant. It could be marginally improved only by folding prerequisite/behavior notes into the parenthetical.

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 utility with no output schema and no annotations, the description is adequate at the level of intent. It falls short on device prerequisites, blocking semantics, and error behavior — details an agent needs to sequence this call correctly relative to list_speakers/select_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 0% and there is one parameter, 'text', whose only meaning comes from the verb 'say'. The description implies the string is spoken verbatim but adds nothing about length limits, markup/SSML support, or formatting, leaving the single parameter only partly characterized.

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

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

The description gives a concrete verb+resource: 'Say text out loud on the PC speakers.' An agent can immediately tell this produces audio output, unlike sibling list_speakers or listen. It doesn't explicitly differentiate from voice_tap/voice_command or state whether the target speaker depends on select_device, but the core 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 parenthetical 'to report what you did or ask a question' supplies an intended-use context, which is more than nothing. However there is no when-not guidance, no mention of prerequisites such as choosing a speaker via select_device/list_speakers, and no comparison to the voice_* siblings that also involve speech.

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 disclosure burden. It contributes one genuinely useful fact — that coordinates are in screenshot pixels, giving a reference frame — but says nothing about speed/duration behavior, whether the call blocks until the gesture completes, device-connection requirements, or what happens if coordinates fall outside the screen.

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 coordinate semantics arrive immediately. The terseness is efficient, though it borders on under-specification rather than wasteful verbosity.

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 five-parameter device-control tool with no annotations, no schema descriptions, and no output schema, the definition is too thin. An agent can form the gesture but lacks the surrounding operational facts (units relative to device density, duration effect, preconditions) needed to invoke it confidently.

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

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

Schema description coverage is 0%, and the schema labels are bare ("X1", "Y1", etc.). The description clarifies that the four coordinates are screenshot-pixel points, which is real added meaning, but it never mentions duration_ms or its default of 300 or how duration affects gesture interpretation.

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 (swipe) plus the exact endpoints it interpolates between, so the action is unambiguous. It does not differentiate itself from sibling gestures such as scroll, long_press, or wake_and_unlock_swipe, which leaves the agent to infer the boundary.

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

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

There is no guidance on when to prefer this over scroll (which likely does a canned directional swipe) or wake_and_unlock_swipe, nor any precondition such as requiring a selected device or a fresh screenshot. The agent must guess from tool names alone.

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. It usefully discloses that coordinates are in screenshot image pixel space (implying they come from the screenshot tool), but it omits prerequisites such as needing a selected/connected device and says nothing about what the tap does or whether results are reported.

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

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

A single short sentence with no waste, and the key qualifier (pixel coordinate space) is front-loaded. 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 two-parameter action with no output schema and no annotations, the description covers the basics. It nonetheless leaves out device-selection prerequisites and the relationship to the screenshot tool, which an agent needs to call it correctly in this multi-tool automation suite.

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%, with x and y documented only as untyped integers. The description adds the meaningful unit (screenshot image pixels), which is exactly the missing semantics, but it does not clarify origin, range, or whether coordinates are relative to a scaled screenshot.

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

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

States a concrete verb ('Tap') plus the coordinate space it operates in ('screenshot image pixels'), which implicitly separates it from tap_element (element-based targeting). It does not explicitly name a sibling alternative, but the resource and scope are clear enough to select the tool 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?

There is no explicit when-to-use or when-not-to-use guidance, and no mention of when to prefer tap_element over raw pixel tapping. The usage is only inferred from the mention of screenshot pixels.

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 says the tool taps an element by index, but it does not disclose side effects, required permissions or accessibility state, invalid-index behavior, stale-list risks, or whether the tap is immediate.

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

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

The description is a single front-loaded sentence with no unnecessary wording. It is appropriately sized for a one-parameter action 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 simple one-parameter action tool, the description identifies the source of the index, which is the essential call context. However, with no annotations or output schema, it omits prerequisites such as fetching the latest UI elements, invalid-index handling, and outcome reporting.

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 add meaning for the index parameter. It usefully explains that index refers to an element number from the latest screenshot or get_ui_elements list, but it leaves open zero-based versus one-based indexing, valid range, ordering, and what happens if the list has changed.

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, resource, and source: it taps an element by index from the latest screenshot or get_ui_elements list. This distinguishes it from coordinate-based tap and from sibling tools like get_ui_elements or screenshot.

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

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

It implies the tool should be used after obtaining the latest screenshot or get_ui_elements list, but it does not explicitly state when to use this instead of tap, voice_tap, long_press, or other interaction tools. The usage context is inferable but not fully guided.

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 behavioral burden. It usefully discloses that a field must be focused first and that submit triggers Enter, but says nothing about whether existing text is replaced or appended, what happens if no field is focused, 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?

Two short sentences, front-loaded with the core action and its precondition, with zero filler wording.

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

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

For a two-parameter, no-output-schema tool with no annotations, the description covers the essential call mechanics: focus precondition and Enter behavior. It is slightly incomplete on failure modes and text-replacement semantics, but sufficient 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 0%, so the description must compensate for both parameters. It fully explains the optional 'submit' flag's behavior and implicitly defines 'text' as the string typed into the focused field, leaving little ambiguity.

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 target ('Type text into the focused field'), which is far more precise than the bare name. It does not explicitly contrast itself with siblings like press_key or adb_shell, which keeps it from a 5.

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

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

'tap the field first' gives a concrete precondition an agent must satisfy before calling, and 'submit=True presses Enter afterwards' describes the follow-on action. There is no explicit when-not guidance or named alternative (e.g., using adb_shell for bulk input), so it stops short of a 5.

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. 'Check' implies a read-only operation and it usefully specifies two distinct conditions (installed AND enabled), but it says nothing about required device/connection state or what happens when the check fails.

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 and the resource is identified 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?

For a simple zero-parameter check the description covers what is being verified, but with no output schema it leaves the return value unexplained (boolean vs. status string vs. error when not installed), and omits the device-connection prerequisite.

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; the baseline for 0 params applies.

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

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

States a specific verb (Check) and a specific resource (Google Voice Access installed and enabled). It is clearly distinguishable from the voice_tap/voice_command siblings, which issue commands rather than report status, though the description doesn't name that 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?

The use case is implied — verify Voice Access is available before relying on voice_tap or voice_command — but never stated. There are no explicit when-to-use, when-not-to-use, or prerequisite conditions (e.g., a device must be selected first).

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

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

With no annotations, the description carries the full behavioral burden and falls short: it does not say the target device must have Voice Access listening, that the effect is delivered as audio and may not be confirmed, or that some listed commands ('tap 5', 'stop listening', 'go home') mutate device state irreversibly. The phrase 'from the PC speakers' hints at the mechanism but no consequences or prerequisites are spelled out.

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?

Purpose is front-loaded in a single sentence, which is good, but the ten-item example list consumes most of the text and includes items like 'open WhatsApp' that overlap conceptually with sibling `open_app`, risking misrouting. A shorter representative set would earn more.

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 2-parameter tool with no annotations, no output schema, and no schema descriptions, the definition leaves key gaps: it does not say what the call returns or how to tell whether the spoken command actually took effect, and it omits the meaning of `settle_seconds`. Given the tool acts on a live device, that is not 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%, so the description must document both parameters. It gives a useful sense of what `command` should contain via examples, but never states whether the string must match a valid Voice Access phrase, and it says nothing at all about `settle_seconds` (default 1.5) or what that delay controls.

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 action (speak a Voice Access command aloud through the PC speakers) and gives a concrete list of valid command strings, so an agent can tell it is a command-injection tool rather than a plain TTS call. It does not explicitly distinguish itself from sibling `speak` or `voice_tap`, which are the most confusable neighbors.

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 example commands implicitly convey when the tool applies (issuing Voice Access actions to a listening device), but there is no explicit when-to-use or when-not-to-use statement. Nothing says to prefer `tap_element`/`scroll` over voice equivalents, or to prefer `speak` for non-command audio.

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 does useful work: it reveals that audio is emitted from PC speakers, that Voice Access performs the action, that a black toast confirms it ("Tapped connections"), and that "tap" should be avoided in favor of "click" because Voice Access can confuse it with app names. However, it never states prerequisites such as Voice Access needing to be enabled, nor what happens on failure or timeout, and settle_seconds goes entirely unexplained.

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

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

The definition is front-loaded with the core mechanism, then structured into an enumerated parameter choice list and a short post-action rule. It is dense but every sentence carries operational value; the layout is easy to scan despite the length.

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

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

For a five-parameter, side-effecting tool with no annotations and no output schema, the description covers the selection logic and a verification step well, but omits the settle_seconds parameter, any prerequisite check (voice_access_status exists as a sibling), and the return value. An agent still has open questions before a reliable call.

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 parameter burden — and it does so for four of five parameters, explaining index (from the latest screenshot), label (visible button text), va_number (grey pin numbers when "show numbers" is on), and verb (default click, with a caveat against "tap"). Only settle_seconds is left undocumented.

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

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

The description gives a concrete verb and mechanism: PC speakers announce "click <name>" and the phone's Voice Access performs the tap. This clearly separates it from the direct-tap siblings (tap, tap_element), though it never names those siblings explicitly, so the differentiation must be inferred from the "BY VOICE" framing.

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 specifies "Give ONE of" index / label / va_number and states when each is preferable — va_number "Best for icons without text and for long or ambiguous names" — plus a follow-up instruction to take a screenshot. It stops short of saying when to prefer voice_tap over tap or tap_element, which is the remaining gap.

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

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

With no annotations, the description carries the whole burden and does disclose one important behavioral fact: the wait is capped at 30 s, signalling a blocking call. It does not say what happens if seconds exceeds 30 (clamp vs. error), nor whether it returns anything or simply blocks, which matters for an agent sequencing calls.

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

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

One short sentence with the action first and the qualifying conditions immediately after; the 30 s cap is placed at the end where it reads as a constraint. No filler, nothing 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?

It is a one-parameter, side-effect-free utility with no output schema, so little is needed, and the description covers purpose, typical triggers, and the time bound. The main omission is the fixed-sleep vs. settle-detection semantics, which is the one thing an agent must know to choose between a 1 s and 10 s value.

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% and the single parameter has only a default of 1 and a title. The description's "Max 30 s" is the only added meaning, bounding the seconds value, but it leaves the core ambiguity unresolved: is seconds a fixed sleep, or an upper bound on waiting until settled? A caller cannot tell from either source.

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?

"Wait for the screen to settle" states a specific action plus the resource/condition it targets, and the parenthetical (app loading, animations) makes the intent concrete. It is clearly separable from every sibling (tap, screenshot, get_ui_elements), though it never explicitly names itself as the idle/sleep primitive among them.

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 "app loading, animations" implies the two situations that call for it, which is better than nothing. But it gives no explicit rule such as "use after open_app/tap before screenshot" and no exclusion, e.g. when polling get_ui_elements would be preferable to a blind sleep.

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 main action and the important limitation that it only works without PIN/pattern, but it does not explain failure behavior, whether it errors or no-ops when a secure lock is present, or any device-state prerequisites.

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

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

The definition is a single front-loaded sentence with no wasted wording. The action and the key precondition are both stated efficiently.

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-parameter screen-unlock tool with no output schema, the description is mostly complete. It covers the action and the main limitation, though it could say more about the result when the lock screen uses a PIN or pattern.

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 parameter semantics are not a major concern. The description does not add parameter meaning, but the baseline for a no-parameter tool is 4.

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: it turns the screen on and swipes up to dismiss the lock screen. It also distinguishes the tool from generic swipe or tap actions by naming the lock-screen dismissal outcome and the no-PIN/pattern scope.

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 a clear precondition: it works only without PIN/pattern. That is useful when-not guidance, but it does not name an alternative tool or explicitly say what to do when a PIN or pattern is configured.

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