Server Quality Checklist

Tool Scores

• android_launch_appC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden for behavioral disclosure. It states the action ('Launch') but doesn't describe what happens (e.g., app opens on device, may fail if not installed, requires device to be connected/on), permissions needed, or error conditions. This is a significant gap for a tool with potential side effects.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero waste—it directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, 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.

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete for a tool that performs an action with potential side effects. It lacks details on behavior (e.g., success/failure states, device requirements), return values, or error handling, which are crucial for an agent to use it correctly in context with sibling tools.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear descriptions for both parameters (package name and optional device serial). The description adds no additional parameter semantics beyond what the schema provides, such as format examples or constraints. Baseline 3 is appropriate since the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Launch') and target resource ('Android app by package name'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'android_list_packages' or 'android_execute_command' that might also interact with apps, leaving some ambiguity about its unique role.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., device connectivity), exclusions (e.g., apps not installed), or compare it to siblings like 'android_execute_command' for broader commands or 'android_list_packages' for discovery, leaving the agent to infer usage context.

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

• android_list_packagesC
  2.9/5.0
  Behavior2/5

  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 states it 'lists' packages, which implies a read-only operation, but doesn't specify what the output includes (e.g., package names, versions, permissions), whether it requires ADB access or specific permissions, or if there are rate limits. The description is minimal and lacks crucial behavioral details for a tool interacting with a device.

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

  Conciseness5/5

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

  The description is a single, clear sentence that front-loads the core purpose without any fluff or redundancy. Every word earns its place, making it highly efficient and easy to parse. It's appropriately sized for a simple listing tool.

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

  Completeness2/5

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

  Given the complexity (device interaction tool with no annotations and no output schema), the description is incomplete. It doesn't explain the return format (e.g., list of strings, JSON structure), error conditions, or dependencies like ADB setup. For a tool that likely outputs data, the lack of output details is a significant gap, making it inadequate for full contextual understanding.

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

  Parameters3/5

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

  Schema description coverage is 100%, with both parameters (filter and deviceSerial) well-documented in the schema. The description adds no additional parameter information beyond implying a listing action. According to the rules, with high schema coverage (>80%), the baseline is 3 even with no param info in the description, which fits here.

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

  Purpose4/5

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

  The description clearly states the verb ('List') and resource ('installed packages on the Android device'), making the purpose immediately understandable. It distinguishes from siblings like android_execute_command or android_launch_app by focusing on package enumeration rather than execution or interaction. However, it doesn't explicitly differentiate from potential similar tools (e.g., if there were a 'list_system_packages' sibling), so it's not a perfect 5.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., device connectivity), exclusions (e.g., not for uninstalled packages), or related tools (e.g., whether android_uiautomator_dump might overlap). Usage is implied from the name and purpose alone, but no explicit context is given.

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

• android_screenshotC
  2.9/5.0
  Behavior2/5

  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 states 'capture a screenshot' but doesn't mention any behavioral traits such as permissions needed, whether it requires an unlocked device, potential delays, or what happens if the device is off. This leaves significant gaps for a tool that interacts with hardware.

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

  Conciseness5/5

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

  The description is a single, direct sentence that efficiently conveys the core action without any wasted words. It's appropriately sized and front-loaded, 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.

  Completeness2/5

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

  Given the complexity of interacting with an Android device and the lack of annotations and output schema, the description is insufficient. It doesn't explain what the tool returns (e.g., base64 image or file path), error conditions, or dependencies, making it incomplete for safe and effective use by an agent.

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

  Parameters3/5

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

  The input schema has 100% description coverage, clearly documenting both optional parameters. The description adds no additional parameter semantics beyond what the schema provides, so it meets the baseline score of 3 for high schema coverage without extra value.

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

  Purpose4/5

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

  The description clearly states the verb ('capture') and resource ('screenshot from the Android device'), making the purpose immediately understandable. However, it doesn't differentiate from sibling tools like 'android_capture_frame_scrcpy' or 'android_get_latest_frame', which appear to be related screenshot/capture tools, so it doesn't reach the highest score.

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

  Usage Guidelines2/5

  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. With multiple sibling tools that might involve capturing or getting frames (e.g., android_capture_frame_scrcpy, android_get_latest_frame), there's no indication of when this specific screenshot tool is preferred or what distinguishes it, leaving the agent without usage context.

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

