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

With no annotations, the description carries the full burden; it does signal destructiveness through concrete verbs ("clear the data of," "uninstall"), which is meaningful. However, it never states that these operations are irreversible or destroy user data, nor does it note that non-list actions require a valid package name.

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

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

A single front-loaded sentence that enumerates the action-to-effect mapping with zero filler; the parenthetical action token is the only structural aid needed.

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 that mixes a safe read with three destructive operations and has no annotations or output schema, the description should disclose irreversibility and per-action parameter requirements. It covers the action vocabulary well but leaves those behavioral gaps for an agent to guess.

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 only 33% (only serial is documented), so the description must compensate, and it partly does: it explains the meaning of each action enum value and says the targeted app is identified "by package name." It stops short of stating that package is required for stop/clear/uninstall but ignored for list, and gives no package format example.

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

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

The description uses specific verbs (list, force-stop, clear data, uninstall) against a named resource (installed apps), and it explicitly binds the "list" action to its enum value. It does not distinguish itself from siblings like phone_install or phone_stop, but the verb/resource pair 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?

Mapping each action word to its effect gives implied guidance about which action to pick, but there is no explicit statement of when to use this tool versus phone_install or phone_shell, and no prerequisites (e.g., that destructive actions need the app currently installed).

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?

Beyond readOnlyHint=true, the description discloses real behavioral traits: it blocks/polls for up to 5 seconds, and passing checks get promoted to assertions while recording. That is non-obvious context an agent would not infer from the schema. It does not say what happens on timeout/failure (exception vs. returned false), which is the one meaningful gap.

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

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

Three short sentences, front-loaded with the core assertion, then the 5-second wait bound, then the recording caveat. No restatement of the title ("Check the screen") and no filler.

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

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

For a zero-required-parameter, no-output-schema read tool with a readOnlyHint already declared, this covers purpose, timing tolerance, and test-recording effects. The remaining ambiguity — failure semantics and whether text and id can be supplied together — is minor but real.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine semantics the schema lacks: it explains what visible=false means (assert absence rather than presence), which the schema only marks as "Default true." It also frames id and text as interchangeable targets. The checked and serial parameters are left entirely to the 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?

Specific verb-plus-resource: "Check that text (or an element id) is on screen, or with visible false that it is not." An agent immediately knows this is a screen-state assertion rather than a UI action like phone_tap or phone_type. It stops short of naming the nearest sibling (phone_look) or stating any exclusion, so 4 rather than 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 implied by the phrasing: use it to verify on-screen state, and pass visible=false to verify absence. The recording-mode sentence hints at when this is especially valuable (during test recording), but no explicit when-to-use, when-not-to-use, or alternative (e.g. phone_look vs phone_assert) is offered.

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 disclose two meaningful behaviors: it updates an existing install rather than failing, and it grants the APK's permissions automatically — a security-relevant side effect not visible in the schema. It omits failure modes, whether the device must be unlocked/connected, and whether the install is reversible.

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 the side effect, then the optional launch behavior. Nothing is wasted.

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

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

For a mutating tool with no annotations and no output schema, the description covers what the tool does and the permission side effect but leaves out what happens on failure, multi-device behavior beyond the schema hint, and whether any confirmation or cleanup is needed.

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

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

Schema description coverage is 100%, so all three parameters are already documented, and the description's note about `open` largely restates the schema's 'Package name to open after installing'. It adds no detail on `apk` path expectations or how `serial` selects among 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?

States a specific verb and resource (install/update an APK from this computer) and notes the post-install launch option, which lightly separates it from phone_open. It doesn't name siblings explicitly, so an agent must still infer the boundary with phone_open and phone_app.

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 install/update framing and the note to pass `open` to launch afterwards, but there is no explicit when-to-use versus when-not guidance or statement that phone_open should be used for already-installed apps.

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

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

With no annotations, the description carries the full burden. It contributes real behavioral information by defining the accepted key vocabulary, including the escape hatch of arbitrary Android KEYCODE_* names, but says nothing about required device state (connected/unlocked), what happens on an invalid key, or whether anything is returned.

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, front-loaded with the verb and resource, then the value domain. Every token earns its place and there is no restatement of the title or name.

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 input-injection tool with no annotations and no output schema, the description covers the essential unknown — the valid key set. It stops short of device-state and error behavior, but nothing structurally required is missing.

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

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

