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

There are no annotations, so the description carries the full burden of behavioral disclosure. It notes the command is arbitrary, but does not disclose that the command may be destructive, whether raw output is returned, what happens on shell errors, or whether there are timeouts. The read-only example is not enough to convey the behavioral risk of arbitrary execution.

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 that states the action, its scope, and an illustrative example. Every element earns its place with no redundancy.

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

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

For an arbitrary escape-hatch tool with no output schema or annotations, the description adequately covers purpose and selection but omits behavioral expectations such as return format and side-effect risk. This leaves an important gap for an agent deciding whether and how to invoke it.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's example illustrates the command format but adds little beyond the schema's 'Command line executed by the device shell' description, and it does not clarify serial semantics beyond what the schema already states.

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 clearly states the tool runs arbitrary adb shell commands and explicitly frames it as a fallback for anything not covered by other tools. This distinguishes it from the many specialized sibling tools without requiring the agent to inspect each 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 explicit when-to-use guidance: use for anything not covered by the other tools. This also implies when-not-to-use, since any operation with a dedicated sibling tool should not go through this escape hatch.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the destination and type of media, without mentioning whether the file is copied, whether a media scan is triggered, what happens on invalid input, or what permissions/side effects are involved.

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 clear sentence with no wasted words. It is front-loaded with the main action and resource, though it could have used additional space to include usage or behavioral guidance without becoming bloated.

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 only two parameters and full schema coverage, the description provides the core invocation context: what to add and where. However, with no annotations and no output schema, an agent is left without information about side effects, return behavior, or when to prefer this over related tools.

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

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