• android_swipeC
  2.9/5.0
  Behavior2/5

  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 mentions the gesture but doesn't cover important aspects like whether this requires device interaction permissions, if it's synchronous/asynchronous, error conditions, or what happens on multi-touch screens. The default duration is mentioned in the schema but not in the description.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that states exactly what the tool does with zero wasted words. It's appropriately sized for a straightforward input/output tool and is perfectly front-loaded.

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

  Completeness2/5

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

  For a tool that performs device interaction with no annotations and no output schema, the description is insufficient. It doesn't explain what constitutes valid coordinate ranges, how coordinates map to screen dimensions, what happens if coordinates are out of bounds, or what the expected outcome of a successful swipe is.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond what's already in the schema. The baseline of 3 is appropriate when the schema does all the parameter documentation work.

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

  Purpose4/5

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

  The description clearly states the action ('perform a swipe gesture') and specifies it's between two coordinates, which distinguishes it from other touch-based interactions like android_touch or android_uiautomator_click. However, it doesn't explicitly differentiate from all sibling tools beyond the basic gesture type.

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

  Usage Guidelines2/5

  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 like android_touch or android_uiautomator_scroll_in_element. The description only states what it does, not when it's appropriate or what scenarios it's designed for.

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

• android_touchC
  2.9/5.0
  Behavior2/5

  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 mentions 'simulate a touch event' which implies a write/mutation operation, but fails to specify critical details like required permissions (e.g., device accessibility), side effects (e.g., potential app state changes), error handling, or response format. This is a significant gap for a tool that interacts with device input.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It is front-loaded with the core action ('simulate a touch event') and avoids redundancy, 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.

  Completeness2/5

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

  For a tool with no annotations, no output schema, and parameters that control device interaction, the description is incomplete. It lacks information about behavioral traits (e.g., mutation effects, error conditions), output expectations, or integration context (e.g., how it relates to other Android tools like android_start_scrcpy_stream). This leaves the agent under-informed for safe and effective use.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters (x, y, duration, deviceSerial). The description adds no additional meaning beyond the schema's parameter descriptions, such as coordinate system details (e.g., screen resolution) or practical usage tips. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('simulate a touch event') and target ('at specific screen coordinates'), which distinguishes it from siblings like android_swipe or android_uiautomator_click that involve different interaction types. However, it doesn't explicitly differentiate from all siblings (e.g., android_uiautomator_click also involves touch-like actions but with element-based targeting).

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

  Usage Guidelines2/5

  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 android_swipe (for drag gestures) or android_uiautomator_click (for element-based interactions). It lacks context about prerequisites (e.g., device state) or exclusions, leaving the agent to infer usage from the tool name and parameters alone.

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

• android_uiautomator_clear_textC
  2.9/5.0
  Behavior2/5

  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 states the action (clear text) but lacks details on what 'clear' entails (e.g., does it simulate backspace, delete all text at once, require focus?), potential side effects (e.g., might trigger UI events), error conditions (e.g., if element not found or not clearable), or performance aspects. This is a significant gap for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, direct sentence that efficiently conveys the core functionality without unnecessary words. It's front-loaded with the key action and target, making it easy to parse quickly. Every part of the sentence earns its place by specifying the operation and how to identify the element.

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

  Completeness2/5

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

  Given the complexity (a mutation tool for Android UI automation), lack of annotations, and no output schema, the description is incomplete. It doesn't explain behavioral traits, error handling, or return values (e.g., success/failure status), which are crucial for safe and effective use. While the schema covers parameters well, the overall context for tool invocation is insufficient.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear descriptions for both parameters (resourceId and deviceSerial). The description adds minimal value beyond the schema, as it only reiterates the resource ID aspect without providing additional context (e.g., format examples, common patterns, or when deviceSerial is needed). With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the action ('clear text') and target ('from a UI element by resource ID'), making the purpose immediately understandable. It distinguishes itself from sibling tools like android_uiautomator_set_text (which sets text) and android_input_text (which inputs text generally). However, it doesn't specify what type of UI element (e.g., text field, edit box) or clarify that it's specifically for Android UI automation, though context from sibling names helps.

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

  Usage Guidelines2/5

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

  No explicit guidance is provided on when to use this tool versus alternatives. While the description implies it's for clearing text from UI elements identified by resource ID, it doesn't mention prerequisites (e.g., the element must be interactable), exclusions (e.g., not for non-text elements), or compare it to similar tools like android_uiautomator_set_text (which could clear by setting empty text). Usage is implied but not clearly defined.

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