Schema coverage is only 50% and the undocumented parameter is the required one ('key'), so the description's enumeration of valid values — which the schema lacks entirely, since there are zero enums — is exactly the compensation needed. 'serial' is already documented in the schema and the description correctly leaves it alone.

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') plus the resource class ('hardware or navigation key') and then enumerates the exact accepted values, so an agent can immediately distinguish it from phone_type (text entry) or phone_tap (coordinate touch) without opening any schema.

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

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

The list of key names implicitly tells the agent when this tool applies, but there is no explicit when/when-not guidance and no mention of the alternatives (phone_type, phone_tap, phone_shell) or prerequisites such as an active device connection. Usage is inferable rather than stated.

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

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

readOnlyHint=true already tells the agent this is a safe read with no side effects, so the description's remaining job is small. It does add useful context by saying the result covers both connected devices and available device profiles, but nothing about format, emptiness handling, or whether profiles are per-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?

One short sentence with no filler, and the resource is stated up front. It is slightly compressed — 'available device profiles' never gets clarified — but nothing is wasted.

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

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

For a zero-parameter, read-only list call this is close to complete, and no output schema exists to defer to. However, the description does not say what a 'device profile' is or how the two result sets relate, which is the main thing an agent would need before calling.

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 zero parameters, so the baseline of 4 applies; there is no parameter semantics for the description 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?

The description names a specific verb ('Show') and the resources it covers: connected devices and available device profiles, which matches the 'phone_list' name. It is clearly a read/list operation against the sibling tools, which are all actions (tap, install, start), but it never explicitly contrasts itself with any of 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?

Usage is only implied — an agent can guess you call this to discover devices/profiles before acting, but the description states no when-to-use condition and names no alternative. For a zero-parameter discovery tool the inference is easy, which keeps this above a 2.

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 usefully discloses the destructive side effect that 'clear empties the log first', which is the most important trait to surface, but it omits return-format behavior, default line count, and multi-device handling.

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

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

Three short sentences, zero padding, with the core purpose front-loaded and the destructive caveat last. Every sentence adds information.

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

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

For a 6-parameter read tool with no output schema, this covers the essential surface: what is read, how it can be filtered, and the one destructive flag. Only the return shape and device-selection nuance remain unaddressed, and 'serial' is already documented in the 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?

Schema coverage is 67%, and the description fills the main gaps by explaining that 'package' scopes to one app, 'level' is a minimum threshold, 'crashes' restricts to the crash buffer, and 'clear' wipes the log first — the two undocumented params (package, clear) are both covered. It stops short of syntax or format details.

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?

Opens with a specific verb+resource ('Read logcat'), which immediately separates it from the phone_* action/test/shell siblings. It doesn't explicitly name an alternative log tool, but the resource 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 filtering options imply when to use each mode (package filter, level threshold, crashes-only), so a caller can infer usage. However, there's no explicit guidance on when to prefer this over phone_shell or phone_app, nor on prerequisites like an attached 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?

readOnlyHint=true already declares the safety profile, and the description adds genuinely new information: the return content is a numbered element list plus a screenshot, with the conditional that screenshot=false suppresses it. No output schema exists, so this disclosure of return shape is doing real work.

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, front-loaded with the core action, with zero filler. Every clause carries information: the read verb, the two return components, and the one condition that changes output.

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-required-parameter read-only inspection tool with full schema coverage and no output schema, this covers what to call and roughly what comes back. It could go further by explaining that the numbered element list is what other tools (e.g. phone_tap) address by index, which is the key downstream use.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema. The description echoes the screenshot toggle's conditional behavior but adds no syntax or format detail beyond it, and says nothing about the serial parameter. Baseline 3 applies.

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

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

States a specific verb and resource ('Read the current screen') and specifies exactly what comes back: the numbered element list plus a screenshot. It's clearly distinct from siblings like phone_tap or phone_shell by being an observation tool, 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?

Usage is only implied: as a 'read the screen' tool an agent can infer it's the inspection step before acting. There is no explicit when-to-use statement, no mention of calling it before phone_tap/phone_type, and no alternatives discussed.

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

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

No annotations are provided, so the description carries the full disclosure burden. It does not say what happens when the package is not installed, whether the call blocks until the app is in the foreground, whether it returns a success/failure signal, or how unresolvable deep links are handled.

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

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