Schema description coverage is 100%, so the schema already documents both serial and file_path. The description adds little beyond the schema, only restating that the file is an image or video and the destination. Baseline 3 applies because the schema carries the parameter documentation.

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 ('Add') on a specific resource ('photo or video to the device's media library'). It distinguishes the tool from siblings like push_file (which places files generally) and record_video (which captures new media). The parenthetical '(Photos/Gallery)' further pins down the intended destination.

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

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

No guidance is given about when to use this tool versus alternatives such as push_file or screenshot. The only usage signal is implied by the purpose itself, with no exclusions, prerequisites, or comparison to 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 carries the burden of behavioral disclosure. It mentions the blocking wait for boot completion and the returned serial, which are useful. However, it does not disclose what happens if the AVD is already booted, potential failure modes, or side effects of wipe_data. This is adequate but not thorough.

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 sentence that front-loads the action and includes the critical wait behavior and return value. There is no unnecessary wording, making it efficient and easy to parse.

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

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

Given there is no output schema, the description appropriately notes the return serial. However, it omits details about error handling, behavior when the emulator is already booted, or prerequisites like the AVD existing. For a tool with three parameters and no output schema, this is moderately complete but leaves some 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?

The schema already covers 67% of parameters (avd and wipe_data have descriptions). The description does not add any extra meaning beyond the schema, such as clarifying timeout_seconds or explaining the interplay between parameters. Since schema coverage is high, a baseline of 3 is appropriate, and the description adds no incremental value.

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

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

The description clearly states the action (boot), the resource (Android emulator), and the key qualifier (by AVD name). It also includes the behavioral detail of waiting until boot completes and the return value (device serial), which distinguishes it from siblings like list_emulators or shutdown_emulator.

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 implies its use for booting an emulator, but it does not explicitly state when to choose this tool over alternatives, nor does it mention any exclusions or prerequisites. It could have noted that it should be used before interacting with an emulator or referenced list_emulators for finding AVD names.

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?

destructiveHint=true already flags destructiveness, and the description adds value by specifying exactly what is destroyed: all app data and permissions. It also conveys the post-condition of resembling a fresh install, which is useful behavioral context beyond the annotation. It does not mention force-stopping or irreversibility, but the annotation and 'clear all data' cover the main risk.

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 sentence that front-loads the action and scope, and the parenthetical analogy adds meaning without extra words. Every part 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 two-parameter destructive tool with no output schema, the core semantics are present and the destructive annotation covers safety. However, the description omits practical invocation guidance such as how the package is specified, that the app remains installed, and what the command returns or emits on success.

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 50% and the package property has no description. The description contributes no parameter-level detail: it does not explain what a package name should look like or that serial is optional. With low schema coverage, the description needed to compensate and did not.

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

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

The description uses a specific verb ('Clear') and a precise resource ('all data and permissions for an app'), and the 'like a fresh install' analogy clarifies that the app itself is kept, distinguishing it from the nearby uninstall_app. An agent can tell what this tool does without relying on the name alone.

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 fresh-install analogy implies the intended use case of resetting app state while keeping the app installed, but it never explicitly states when to prefer this over uninstall/reinstall or gives exclusions. The guidance is implied rather than spelled out.

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 to describe behavioral traits, and the description itself does not disclose side effects, irreversibility, or whether the operation affects all devices or only one. 'Clear' implies destruction but lacks details on scope or consequences, leaving the agent unaware of potential impacts.

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, concise sentence with no redundant or extraneous information. It directly states the action and object, achieving maximum clarity in minimal words.

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

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

For a tool that clears a device buffer, the description is too sparse. It does not explain what happens when multiple devices are connected and no serial is provided, nor does it clarify whether the operation is reversible. The schema helps with parameter details but the overall context remains incomplete for an agent to make fully informed decisions.

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 provides a clear description for the single 'serial' parameter, so schema coverage is high. The tool description itself adds no parameter detail, but the baseline of 3 applies because the schema already documents the parameter meaning 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?

The description clearly states the action (clear) and the target (logcat buffer). It is unambiguous and directly conveys the tool's purpose. No confusion with other tools is possible given the specific object.

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 provides no guidance on when to use this tool, when not to use it, or how it relates to alternatives. It does not mention any prerequisites like device selection or side effects. The agent is left with no direction beyond the bare action.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does state the core effect (exiting demo mode and restoring the real status bar), but it does not mention idempotency, whether all demo customizations are cleared, or what happens if the device is not in demo mode.

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 one short sentence with no filler. The main action is front-loaded and every word contributes to understanding what the tool does.

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 state-reset tool with one optional parameter and no output schema, the description plus the schema cover most of what an agent needs. It is slightly incomplete only in not explicitly connecting this tool to set_status_bar as its counterpart, though the sibling list supplies that 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?

The input schema already documents the only parameter, serial, with 100% coverage, including the optional-when-one-device rule. The description adds no parameter-level detail, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('exit'), names the resource ('demo mode'), and states the outcome ('restore the real status bar'). This clearly separates it from the sibling set_status_bar by signaling it is a reversal/reset action rather than a set action.

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

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

The phrase 'exit demo mode' implies the tool should be used when the device is in demo mode and the real status bar is needed. However, it does not explicitly state when not to use it or mention set_status_bar as the counterpart for entering demo mode.

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

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

Annotations declare readOnlyHint=true, so no contradiction. The description adds value by disclosing the default filtering behavior (only elements with text/desc or interactive) and the output fields (bounds, tap centers), which is useful context beyond the annotation. It doesn't mention potential performance or device requirements, but the read-only nature is covered.

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 with zero redundancy. The main purpose is front-loaded, followed by a concise note on default behavior. Every word adds information; no filler.

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

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

For a simple read-only tool with three optional parameters all documented, the description is complete enough. It specifies the output type and default filtering, which covers the agent's needs for invoking the tool correctly. The lack of an output schema is acceptable given the compact and well-described return format.

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 parameters are already well-documented. The description adds marginal value by reiterating the default filtering that relates to include_all, but it doesn't provide deeper meaning beyond the schema. The baseline of 3 is appropriate since the schema carries the semantic load.

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 ('Get'), a clear resource ('UI hierarchy of the current screen'), and the output format ('compact JSON list') with detailed content fields. This clearly distinguishes it from siblings like screenshot (which captures an image) and find_element (which searches for a specific element).

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 implies its purpose (inspect UI hierarchy) but does not explicitly mention when to use it instead of alternatives like find_element or screenshot. It does clarify default filtering behavior, which hints at usage for interesting elements vs all nodes, but lacks explicit exclusions or comparisons.

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?

The readOnlyHint annotation already indicates a safe read operation, lowering the bar. The description adds behavioral detail beyond that: case-insensitive matching and the return of bounds and tap centers, which are useful for subsequent actions. It also implies multiple results without specifying limits, which is a minor 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?

The description is a single concise sentence that front-loads the action, includes the matching criteria, and provides return value information. There is no redundancy or unnecessary detail, making it highly efficient.

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 output schema, the description supplies essential return information (bounds and tap centers). It explains the matching logic and case-insensitivity, which is sufficient for basic invocation. However, it does not mention potential limits (e.g., maximum results) or error conditions, and the absence of usage guidance is a gap partially captured in the usage_guidelines dimension.

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 only documents serial; query has no description. The tool description clarifies that query is the string to search for in text, content description, or resource ID, partially compensating for the missing schema description. However, it does not specify any format constraints for query, and serial semantics are already fully 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 clearly states a specific verb 'Find' and resource 'UI elements', and details the matching criteria (text, content description, resource ID) with case-insensitivity. This distinguishes it from siblings like wait_for_element or describe_ui, which serve different purposes.

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 provides no explicit guidance on when to use this tool versus alternatives. It does not mention typical use cases such as locating an element before tapping, nor does it exclude scenarios where wait_for_element or describe_ui would be more appropriate. The usage context is entirely implied.

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

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

The readOnlyHint annotation already indicates a safe read operation, and the description adds no additional behavioral context such as return format, potential empty results, or error conditions. It does not contradict the annotation but provides no extra value beyond it.

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 concise sentence that front-loads the core purpose without any filler. Every word contributes to understanding, and it is appropriately sized for such a simple operation.

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 tool with no output schema, the description is fully adequate. It tells the agent exactly what the tool does, and the annotation covers the safety profile. Nothing essential 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?

The tool has zero parameters, so there is nothing for the description to explain about parameter meaning. The baseline for zero-parameter tools is 4, and the description does not need to add anything beyond what the empty schema implies.

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 clearly states the verb 'Get' and the resource 'serial(s) of currently connected devices/emulators'. It is distinct from sibling tools like list_emulators, which lists emulators, whereas this tool fetches serials of connected devices. The purpose is specific and 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 description implies when to use it—when you need serial numbers of connected devices—but does not explicitly mention alternatives or when not to use it. The context is clear, but there is no explicit exclusion or comparison to siblings like list_emulators.

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?

The readOnlyHint annotation already signals no side effects, and the description aligns with that by being a simple 'get' operation. The description adds context about coordinate space but does not describe the return format or any other behavioral details beyond the annotation.

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 concise, with two sentences that deliver all necessary information without redundancy or unnecessary detail. It is well-structured and front-loaded with the core purpose.

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

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

The description provides sufficient context for an agent to understand when to call this tool, especially the shared coordinate space note. It clearly indicates the output (screen size and density), and no output schema is present, so no further return-value explanation 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?

The only parameter 'serial' is fully described in the schema (optional, for device selection). The tool description itself does not add parameter information, and with 100% schema coverage, the baseline of 3 applies.

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

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

The description clearly states the tool's purpose: retrieving the screen size in pixels and density. It also explains the significance of the coordinate space, making it 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 description implicitly guides usage by noting that screenshots, tap coordinates, and describe_ui bounds share the same pixel space, suggesting when this info is relevant. However, it does not explicitly name alternatives or contrast with other 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 provided, the description carries the full burden of behavioral disclosure. It states the action but does not mention side effects, prerequisites (e.g., app must be installed, device must support runtime permissions), or the outcome of granting an already-granted permission. The example adds a minor clue but is insufficient.

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 that immediately conveys the action and includes a relevant example. There is no redundant or filler content, making it highly efficient.

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 tool with three parameters and no output schema, the description is mostly complete. It covers the core action and gives an example for permission. It does not explicitly mention the optional serial behavior or return value, but these are implicitly handled by the schema and are not critical for a straightforward grant operation.

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% (only serial has a description). The description provides an example for the permission parameter (android.permission.CAMERA) but does not clarify what 'package' refers to or give formatting hints. It partially compensates for the low coverage but leaves the package parameter undefined.

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 'Grant' and a clear resource 'runtime permission to an app', with a concrete example (android.permission.CAMERA). This distinguishes it from sibling tools like launch_app or install_app, which have different verbs and purposes.

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 implies when to use the tool (when a runtime permission needs to be granted), but it does not explicitly mention when not to use it or provide alternatives. No exclusions are stated, so it relies on the user inferring the usage context from the purpose.

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

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

With no annotations, the description carries the full burden of behavioral disclosure, but it only states the basic action. It does not mention that installation may overwrite an existing app, require permissions, or have side effects on the device. No behavioral traits beyond the core mutation are 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?

The description is a single efficient sentence with no filler and the key action is front-loaded. It is appropriately short for the simple operation, though it omits useful context that would be handled by other dimensions.

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 mutation tool with no annotations and no output schema, but the description does not explain prerequisites, side effects, or post-install behavior. The schema covers parameters, but operational context 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?

The input schema already describes both parameters with 100% coverage, so the baseline is 3. The description adds no extra meaning to apk_path or serial beyond what the schema provides.

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

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

The description names a specific verb and resource ('Install an .apk') and clearly differentiates this from siblings like uninstall_app, launch_app, and push_file. An agent can immediately identify the operation 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?

No guidance is given about when to choose install_app over related tools, nor are prerequisites such as a connected device or existing installation state mentioned. The only usage signal is the verb itself, which does not provide decision support beyond the tool's name.

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

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states the action (send a keycode) without mentioning side effects, permissions, error handling, or response behavior. For a tool that sends an event, an agent would benefit from knowing if it can be safely repeated, what happens on invalid keycodes, or whether it requires a focused window. This is a significant gap given the absence of annotations.

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 sentence that front-loads the core action, provides illustrative examples, and immediately clarifies its scope relative to a sibling tool. Every word earns its place; there is no padding or redundancy.

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 only two parameters and no output schema, the description is largely sufficient. It covers the purpose, gives an example for the main parameter, and the serial parameter is documented in the schema. The only minor gap is lack of detail on error handling or invalid keycode behavior, but given the tool's simplicity and the examples provided, an agent can call it correctly in most cases.

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

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

Schema coverage is 50% (only serial has a description; keycode is just a string). The description adds value by providing examples of valid keycode formats ('KEYCODE_ESCAPE, 66'), which partially compensates for the missing schema description. However, it does not enumerate all possible keycodes or explain the accepted format beyond examples, so the agent may still be uncertain about how to specify arbitrary keys. The examples help but are not comprehensive.

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 clearly states the action ('Send any Android keycode'), gives concrete examples (KEYCODE_ESCAPE, 66), and explicitly distinguishes it from the sibling press_button ('for keys not covered by press_button'). An agent immediately knows what this tool does and how it differs.

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 provides a clear when-to-use condition: for keys not covered by press_button. This is an explicit exclusion that routes the agent correctly. It does not mention when not to use it (e.g., for text input, use type_text), but the primary alternative is covered, making the guidance effective if 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?

With no annotations provided, the description carries the full burden. It discloses the mechanism ('uses its main launcher activity') and supports a specific activity, but does not mention error behavior (e.g., missing package, invalid activity) or side effects. Some behavioral context is added, but significant gaps remain.

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

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

The description is a single, front-loaded sentence with zero waste. It communicates both primary and secondary usage without redundancy, making it highly efficient.

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

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

Given the tool's simplicity (3 params, 1 required, no output schema), the description covers the essential purpose and usage. However, it omits edge-case behavior (e.g., what happens if the app is not installed) and lacks explicit guidance on when to prefer this over alternatives, leaving minor gaps for an agent.

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

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

The input schema provides complete descriptions for all three parameters (serial, package, activity) at 100% coverage. The tool description adds no additional parameter-specific meaning beyond the schema, so the baseline of 3 is appropriate.

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

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

The description states a specific verb 'Launch' and resource 'app', with two clear modes (by package or specific activity). It distinguishes itself from sibling tools like install_app, uninstall_app, and terminate_app, making the purpose 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 description clearly conveys when to use this tool (to launch an app or activity) but does not explicitly state when not to use it or name alternatives. The context is clear enough, but it lacks exclusionary guidance that would fully route the agent.

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

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

Annotations already declare readOnlyHint=true, so the description does not need to restate that. It adds useful behavioral context by revealing the default filtering behavior ('third-party only by default'), which implies that include_system can override this. This goes beyond the annotations and helps the agent predict behavior.

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

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

A single sentence with no fluff, front-loaded with the action and scope. It is appropriately sized for the tool's simplicity and wastes no words.

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

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

For a simple list tool with readOnly annotations, the description covers the core purpose and default behavior. It does not mention the return format or how the optional serial parameter is resolved, but these are partially covered by the schema. Overall it is adequate, though a bit more context on the output would improve it.

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 has a description but include_system does not. The description partially compensates by implying the meaning of include_system through the default filter statement, but it does not explicitly explain the parameter's effect. The agent must infer that setting include_system=true will include system apps.

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 clearly states the verb 'List' and the resource 'installed packages', and immediately clarifies the default scope with 'third-party only by default'. This distinguishes it from sibling tools like install_app, uninstall_app, launch_app, etc., so an agent can easily tell them apart.

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 provides no explicit guidance on when to use this tool versus alternatives, nor any conditions or exclusions. It only states what it does. An agent must infer that this is for enumerating installed apps, but no context is given for scenarios like checking before launching or filtering.

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?

The annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds value by specifying the exact scope of the listing (AVDs and connected devices), which is behavioral context beyond the annotation. It does not describe output format, but that is not a requirement given the simple nature and 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?

The description is a single, concise sentence that front-loads the primary action ('List') and immediately specifies the targets. There is no redundancy or unnecessary detail.

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

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

Given the tool has no parameters, no output schema, and a read-only annotation, the description is largely complete for a listing tool. It specifies what it lists. The only gap is the lack of detail about the output format (e.g., whether it returns names, paths, or details), but this is a minor omission for a simple list 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?

There are zero parameters and the schema coverage is 100% (empty schema). Per rubric, the baseline for zero parameters is 4. The description does not need to explain parameters since none exist.

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 'List' and clearly identifies the resources: available Android Virtual Devices (AVDs) and currently connected devices/emulators. This clearly differentiates from sibling tools like get_booted_serial or get_screen_info, which target specific devices or details.

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 implies its usage: to enumerate available devices. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention any exclusion criteria or when not to use it. The purpose is clear, but explicit guidance on alternatives is absent.

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

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

Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the filtering behavior but does not disclose other traits such as whether the tool blocks, the output format, or whether it captures a snapshot versus streaming. With the annotation covering safety, the description provides minimal additional behavioral context.

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, concise sentence that leads with the primary action ('Read recent logcat output') and mentions optional filters. There is no filler or redundant information, making it easy for an agent to parse quickly.

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 read-only tool with four optional parameters and no required fields, the description is nearly complete. It covers the core purpose and filtering options. The only gap is the lack of information about the return format or any potential caveats (e.g., whether it reads only the buffer or streams), but given the tool's simplicity and the presence of the readOnlyHint annotation, this is a minor omission.

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 four parameters are already documented with descriptions. The tool description reinforces the purpose of 'filter' and 'package' but does not add new semantic details beyond what the schema provides. Baseline of 3 is appropriate when the schema carries the full parameter documentation.

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 ('Read') and resource ('logcat output'), and clearly distinguishes the tool from its sibling 'clear_logcat' by describing the read operation. It also names the optional filters (regex, package), making the tool's purpose 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 description implies the tool is for reading logcat, but it does not explicitly state when to use it over alternatives like adb_shell (which could also fetch logs) or when not to use it. It does not mention the sibling 'clear_logcat' as the tool to use for clearing, leaving usage guidance 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 are provided, so the description carries full responsibility. It only restates the basic action without revealing behavioral details such as the default duration (though duration_ms exists in schema), side effects, or return values. This is insufficient for a tool that performs a timed press.

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 short sentence, which is concise. However, given the tool has four parameters and no annotations, it is under-specified rather than appropriately concise; it lacks necessary detail.

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

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

The description is grossly incomplete: it omits parameter explanations, usage context, behavioral nuances, and output/return information. For a tool with four parameters and no annotations or output schema, this is far from sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is only 25% (only serial has a description). The description does not explain x, y, duration_ms, or serial semantics at all, failing to compensate for the schema gaps. It adds no value beyond what the schema already provides.

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

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

The description clearly identifies the action ('Long-press') and the target ('x,y pixel coordinates'), which is specific and distinguishable from siblings like tap or swipe. However, it doesn't explicitly contrast with alternatives, but the verb itself implies a distinct action.

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 provides no guidance on when to use this tool versus alternatives like tap or swipe. It does not mention conditions, prerequisites, or scenarios where a long-press is appropriate.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'open' without describing what happens on success or failure, whether it returns any data, or if it is asynchronous. This leaves significant ambiguity for a tool that performs an action.

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 that is immediately understandable. It is concise with no wasted words. However, it is so brief that it omits crucial details, but for conciseness and structure, it is well-formatted.

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

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

Given the lack of annotations, output schema, and minimal parameter descriptions, the description is not complete. It does not explain return values, error handling, or the exact behavior of opening a URL. The agent would need to experiment to understand the tool's full capabilities, making it insufficient for reliable invocation.

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

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

The schema covers 50% of parameters with a description for 'serial' but none for 'url'. The tool description does not compensate for this gap, failing to explain what a valid 'url' looks like (e.g., must include scheme) or any formatting requirements. The agent gets no added clarity beyond the bare 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 clear verb ('open') and resource ('URL or deep link') with a location ('in the device'). It is specific enough to be understood, but it does not explicitly distinguish itself from sibling tools like launch_app, which could also open things. Still, the resource type is distinct, so it earns a 4.

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 provides no guidance on when to use this tool versus alternatives. There is no mention of scenarios, prerequisites, or why one would choose this over launch_app or other navigation tools. The agent is left to infer the appropriate context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the action and the button list, but fails to mention potential side effects (e.g., pressing POWER might lock the screen, BACK might exit an app, VOLUME_UP changes system volume). There is no mention of whether the action is synchronous, requires permissions, or what the return value is. This is a significant gap for a hardware interaction 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?

The description is a single concise sentence that front-loads the primary action. The button list is embedded inline, which is efficient though slightly cluttered. No wasted words; it earns its place.

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

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

For a simple button-press tool, the description covers the basic action and parameter list. However, given the lack of annotations, it omits critical behavioral context such as side effects, potential blocking behavior, and whether it works on all Android versions. The description is minimally adequate but leaves an agent uncertain about consequences.

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 input schema already defines the button enum and a description for serial, giving 50% schema description coverage. The tool description merely repeats the button list without adding any semantic guidance on when to use each button or how they behave. It does not explain the serial parameter's purpose beyond what the schema says. The description adds no value 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?

The description clearly states the action ('Press a hardware/navigation button') and enumerates the specific buttons it supports (HOME, BACK, etc.). This makes the tool's purpose unambiguous and distinct from siblings like tap (screen touch) and key_event (keyboard input). The verb+resource structure is precise.

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 provides no guidance on when to use this tool versus alternatives like tap, key_event, or swipe. It does not mention that hardware buttons may behave differently across devices or that some buttons (e.g., POWER) could trigger system-level actions. No context on use cases or exclusions is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the basic copy operation without mentioning side effects (e.g., overwriting local files), permission requirements, error conditions, or whether it works on directories. This is minimal disclosure for a tool with no annotation fallback.

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 sentence with no unnecessary words, front-loading the action and direction. It is concise and immediately scannable.

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 output schema and no annotations, the description is thin. It omits details like whether the local file is overwritten, what happens if the remote file does not exist, or if the device serial is required when multiple devices are connected (though the schema implies it is optional). An agent has limited information to anticipate outcomes or handle edge cases.

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

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

Schema description coverage is only 33% (serial is described, remote_path and local_path are not). The description adds directional context that clarifies remote_path is on the device and local_path is on the local machine, which partially compensates. However, it does not specify path formats, whether they must be absolute, or any constraints beyond the implied device/local distinction.

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 'Copy a file from the device to the local machine' uses a clear verb (copy) and resource (file from device to local), making the purpose unmistakable. It implicitly contrasts with the sibling push_file, which copies in the opposite direction, so the tool's scope is distinct.

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 implies the use case (transferring a file from device to local) but does not explicitly state when to use it versus alternatives like push_file or adb_shell. There are no exclusions or explicit 'use when' guidance; the direction of transfer is the only implicit differentiator.

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?

The description does not disclose any behavioral aspects such as whether the operation overwrites existing files, requires permissions, or has side effects. Since there are no annotations, the description carries the full burden, which it does not meet.

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, concise sentence with no unnecessary words or fluff. It efficiently conveys the tool's purpose.

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

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

For a simple file transfer tool, the description and schema provide the essential context: the action and the key parameters. No output schema is present, so return values are not needed. Additional context like error handling or device selection edge cases is not required for such a straightforward operation.

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 covers 2 out of 3 parameters with descriptions (serial and remote_path), leaving local_path without a description. The description adds no further detail beyond the schema, and the parameter names provide adequate semantic clues. Medium coverage, so a baseline score of 3 is appropriate.

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

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

The description clearly states the action: copying a local file to the device. It is unambiguous and distinguishes the tool from pull_file, which performs the reverse operation.

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 usage is implied by the description and tool name, but no explicit guidance is provided regarding when to use this tool versus alternatives like pull_file or adb_shell. There is no mention of alternative tools or conditions.

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 provided, the description must carry the full behavioral burden. It discloses the maximum recording length and the output format (.mp4), and implies a pairing with stop_recording. However, it omits details like whether recording overwrites existing files, if it blocks execution, or any permissions needed, leaving some behavioral uncertainty.

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

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

The description is two short sentences with no filler. It leads with the core action and constraint, then immediately provides the follow-up instruction. Every word earns its place.

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

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

The tool is relatively simple (2 optional parameters, no output schema), but the lack of annotations and output schema means the description should cover more. It explains the start/stop workflow but doesn't mention return behavior, error cases, or whether the recording is saved automatically. Adequate for basic use, but not fully 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 only 50% (serial has a description, output_path only has a default). The description adds no information about either parameter, so it fails to compensate for the missing schema documentation. An agent must guess the purpose of output_path beyond its default value.

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

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

The description clearly states the tool's purpose: starting a screen recording with a specific duration limit (3 minutes). It distinguishes itself from the sibling stop_recording by explicitly naming the companion tool, leaving no ambiguity about its role.

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 instructs the agent to call stop_recording to finalize the capture, which is essential workflow guidance. It doesn't explicitly state when to prefer this over alternatives, but there are no direct alternatives for recording among the siblings, so the pairing guidance is sufficient.

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?

The description does not contradict the readOnlyHint annotation, and it mentions saving a file, which is a mild side effect. However, it does not add significant behavioral context beyond the annotations, such as permissions or edge cases.

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 two concise sentences, front-loading the action and then elaborating on the output. It is well-structured and free of unnecessary detail.

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?

In the absence of an output schema, the description provides sufficient context about the returned data (a downscaled copy plus scale factor). It does not over-explain but covers the essential behavior expected from a screenshot tool.

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

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

Schema description coverage is 75%, below the 80% threshold, so the description must compensate for the missing parameter details. The description only indirectly references output_path and return_image without explaining parameters like serial or inline_max_px more deeply than 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 clearly states the action ('Take a screenshot of the device screen') and specifies the output behavior: saving a full-resolution PNG and returning a downscaled copy inline with scale factor information. This is specific and 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 description implies usage for capturing the screen but does not explicitly state when to use it versus alternatives. No comparative guidance is provided, only the tool's inherent functionality.

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 only states the action ('Switch') without disclosing side effects, reversibility, permission requirements, or behavior when multiple devices are connected. For a mutation tool, this is a significant gap.

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

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

The description is a single, front-loaded sentence with zero waste. It efficiently communicates the core action and object, ideal for quick agent parsing.

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 tool, the description is minimally sufficient but lacks context about device selection (e.g., when 'serial' is needed) and any prerequisites. Given no annotations or output schema, it could be more complete, but the core action is adequately conveyed.

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 has a description, appearance does not). The description adds no parameter-specific meaning—it does not explain the 'appearance' enum values or the optionality of 'serial'. It fails to compensate for the schema's incomplete coverage.

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 clearly states a specific verb ('Switch') and resource ('the device') with a precise scope ('between light and dark mode'). It unambiguously conveys the tool's function and distinguishes it from unrelated siblings like set_orientation or set_status_bar.

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 provides no guidance on when to use this tool versus alternatives, and no mention of prerequisites or exclusions. While the purpose is clear, there is no explicit context for selection among the many 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 provided, the description carries the full burden. It states the action and the emulator constraint, but does not disclose prerequisites (e.g., emulator must be booted), side effects (e.g., overriding existing location), or error behavior. This is a minimal disclosure for a mutation 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?