• android_uiautomator_clickC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'using UIAutomator' but doesn't disclose behavioral traits such as error handling (e.g., if element not found), performance implications (e.g., waiting times), or side effects (e.g., potential app state changes). For a UI interaction tool with zero annotation coverage, this is a significant gap in transparency.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action ('Click on a UI element') and method ('using UIAutomator'), with zero wasted words. It's appropriately sized for a straightforward tool.

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

  Completeness2/5

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

  Given the complexity of UI automation (interactive, state-dependent) with no annotations and no output schema, the description is incomplete. It lacks details on success/failure outcomes, error conditions, dependencies (e.g., UIAutomator setup), or behavioral nuances, leaving significant gaps for an AI agent to use it correctly.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear descriptions for both parameters in the schema itself. The description adds no additional meaning beyond what's in the schema (e.g., it doesn't explain format constraints or provide examples beyond the schema's example). Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Click on a UI element') and the method ('using UIAutomator'), with the resource ID as the targeting mechanism. It distinguishes from generic 'android_touch' by specifying UIAutomator-based clicking, but doesn't explicitly differentiate from 'android_uiautomator_double_click' or 'android_uiautomator_long_click' beyond the basic click action.

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

  Usage Guidelines2/5

  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 like 'android_touch' (general touch), 'android_uiautomator_double_click', or 'android_uiautomator_long_click'. The description implies usage for clicking by resource ID with UIAutomator, but lacks explicit context about prerequisites (e.g., device accessibility enabled) or comparative scenarios.

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

• android_uiautomator_double_clickC
  2.9/5.0
  Behavior2/5

  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 mentions the action (double click) but lacks critical behavioral details: whether this requires prior UI element interaction, what happens on failure (e.g., if element not found), if it blocks until completion, or error conditions. For a UI automation tool with zero annotation coverage, this 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.

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It is front-loaded with the core action and target, making it easy to parse quickly.

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

  Completeness2/5

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

  Given the complexity of UI automation, no annotations, and no output schema, the description is incomplete. It misses behavioral context (e.g., success/failure states, dependencies), usage prerequisites, and error handling, which are crucial for effective tool invocation in this domain.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents both parameters (resourceId and deviceSerial). The description adds no additional meaning beyond implying resourceId targets a UI element, which is already clear from the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

  Purpose4/5

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

  The description clearly states the action ('Perform a double click') and target ('on a UI element by resource ID'), which is specific and unambiguous. It distinguishes from sibling tools like android_uiautomator_click (single click) and android_uiautomator_long_click, but does not explicitly mention these alternatives in the description itself.

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

  Usage Guidelines2/5

  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 android_uiautomator_click or android_touch, nor does it mention prerequisites (e.g., needing an active Android session or UI element visibility). It only states what the tool does, not when to apply it.

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