A single sentence with no wasted words, with the primary parameter's accepted formats front-loaded and illustrated by examples.

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-annotation, no-output-schema tool, the description explains the input well but leaves out failure behavior, return semantics, and device targeting implications when `serial` is supplied. Adequate to invoke, but incomplete for handling outcomes.

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 only 50%: the `target` parameter has no schema description, and the description compensates well by enumerating its accepted forms (package name with example, URL, deep-link scheme, literal "settings"). The `serial` parameter's meaning is already covered in the 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 verb and resource (open an installed app / URL / deep link) and gives concrete examples. It does not name any sibling tool, but the scope is narrow enough to distinguish it from phone_install or phone_shell by intent.

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: 'Open an installed app' suggests it is for launching, not installing or shelling. There is no explicit when-to-use vs. phone_shell or phone_start, and no stated preconditions such as the app already being installed.

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 never states how far the scroll moves, whether the scroll animates/settles, whether it fails or no-ops at the end of content, or what the tool returns. Only the direction semantics ("down" shows what is below) 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 short sentences, front-loaded with the action and its purpose, with the optional-element case trailing. No filler.

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

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

For a 3-parameter interaction tool with no annotations and no output schema, the description omits the scroll distance, whether the screen state is returned or must be inspected via phone_look, and failure behavior at the end of content — all things an agent needs to drive this reliably.

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

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

At 67% schema coverage, the schema documents ref ("scrollable element ... Default: the whole screen") and serial. The description only adds meaning for direction by glossing "down" as showing what is below; it says nothing about ref or serial beyond the 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?

"Scroll to reveal more content in a direction" is a specific verb+resource with the effect of the action stated. It does not, however, distinguish itself from the sibling phone_swipe (also a directional gesture) — the only edge is that scroll is content-revealing and swipe is generic, and that is left implicit.

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

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

"Scroll to reveal more content" implies usage, and "Optionally inside a scrollable element" hints at when to pass ref. But there is no explicit when-to-use vs phone_swipe, no note on pairing with phone_look to verify what appeared, and no exclusions.

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

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

With no annotations, the description carries the entire behavioral burden, and it discloses almost nothing: no indication that this is arbitrary, potentially destructive code execution, no mention of required device permissions/root, no timeout, no statement about what is returned (stdout/stderr/exit code). For the most powerful tool in the set, this is a substantial 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?

Two short sentences, front-loaded with the core action and followed by the routing hint. No wasted words, though the second sentence is slightly vague where it could be sharper.

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?

No output schema and no annotations, so the description must explain return behavior and safety on its own — and it does neither. An agent cannot tell whether output is captured, whether the call blocks, or what side effects are possible before invoking arbitrary shell commands.

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 50%: `serial` is documented in the schema, while `command` has no description. The phrase "a command in the device shell (adb shell)" partially compensates by implying the string is passed to adb shell, but it adds no detail on quoting, shell interpretation, or multi-command usage.

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 command in the device shell — and names the underlying mechanism (adb shell), so the agent knows exactly what capability this exposes. It does not name a specific sibling it overlaps with, but the catch-all framing makes its role in the 18-tool family clear.

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?

"For anything the other tools do not cover" gives a concrete selection rule: treat this as the fallback when no dedicated phone_* tool fits. It stops short of naming which alternatives exist or stating exclusions/limits on what may be run, so it is context rather than a full routing spec.

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 load, and it does disclose two useful traits: it installs missing dependencies and it is idempotent/reuses an existing phone. It does not mention that boot can be slow, what state the phone is left in after boot, whether only one phone can run at a time, or how failures surface.

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

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

Two tight sentences: the core action and its install behavior come first, then the sizing options, then the reuse note. Every clause carries information an agent needs to choose 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?

For a 7-parameter, annotation-free mutation tool with no output schema, the description covers what to pass and what side effects to expect. The remaining gap is the return value — the agent doesn't know whether it gets a device id or handle back, nor how long boot takes.

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

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

Schema coverage is 100%, so the baseline is 3, and the description exceeds it by listing the actual allowed values for `device` (pixel-8, pixel-8-pro, small-phone, compact, tablet), which the schema does not enumerate. It adds nothing for `wipe`, `headless`, or `android`, but those are already documented in the 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 concrete verb and resource ('Boot an Android phone') plus a distinguishing detail that it installs anything missing first, which separates it from phone_stop and phone_install in the sibling list. It also enumerates the supported device profiles, so an agent knows the valid domain 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?