The description is a single sentence that is front-loaded with the core action and constraint. There is no redundant text or filler, making it appropriately concise.

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 setter with no output schema and sparse annotations, the description is insufficiently complete. It does not mention that the emulator must be running, that a serial is needed when multiple devices are connected, or what happens on failure. The agent gets little context beyond the bare action.

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% (only 'serial' is described). The tool description does not elaborate on 'latitude' or 'longitude' beyond the context of setting a GPS location. It does not mention coordinate formats, ranges, or constraints, so the agent must rely on the parameter names 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?

The description uses a clear verb-resource pair ('Set the simulated GPS location') and adds a key constraint ('emulator only'), which helps distinguish it from sibling tools like set_orientation or set_appearance. It lacks an explicit sibling name but the purpose is unambiguous.

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

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

No guidance is given on when to use this tool versus alternatives, nor any prerequisites or exclusions beyond the 'emulator only' note. The description does not mention when not to use it or how it relates to other device-control 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Rotate the screen' discloses no behavior: nothing about whether the change is persistent, whether reverse orientations are supported on all devices, what happens when an unsupported orientation is requested, or any side effects. A one-line statement is entirely insufficient for a device-mutating 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?

The five-word sentence is technically terse, but this is under-specification rather than conciseness. There is no structure or front-loading of important constraints, and the sentence doesn't earn its place by conveying meaningful operational detail.

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 and no output schema, a single clause is grossly incomplete. Missing entirely: the meaning of each orientation enum value, when serial is required, the return behavior, and device compatibility for reverse orientations. An agent cannot call this tool correctly with confidence.

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 has a description; orientation has only an enum with no description). The description adds zero meaning beyond the schema — it doesn't explain what each orientation value does or how serial selection works. Since coverage is borderline rather than high, the description should have compensated but does not.

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

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