• android_uiautomator_findC
  2.9/5.0
  Behavior2/5

  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 mentions the search mechanism (UIAutomator) but lacks critical details: whether this is a read-only operation, if it requires device permissions, how it handles multiple matching elements, error conditions (e.g., no matches), or performance implications. For a tool with potential side effects or constraints, 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.

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Find UI elements') and includes key details (search criteria and mechanism). There is no redundant information or unnecessary elaboration, making it highly concise and well-structured for quick understanding.

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

  Completeness2/5

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

  Given the complexity of UI automation, no annotations, and no output schema, the description is incomplete. It doesn't explain return values (e.g., element identifiers or error messages), behavioral traits like idempotency or side effects, or integration with sibling tools (e.g., how found elements might be used with android_uiautomator_click). For a tool in a rich sibling set, more context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, with clear parameter descriptions in the input schema. The description adds minimal value by naming the search criteria ('resource ID or text') but doesn't elaborate on syntax, precedence (if both parameters are provided), or practical examples beyond what the schema provides. With high schema coverage, 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.

  Purpose4/5

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

  The description clearly states the action ('Find UI elements') and the mechanism ('using UIAutomator'), with specific search criteria ('by resource ID or text'). It distinguishes itself from sibling tools like android_uiautomator_click or android_uiautomator_set_text by focusing on element discovery rather than interaction. However, it doesn't explicitly differentiate from android_uiautomator_dump, which might also involve element discovery, making it slightly less specific.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites (e.g., needing an active device connection), compare it to sibling tools like android_uiautomator_dump for broader element discovery, or specify scenarios where resource ID vs. text searching is preferred. Usage is implied but not explicitly stated.

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

• android_uiautomator_scroll_in_elementC
  2.9/5.0
  Behavior2/5

  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 lacks details on permissions needed, whether it's destructive (e.g., could cause unintended UI changes), error handling, or performance implications. This is inadequate for a tool with potential side effects.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core functionality ('Scroll within a specific UI element') with zero wasted words. It's appropriately sized for the tool's complexity.

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

  Completeness2/5

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

  Given no annotations and no output schema, the description is incomplete. It lacks behavioral context (e.g., safety, side effects) and doesn't explain return values or errors. For a UI automation tool with potential mutations, this leaves significant gaps for an AI agent.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional meaning beyond what's in the schema, such as explaining 'resourceId' as a UI element identifier or 'distance' in practical terms. Baseline 3 is appropriate as the schema handles parameter documentation.

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

  Purpose4/5

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

  The description clearly states the action ('Scroll') and target ('within a specific UI element'), providing a specific verb+resource combination. It distinguishes from sibling tools like 'android_swipe' (general swipe) by specifying scrolling within an element, though it doesn't explicitly contrast with all siblings.

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

  Usage Guidelines2/5

  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 like 'android_swipe' for general scrolling or other UI automation tools. The description implies usage for scrolling within elements but offers no explicit context, prerequisites, or exclusions.

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

• android_uiautomator_toggle_checkboxC
  2.9/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. While 'toggle' implies a state change (mutating the checkbox), the description doesn't disclose behavioral traits like whether this requires specific permissions, what happens if the element isn't found, if it waits for UI stability, or what the expected outcome is. It's minimally descriptive for a mutation operation.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a simple tool and front-loads the core functionality immediately.

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

  Completeness2/5

  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 insufficient. It doesn't explain what 'toggle' means in practice (e.g., checks if unchecked, unchecks if checked), error conditions, or return values. Given the complexity of UI automation and lack of structured data, more context is needed.

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

  Parameters3/5

  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 parameters (resourceId and deviceSerial) adequately. The description doesn't add any meaningful parameter semantics beyond what's in the schema, such as format examples or constraints, meeting the baseline for high schema coverage.

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

  Purpose4/5

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

  The description clearly states the action ('toggle') and target ('checkbox element by resource ID'), providing a specific verb+resource combination. However, it doesn't distinguish this tool from similar sibling tools like android_uiautomator_click or android_uiautomator_double_click that might also interact with UI elements.

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

  Usage Guidelines2/5

  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's no mention of prerequisites (e.g., needing an active Android session), when not to use it, or how it differs from other UI interaction tools in the sibling list.

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