Explains the two selection paths — pick a named profile or pass width/height/density — and notes that an already-running phone is reused, so the agent needn't call phone_list first. It stops short of explicit when-not guidance or naming an alternative (e.g., when to prefer a separate install/boot flow).

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 provides almost nothing beyond the basic mutation. It does not say whether shutdown is graceful or forced, whether unsaved emulator state is destroyed, whether the call blocks until the device is off, or whether it affects one or all devices.

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. It is efficient, though its brevity reflects under-specification rather than tight editing of a richer explanation.

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 lifecycle tool with no annotations and no output schema, the description omits essentials: what state is lost, whether the operation is reversible, and what the agent should expect afterward. The simple one-parameter schema keeps the bar low, but the behavioral gap is still material.

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

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

Schema coverage is 100%, so the single optional `serial` parameter is already fully documented in the schema, including the 'only needed when several are connected' nuance. The description adds nothing about it, which is acceptable given the schema does the work, but earns no credit above baseline.

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 object ("shut down a running emulator"), which is unambiguous and distinct from the sibling phone_start. It stops short of explicitly naming the counterpart tool, but the resource is concrete enough that an agent can tell what it does without reading 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?

"Running emulator" implies a precondition, but the description never states when to call this versus alternatives, whether it should be paired with phone_start, or what to do if nothing is running. There is no routing guidance relative to the 17 sibling 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 must carry the behavioral burden. It discloses that this injects a finger-drag gesture and that coordinates are screenshot pixels, but it does not state that the gesture can alter UI state, what happens on failure, 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 sentences, front-loaded with the action and coordinate frame, followed by the usage condition. There is no redundant restatement of the tool name or title.

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

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

For a six-parameter device-input tool with no annotations and no output schema, the description is somewhat under-specified. It covers the core action and coordinate unit, but not the precise parameter roles, device selection, gesture duration, or post-gesture 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?

Schema description coverage is only 33%, so the description should compensate. It clarifies that the four required numbers are start/end points in screenshot pixels, but it does not map x1/y1 vs x2/y2 explicitly or mention duration_ms and serial, which the schema partially covers.

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 (drag a finger from one point to another) and fixes the coordinate system as screenshot pixels. It also distinguishes itself from phone_scroll by saying it is for gestures scrolling does not cover.

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 explicitly names scrolling as the alternative and gives the condition that selects this tool over scrolling. However, it does not mention other sibling alternatives such as phone_tap for simple taps, so the guidance is clear but not exhaustive.

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 discloses coordinate units (screenshot pixels) and long-press behavior, but omits side effects, failure behavior when targets are missing, and whether it waits for UI changes.

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 tightly written sentence with the primary action and modifiers front-loaded. Every clause adds targeting or long-press information.

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

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

For a 6-parameter UI action with no annotations and no output schema, the description covers targeting well but is thin on operational behavior and validation. It does not say that one targeting mode is required, how conflicts are resolved, or what happens on failure.

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 67%, with x/y undocumented in the schema; the description compensates by defining x/y as screenshot pixels and framing target selection as ref/text versus point. It still leaves precedence between ref and x/y, and the required pairing of x/y, unstated, while serial is only covered by the 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 names a specific verb (Tap) and the exact target types: an element by ref or visible text, or a point by x/y. This clearly distinguishes it from siblings such as phone_swipe, phone_scroll, phone_type, and phone_key.

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 explains the three targeting modes and the optional long-press flag, which is useful invocation guidance. However, it gives no explicit when-to-use guidance, no alternatives, and no prerequisite such as needing a prior phone_look to obtain refs.

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 at all, the description carries the full burden, and it does disclose two useful traits: replay is deterministic/step-by-step and no AI is involved, plus the outcome is a pass/fail report. It omits whether the call blocks for the whole flow duration, typical runtime, what happens on failure (partial state left behind), and any permission or device 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?

Two short sentences, zero filler, with the core action front-loaded before the clarifying note about AI. Every sentence earns its place.

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

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