States a verb (rotate) and resource (the screen), giving basic purpose. However, 'rotate' implies relative motion while the schema's enum values (portrait, landscape, reverse_portrait, reverse_landscape) indicate an absolute orientation set, so the wording is mildly misleading. None of the siblings handle orientation, so it is implicitly distinct, but the description doesn't make that differentiation explicit.

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

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

No guidance on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or contexts in which set_orientation is preferred over other device-state tools like set_appearance or set_location. An agent has to infer usage entirely from the tool name.

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, but it only states the action without disclosing side effects, reversibility, or whether changes persist. It does not mention that SystemUI demo mode may need to be activated or that the tool overrides system UI temporarily. This is insufficient for a mutating 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?

The description is a single, front-loaded sentence with no wasted words, but it is too sparse. It omits essential details, making it concise at the expense of usefulness.

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 6 parameters, no annotations, and no output schema, the description is severely incomplete. It does not explain parameter usage, optionality of serial, behavior when no parameters are provided, or any special requirements. An agent would struggle to invoke this correctly without additional information.

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 50% (time, serial, wifi_level have descriptions; battery_level, battery_charging, hide_notifications do not). The description mentions 'notifications' but does not clarify which parameter maps to it, nor does it explain ranges or relationships (e.g., battery_charging). It adds little beyond the schema and fails to compensate for the missing parameter descriptions.

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 clearly states the action ('Override') and the target ('status bar via SystemUI demo mode'), listing the affected aspects (time, battery, wifi, notifications). It is specific enough to distinguish from a reset tool like clear_status_bar, though it does not explicitly name that 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?