• android_uiautomator_waitC
  2.9/5.0
  Behavior2/5

  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 states the tool waits for an element to appear, implying a blocking operation with a timeout, but doesn't disclose behavioral details like what happens on timeout (e.g., returns error or null), whether it polls continuously, or if it requires specific device states. For a tool with no annotations, 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.

  Conciseness5/5

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

  The description is a single, efficient sentence: 'Wait for a UI element to appear by resource ID.' It's front-loaded with the core action and resource, with zero wasted words. Every part of the sentence contributes directly to understanding the tool's purpose.

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

  Completeness2/5

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

  Given no annotations, no output schema, and a tool that performs a potentially complex waiting operation, the description is incomplete. It doesn't explain return values (e.g., success/failure, element details), error conditions, or dependencies like device connectivity. For a 3-parameter tool with behavioral implications, more context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents the three parameters (resourceId, timeoutMs, deviceSerial). The description adds no additional meaning beyond implying resourceId is the key input. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't enhance parameter understanding.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Wait for a UI element to appear by resource ID.' It specifies the verb ('wait') and resource ('UI element'), but doesn't explicitly differentiate from siblings like android_uiautomator_find, which might also locate elements. The description is specific but lacks sibling comparison.

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

  Usage Guidelines2/5

  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. It doesn't mention prerequisites, such as needing an active Android device connection, or compare it to siblings like android_uiautomator_find for immediate element retrieval. Usage context is implied but not explicit.

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

• android_send_key_eventB
  3.1/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but lacks behavioral details. It doesn't disclose effects (e.g., whether it simulates physical key presses, requires device connectivity, or has rate limits), leaving the agent to infer behavior from the action 'Send'.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose and provides relevant examples without unnecessary elaboration. Every word contributes to understanding the tool's function.

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

  Completeness3/5

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

  For a tool with 2 parameters, 100% schema coverage, and no output schema, the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits (e.g., device state requirements or error handling), which are important given the absence of annotations.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents keyCode and deviceSerial parameters. The description adds minimal value by listing example key codes (KEYEVENT_HOME, KEYEVENT_BACK, KEYEVENT_ENTER), which aligns with but doesn't significantly expand on schema details.

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

  Purpose4/5

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

  The description clearly states the action ('Send a key event') and target ('Android device'), with examples like KEYEVENT_HOME and KEYEVENT_BACK. It distinguishes from siblings like android_input_text (for text) and android_touch (for touch gestures), but doesn't explicitly contrast them.

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

  Usage Guidelines2/5

  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 is provided. For example, it doesn't specify when to use android_send_key_event over android_input_text for Enter key events or android_touch for navigation, leaving usage context implied rather than explicit.

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

• android_execute_commandB
  3.2/5.0
  Behavior2/5

  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 mentions executing commands but lacks details on behavioral traits like permissions required, error handling, safety risks (e.g., destructive commands), or output format. This is a significant gap for a tool that could perform arbitrary operations.

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

  Conciseness5/5

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

  The description is front-loaded and concise, with two sentences that directly state the purpose and flexibility. Every sentence earns its place by clarifying the tool's role without unnecessary elaboration, making it efficient for quick understanding.

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

  Completeness2/5

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

  Given the complexity of executing arbitrary ADB commands, no annotations, and no output schema, the description is incomplete. It doesn't address critical aspects like command safety, expected outputs, or integration with sibling tools, leaving gaps that could hinder effective agent use.

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

  Parameters3/5

  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 parameters thoroughly. The description adds no additional meaning beyond stating it's for 'custom arguments,' which aligns with the schema but doesn't provide extra context like common use cases or constraints. Baseline 3 is appropriate here.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Execute a generic ADB command with custom arguments.' It specifies the verb ('Execute') and resource ('ADB command'), distinguishing it from sibling tools that perform specific actions like screenshot or input. However, it doesn't explicitly differentiate from all siblings, as some might also involve ADB commands indirectly.

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

  Usage Guidelines3/5

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

  The description implies usage by stating it 'Allows agents to run any ADB command with their own parameters,' suggesting it's for custom or unsupported commands. It doesn't provide explicit when-to-use vs. alternatives, such as preferring specific sibling tools for common tasks, leaving usage context somewhat implied.

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