For a 2-parameter tool with full schema coverage and no output schema, the description covers the return value (pass/fail) but is thin on execution semantics and overhead. Most notably it never positions this tool against the closely named phone_test_start sibling, which is the main ambiguity an agent would face.

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

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

Schema coverage is 100%, so both path and serial are already documented in the schema; the description adds no extra semantics beyond confirming that a YAML flow file is what's replayed. Baseline 3 applies since the schema does the heavy lifting.

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

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

States a concrete verb and resource: replay a Maestro-format YAML flow on the phone, with step-by-step execution and pass/fail reporting. It does not distinguish itself from the sibling phone_test_start or phone_test_save, leaving the agent to guess which test entry point to pick.

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

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

Usage is implied by 'Replay a Maestro-format YAML flow,' but there is no explicit when-to-use vs. phone_test_start, no prerequisites (device connected, app installed, flow already saved), and no guidance on when not to use it. 'No AI is involved' hints at a contrast with a smarter alternative without naming 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 provided, so the description bears the full burden. It discloses the file format and that recording continues after saving, but says nothing about whether an existing file at the target path is overwritten, what the tool returns, or whether a save can fail partway — all material for a write operation with zero annotation coverage.

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, zero waste, with the core action front-loaded and the non-obvious side effect (recording continues) immediately after.

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?

A simple 3-parameter tool with no output schema and no annotations. The description covers the action and the format but leaves the write semantics (overwrite behavior, return value) unstated, which is a real gap for a file-writing tool.

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

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

Schema description coverage is 100%, and each parameter already has a clear description including the default path and the multi-device case for serial. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb + resource + output format: "Write the recording as a Maestro-format YAML flow." That distinguishes it from phone_test_start (begin recording) and phone_test_run (execute), 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?

"Recording continues, so you can save again later" implies this is a mid-recording snapshot you may repeat, which is useful usage context. But there is no explicit guidance on when to save vs. when to run (phone_test_run) or start a new recording, so the agent must infer from siblings.

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

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

No annotations exist, so the description carries the full burden; it does disclose the important side effect that the app will be restarted, plus the default app targeting. It omits how the recording is terminated or persisted, what handle/identifier comes back, and what happens to an already-running recording.

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 action and followed by the default-targeting caveat; every clause earns its place. Sized appropriately for a low-parameter tool.

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

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

For a stateful recording tool with no annotations and no output schema, the description establishes the start of a workflow but not its shape—no mention of stopping/saving, of what is captured, or of what the caller receives. Adequate but leaves real workflow gaps.

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

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

Schema coverage is 100%, so all three parameters are already documented. The description adds one genuinely new fact—that the app parameter defaults to whatever is currently on screen—but says nothing about serial or clear_state behavior beyond the schema text.

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 compound action: restart the app and begin capturing subsequent actions as a repeatable test. This is clearly distinct from phone_test_save and phone_test_run by wording, and 'record everything you do from here' separates it from a plain phone_start. It stops short of naming 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?

Usage is implied by 'record everything you do from here as a repeatable test' and the note about defaulting to the on-screen app, so an agent can infer this is the entry point of a test-authoring workflow. However, no alternative is named, no prerequisite state is stated, and the implied follow-up (saving with a sibling) is never 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?

With no annotations, the description carries the full burden; it does disclose the ASCII-only limitation and that newlines press Enter, which are real behavioral traits. It omits failure modes, whether the app must be foregrounded, timing/retry behavior, and whether typed text replaces or appends by default.

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

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

Two tight sentences, front-loaded with the primary action, then the targeting variant, then behavioral caveats. 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?

For a 6-parameter input tool with no annotations and no output schema, the description covers action, targeting, and the two most surprising constraints (ASCII-only, newline=Enter). A brief note on what happens when no field is focused or on failure would close the remaining 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 coverage is 100%, so baseline is 3, but the description adds genuine semantics: ref vs field as alternative targeting mechanisms, and that embedded newlines in text act as Enter presses. clear, submit and serial are left to the schema, which documents them adequately.

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

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

States a specific verb (type) and target (focused field) plus the optional pre-step of tapping a field by ref or visible text. This implicitly separates it from phone_tap and phone_key, though it never names a sibling 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?

Explains both invocation modes: type into whatever is already focused, or target a field via ref (index) or field (visible text/hint). No explicit when-not guidance or named alternatives, but the context needed to choose a path is present.

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