The description gives no guidance on when to use this tool versus alternatives, nor does it mention clear_status_bar as a way to reset. It lacks context about prerequisites or scenarios (e.g., demo mode must be enabled), leaving the agent to infer usage.

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 that the tool only works on emulators and that it simulates accelerometer motion, which is useful. However, it does not mention what happens on failure, whether a booted emulator is required, or what the tool 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?

The entire description is one efficient sentence with the key constraint front-loaded. Every part adds value: the action, the emulator-only restriction, the simulated behavior, and a concrete example.

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 one optional parameter, no output schema, and no nested objects, the description plus schema fully cover the essential context. An agent knows what the tool does, where it can be used, why it would be used, and how the serial parameter behaves.

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

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

Schema description coverage is 100% and the only parameter, serial, is already well described in the schema. The description adds no additional parameter-level meaning, 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?

The description uses a specific verb and resource ('Shake the device') and immediately clarifies the platform constraint and intended effect ('emulator only — simulates accelerometer motion'). It also gives a concrete use case (React Native dev menu), which disambiguates it from sibling input tools like swipe or 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 description explicitly states when the tool applies ('emulator only') and gives an example trigger ('e.g. to open the React Native dev menu'). It effectively tells an agent not to use this on physical devices, and no alternative sibling is relevant for a shake gesture.

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 full responsibility for behavioral disclosure. It only states the action without revealing side effects such as unsaved state loss, whether the shutdown is graceful, or what occurs if the emulator is not running. This is a significant gap for a potentially destructive operation.

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

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