• android_start_scrcpy_streamB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only mentions the scrcpy installation prerequisite. It doesn't disclose whether this starts a background process, consumes resources, requires specific permissions, has rate limits, or how to access the streamed frames. For a streaming tool with zero annotation coverage, this leaves significant behavioral gaps.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose and includes a crucial prerequisite. Every word earns its place with no wasted text.

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

  Completeness2/5

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

  For a streaming tool with no annotations and no output schema, the description is insufficient. It doesn't explain what 'continuous fast frame capture' means operationally, how frames are accessed, whether the stream persists across tool calls, or what happens if scrcpy isn't installed. Given the complexity and lack of structured data, more context is needed.

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

  Parameters3/5

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

  Schema description coverage is 100% with one optional parameter clearly documented in the schema. The description adds no parameter information beyond what the schema provides, so it meets the baseline for high schema coverage but doesn't add extra value.

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

  Purpose4/5

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

  The description clearly states the action ('Start scrcpy streaming') and purpose ('for continuous fast frame capture'), which distinguishes it from single-frame capture tools like android_capture_frame_scrcpy or android_screenshot. However, it doesn't explicitly differentiate from android_stop_scrcpy_stream beyond the obvious start/stop distinction.

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

  Usage Guidelines3/5

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

  The description implies usage when continuous frame capture is needed versus single-frame alternatives, but doesn't explicitly state when to use this tool versus android_capture_frame_scrcpy or android_get_latest_frame. The prerequisite 'requires scrcpy installed' provides some context but no explicit when-not-to-use guidance.

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

• android_stop_scrcpy_streamB
  3.2/5.0
  Behavior2/5

  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 ('Stop') but doesn't explain what happens when invoked (e.g., whether it terminates an active stream gracefully, frees resources, or has side effects). This is a significant gap for a tool that likely involves resource management.

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

  Conciseness5/5

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

  The description is extremely concise with just three words, front-loading the essential action. There's no wasted text, making it efficient and easy to parse, which is ideal for a simple tool with no parameters.

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

  Completeness3/5

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

  Given the tool's simplicity (0 parameters, no output schema, no annotations), the description is minimally adequate but lacks completeness. It doesn't address behavioral aspects like what 'Stop' entails or dependencies on other tools, leaving gaps that could confuse an agent about proper usage.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter information, which is appropriate here, earning a baseline score of 4 for not introducing unnecessary details.

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

  Purpose4/5

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

  The description clearly states the verb ('Stop') and resource ('scrcpy streaming'), making the purpose immediately understandable. It doesn't explicitly differentiate from sibling tools like 'android_start_scrcpy_stream', but the action is specific enough to infer it's the counterpart to starting the stream.

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

  Usage Guidelines2/5

  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 or any prerequisites. It doesn't mention that it should be used after starting a stream with 'android_start_scrcpy_stream' or warn against using it if no stream is active, leaving usage context unclear.

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

• android_uiautomator_dumpB
  3.2/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden but only states the basic action and output format. It doesn't disclose behavioral traits such as whether this requires device connectivity, potential performance impacts, error conditions, or if it's read-only (implied by 'Dump' but not explicit). More context on operational constraints is needed.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the key information: action, method, and output. There is no wasted text, making it easy to parse quickly for an AI agent.

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

  Completeness3/5

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

  Given the tool's moderate complexity (UI hierarchy dumping) and lack of annotations and output schema, the description is minimally adequate. It specifies the output as XML but doesn't explain the structure or content of the XML, which could be crucial for an agent to interpret results. More details on behavior or output would improve completeness.

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

  Parameters4/5

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

  Schema description coverage is 100%, so the parameter 'deviceSerial' is well-documented in the schema. The description doesn't add extra param details, which is acceptable given high schema coverage. With only one optional parameter, the baseline is high, and the description doesn't detract from schema clarity.

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

  Purpose4/5

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

  The description clearly states the action ('Dump') and resource ('UI hierarchy using UIAutomator'), specifying the output format ('return as XML'). It distinguishes from siblings like android_screenshot or android_capture_frame_scrcpy by focusing on UI hierarchy extraction rather than visual capture, though it doesn't explicitly contrast with android_uiautomator_find which might also interact with UI hierarchy.

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

  Usage Guidelines2/5

  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. For example, it doesn't mention if this is for debugging, automation setup, or when android_uiautomator_find might be preferred for specific element interactions. The description lacks context about prerequisites or typical use cases.

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