The description is a single sentence with no filler, leading with the action verb and resource. It is optimally concise and 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 tool with one optional parameter and no output schema, the description is minimal but might suffice. However, it could be more complete by mentioning the effect on running processes or the need for a booted emulator. The lack of any behavioral caveats leaves room for improvement.

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 input schema already fully describes the single 'serial' parameter, including its optionality and example. The description adds no parameter-level information, so the baseline of 3 applies given 100% schema coverage.

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 clearly states the verb 'shut down' and the resource 'running emulator', making its purpose unambiguous. It is distinctly opposite to sibling tools like boot_emulator and does not require inference.

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 implies when to use the tool (when an emulator is running and needs to be stopped) but provides no explicit guidance on alternatives or exclusion conditions. For example, it does not mention that boot_emulator is the tool for starting an emulator, leaving usage context implicit.

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 provided, the description carries the full burden of behavioral disclosure. It states the core action and result but does not cover edge cases like behavior when no recording is active, error handling, or whether the operation is destructive to the recording. It is adequate but not thorough.

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, efficient sentence that front-loads the action and outcome. It contains no unnecessary words and is immediately scannable.

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 tool with one optional parameter and no output schema, the description is mostly complete. However, it omits usage context (e.g., when to invoke it) and does not specify the save location or return behavior, which would be helpful for an agent.

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

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

The schema description covers the single optional 'serial' parameter at 100% coverage. The tool description adds no additional meaning or context beyond the schema, so a baseline of 3 is appropriate.

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

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

The description states a specific verb (stop) and resource (active screen recording) along with the outcome (save video locally). It clearly differentiates from sibling record_video by describing the inverse action.

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

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

There is no guidance on when to use this tool relative to siblings, such as record_video. It does not mention that it should be used after a recording has been started or any prerequisites, leaving the agent to infer the context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only mentions the action and pixel coordinates, but does not reveal side effects, device requirements, or whether it simulates user input in a way that could affect the UI. This is a significant gap for a gesture 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?

The description is a single, efficient sentence that front-loads the action and key unit detail. No redundant or filler content; it 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?

Given the tool has six parameters, no output schema, and no annotations, the description is minimal. It omits essential context like device selection (serial), duration default, and potential side effects. An agent cannot fully understand how to correctly invoke this tool from the description alone.

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 low (33%), so the description must compensate. It clarifies that coordinates are in pixels and implies start and end points, but it does not explicitly map to x1,y1,x2,y2 or explain the role of serial and duration beyond what the schema already states. It adds some value but not comprehensive parameter semantics.

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 clearly states the action (swipe) and its target (from one point to another) with the unit (pixels). It is specific and distinguishes itself from sibling gesture tools like tap or long_press by indicating a continuous movement. No tautology or ambiguity.

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 offers no guidance on when to use this tool instead of alternatives, nor does it mention any exclusions or prerequisites. It simply states the operation without contextualizing its selection among the 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 carries the full burden. It states the core action but does not disclose side effects (e.g., triggering a UI event), whether it waits for completion, or any error conditions. For a simple tap, this is minimal but acceptable; it adds no context beyond the literal action.

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, efficient sentence with zero unnecessary words. It front-loads the action and coordinates, making it immediately scannable and memorable.

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 tap tool with two required numeric params and an optional device selector, the description is sufficient for an agent to call it correctly. No output schema exists, and the action is straightforward; nothing essential 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?