• android_uiautomator_set_textB
  3.2/5.0
  Behavior2/5

  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 mentions the method ('using UIAutomator') but doesn't cover critical aspects like whether this requires device interaction permissions, potential side effects (e.g., overwriting existing text), error handling, or performance implications. This leaves significant gaps 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.

  Conciseness5/5

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

  The description is a single, direct sentence that efficiently conveys the core functionality without unnecessary words. It's front-loaded with the key action ('Set text') and includes essential context ('by resource ID using UIAutomator'), making it highly concise and well-structured.

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

  Completeness2/5

  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 insufficient. It lacks details on behavioral traits (e.g., permissions, side effects), error conditions, or return values, which are critical for safe and effective tool invocation in an Android automation context.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema fully documents all three parameters (resourceId, text, deviceSerial). The description adds no additional parameter semantics beyond what's in the schema, such as examples or constraints. Baseline 3 is appropriate when the schema handles parameter documentation effectively.

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

  Purpose4/5

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

  The description clearly states the action ('Set text') and target ('on a UI element by resource ID using UIAutomator'), distinguishing it from generic text input tools like 'android_input_text'. However, it doesn't explicitly differentiate from sibling UIAutomator tools like 'android_uiautomator_clear_text' in terms of specific use cases.

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

  Usage Guidelines3/5

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

  The description implies usage for setting text on UI elements identified by resource ID, which suggests it's for targeted text input in Android apps. However, it lacks explicit guidance on when to use this vs. alternatives like 'android_input_text' (for general text) or 'android_uiautomator_clear_text' (for clearing text), leaving the agent to infer based on context.

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

• android_capture_frame_scrcpyB
  3.3/5.0
  Behavior2/5

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

  No annotations are provided, so the description carries full burden. It mentions 'faster than ADB screencap', which adds useful context about performance, but it doesn't disclose other behavioral traits such as whether it requires scrcpy to be running, what happens if no device is connected, or if it has any rate limits. For a tool with no annotations, this leaves significant gaps in understanding its behavior.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Capture a single frame via scrcpy') and adds a key benefit ('faster than ADB screencap'). There is no wasted text, and it's appropriately sized for the tool's complexity.

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

  Completeness3/5

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

  Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is minimal but adequate. It covers the basic purpose and a performance advantage, but for a tool that interacts with devices and saves files, it lacks details on error handling, prerequisites (e.g., scrcpy setup), or return values. It's complete enough for a simple tool but has clear gaps in context.

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

  Parameters3/5

  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 parameters (outputPath and deviceSerial) with descriptions. The description adds no additional parameter information beyond what's in the schema, such as format details or examples. With high schema coverage, the baseline is 3, as the description doesn't compensate but also doesn't detract.

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

  Purpose4/5

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

  The description clearly states the tool's purpose: 'Capture a single frame via scrcpy' specifies the action (capture) and resource (frame), and it distinguishes from siblings by mentioning 'faster than ADB screencap', which differentiates it from android_screenshot. However, it doesn't explicitly name the sibling android_screenshot as an alternative, so it's not a perfect 5.

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

  Usage Guidelines3/5

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

  The description implies usage by stating 'faster than ADB screencap', suggesting this tool is preferred for speed over alternatives like android_screenshot. However, it doesn't explicitly state when to use this vs. other frame-capturing tools (e.g., android_get_latest_frame) or provide clear exclusions, so guidance is implied but not comprehensive.

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

• android_get_latest_frameB
  3.3/5.0
  Behavior2/5

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

  With no annotations, the description carries full burden but only mentions 'instant access, no latency'. It omits critical behavioral details: whether this is read-only or modifies state, potential errors if the stream isn't running, return format (e.g., image data), or performance implications like memory usage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core purpose ('Get the latest frame') and adds qualifying context ('instant access, no latency'). Every word earns its place with no redundancy or fluff.

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

  Completeness2/5

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

  Given the complexity of accessing a live stream and no annotations or output schema, the description is incomplete. It fails to explain prerequisites (e.g., stream must be active), error conditions, or return value format, leaving significant gaps for safe and effective tool invocation.

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

  Parameters4/5

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

  The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, focusing on tool behavior instead, which aligns with the baseline for zero parameters.

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

  Purpose4/5

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

  The description clearly states the action ('Get') and resource ('latest frame from scrcpy stream'), specifying it provides 'instant access, no latency'. It distinguishes from sibling 'android_capture_frame_scrcpy' by emphasizing immediacy versus potential capture delay, though not explicitly naming the alternative.

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

  Usage Guidelines3/5

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

  The description implies usage when low-latency frame access is needed from an active scrcpy stream, as suggested by 'instant access, no latency'. However, it lacks explicit guidance on prerequisites (e.g., requiring 'android_start_scrcpy_stream' first) or clear alternatives like 'android_screenshot' for non-stream contexts.

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

• android_input_textA
  3.6/5.0
  Behavior2/5

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

  With no annotations provided, the description carries full burden for behavioral disclosure. While it mentions the action and method (ADB), it lacks critical behavioral details such as whether this requires device accessibility permissions, what happens if no field is focused, error conditions, or performance characteristics. The description is minimal and doesn't adequately cover behavioral traits.

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

  Conciseness5/5

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

  The description is a single, efficient sentence with zero wasted words. It's front-loaded with the core purpose and includes essential context about the method (ADB). Every element of the description serves a clear purpose.

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

  Completeness2/5

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

  For a device interaction tool with no annotations and no output schema, the description is insufficient. It doesn't explain what happens on success/failure, return values, error conditions, or prerequisites (like needing ADB setup or device accessibility enabled). The description leaves too many operational questions unanswered.

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

  Parameters3/5

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

  Schema description coverage is 100%, so the schema already fully documents both parameters. The description doesn't add any parameter-specific information beyond what's in the schema (e.g., it doesn't explain text encoding, special character handling, or device selection logic). Baseline 3 is appropriate when schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('Input text'), target resource ('currently focused field on the Android device'), and method ('via ADB'). It distinguishes itself from sibling tools like android_uiautomator_set_text by specifying it works on the currently focused field rather than requiring UI element targeting.

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

  Usage Guidelines4/5

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

  The description implies usage context ('currently focused field') which suggests when to use this tool versus alternatives like android_uiautomator_set_text that require element identification. However, it doesn't explicitly state when NOT to use it or name specific alternative tools, leaving some ambiguity about tool selection.

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

• android_uiautomator_long_clickA
  3.6/5.0
  Behavior2/5

  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 mentions the action ('long click') but lacks details on behavioral traits such as duration of the long click, error handling if the element isn't found, whether it requires the app to be in the foreground, or any side effects like UI changes. This is a significant gap for a mutation tool with zero annotation coverage.

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

  Conciseness5/5

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

  The description is a single, efficient sentence that front-loads the core action ('Perform a long click') and specifies the target ('UI element by resource ID'). There is no wasted verbiage, making it highly concise and well-structured for quick understanding.

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

  Completeness2/5

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

  Given this is a mutation tool with no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It doesn't cover key aspects like what constitutes a 'long click' (e.g., duration), error scenarios, or expected outcomes, leaving gaps that could hinder correct agent usage.

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

  Parameters3/5

  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 parameters (resourceId and deviceSerial). The description adds minimal value beyond the schema by implying resourceId is used for targeting the element, but it doesn't provide additional context like format examples or usage tips. Baseline 3 is appropriate when the schema does the heavy lifting.

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

  Purpose5/5

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

  The description clearly states the specific action ('Perform a long click') on a specific resource ('UI element by resource ID'), distinguishing it from siblings like android_uiautomator_click (regular click) and android_uiautomator_double_click. It uses precise verb+resource language without being tautological.

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

  Usage Guidelines4/5

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

  The description implies usage context by specifying 'UI element by resource ID,' suggesting it's for interacting with Android UI elements identified by IDs. However, it doesn't explicitly state when to use this versus alternatives like android_touch or android_uiautomator_click, nor does it mention prerequisites like needing UI visibility or device connection.

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