The schema lists x and y as plain numbers with no description, while the description clarifies they are pixel coordinates on the screen, adding meaningful context. The optional serial is already described in the schema. The description compensates for the low schema coverage of the required 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 clearly states the action ('Tap') and the resource ('screen') with specific coordinates. It distinguishes from siblings like swipe and long_press by implying a discrete, single touch event. The purpose is unambiguous and easy to parse.

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

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

There is no guidance on when to use tap versus alternatives such as swipe, long_press, or press_button. The description provides no context about prerequisites, scenarios, or exclusions, leaving the agent to infer usage from the name 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Force-stop' implies immediate termination, but it does not mention potential data loss, whether the action is reversible, or any required permissions. The description lacks the detail expected for a mutation tool without annotation support.

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, focused sentence with no wasted words. It is appropriately terse for a simple tool and front-loads the core action 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 mutation tool with no annotations and no output schema, the description is incomplete. It does not clarify what value to pass for the required 'package' parameter, nor does it explain the consequences of force-stopping (e.g., losing unsaved state). An agent would need additional context to call this correctly.

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

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

Schema coverage is 50%: only 'serial' has a description, while 'package' (required) is undocumented. The description 'a running app' only vaguely implies that package identifies the app, adding no format, constraints, or examples. It fails to compensate for the missing parameter documentation.

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 'Force-stop a running app' clearly identifies the action (force-stop) and the resource (a running app). It is distinct from sibling tools like launch_app, clear_app_data, or uninstall_app, though it does not explicitly name alternatives. The verb is specific enough to differentiate, but lacks the explicit sibling differentiation seen in top-tier examples.

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

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, exclusions, or scenarios where launch_app or uninstall_app would be more appropriate. The agent is left to infer usage context from the name 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?

With no annotations provided, the description carries the behavioral disclosure burden. It usefully reveals that this uses `adb input text` and cannot type emoji or non-Latin characters, but it does not mention whether text is appended or replaces existing content, how special characters are handled, or what happens when no field is focused.

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 entire description is one focused sentence with the action first and the essential limitation appended. There is no filler or redundant restatement of schema fields.

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 tool, the description conveys the target, the prerequisite that an input field is focused, and the main input limitation. It does not cover error behavior or special-character handling, but the core usage is clear enough for an agent to invoke it correctly.

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

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

Schema coverage is only 50% because the `text` parameter lacks a schema description. The description compensates by adding the critical ASCII-only constraint for `text`. The `serial` parameter is already adequately described 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?

The description states a specific action ('Type text'), a clear target ('currently focused input field'), and a key constraint (ASCII only). This distinguishes it from sibling tools like tap or key_event, which handle input differently.

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 field must already be focused and signals the ASCII-only limitation. However, it does not explicitly name alternative tools or explain when to prefer this over key_event or other input methods.

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

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

Annotations already declare destructiveHint=true, and the description's 'Uninstall' is consistent with that. The description does not add extra behavioral context like permanent removal of app data or possible failure on system apps, but the annotation already covers the destructive nature.

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

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

A single sentence with no filler, front-loaded with the action and target. Every word contributes to understanding the tool's purpose.

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

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

The description is adequate for a simple uninstall operation, but it omits details about expected output, failure modes, or prerequisites such as the app needing to be installed. With no output schema and only a one-line description, an agent gets the basics but little else.

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

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

The description adds meaning by indicating that the tool works by package name, which helps map the required 'package' parameter. However, the optional 'serial' parameter is only documented in the schema, and the schema has 50% description coverage, so the description only partially compensates.

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 a specific verb, 'Uninstall', and identifies the resource ('an app') and the key identifier ('by package name'). This clearly distinguishes it from sibling tools like install_app, launch_app, terminate_app, and clear_app_data.

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

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

The description gives no explicit guidance about when to use this tool versus alternatives. It does not mention when not to use it or point to related tools such as terminate_app or clear_app_data, so an agent must infer the usage context from the tool name 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?

Annotations include readOnlyHint=true, so the read-only nature is already disclosed. The description adds valuable behavioral context: the polling mechanism and the ability to wait for either appearance or disappearance. It does not contradict annotations and adds meaningful information about the operation's dynamics.

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 two concise sentences with no redundant words. The core functionality is front-loaded, and the usage context is provided in the second sentence. Every part earns its place.

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

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

For a simple polling tool with readOnlyHint annotation, the description adequately covers what it does, when to use it, and the key behavior (appear/disappear). It does not explain timeout error behavior, but the timeout_seconds parameter with default value provides that information. No output schema means return value is not critical.

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% (gone and serial have descriptions; query and timeout_seconds do not). The description adds 'element matching the query', giving semantic meaning to the query parameter but not specifying its syntax. It does not address timeout_seconds, but the name is self-explanatory. This partially compensates for the schema gap.

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

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

The description uses a specific verb 'poll' and clearly states the resource: 'an element matching the query'. It distinguishes between appearing and disappearing, making it unambiguous. It is distinct from find_element (which likely returns a snapshot) and other interaction tools.

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 context: 'Useful after navigation or network calls.' This implies when to use it. However, it does not explicitly mention alternatives or when not to use it, such as using find_element for a single check.

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