Server Quality Checklist

Tool Scores

• android_doctorA
  4.4/5.0
  Behavior5/5

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

  Given annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, the description adds substantial behavioral detail: it enumerates the components verified (adb, SDK, JDK, devices, Gradle wrapper), explains the specific JDK mismatch it catches, and describes error handling (reports missing adb with guidance rather than throwing). No contradictions with annotations.

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

  Conciseness4/5

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

  The description is longer than average but well-structured with clear sections (overview, args, returns, examples, error handling). The opening sentence is immediately informative. Minor redundancy exists between the 'Run this first' guidance and the later 'Use when' examples, but all sections serve a purpose.

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

  Completeness5/5

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

  For a multi-check diagnostic tool with no output schema, the description is thorough: it explains what is checked, when to use it, the return object structure with example entries, and error behavior. It even names a specific failure mode ('Unsupported class file major version'). This gives an agent everything needed to invoke and interpret the tool 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 coverage is 100%, so the baseline is 3. The description's 'Args' section largely restates the schema's parameter descriptions (e.g., project_path as 'Gradle root to include in the checks'), adding little new meaning. It does not explain parameter interactions or edge cases beyond what the schema already provides.

  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 opens with a specific action ('Check that the Android toolchain is usable') and a clear deliverable ('report exactly what is wrong'). It distinguishes itself from sibling tools by positioning itself as the first diagnostic step when build or device commands fail.

  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 provides strong contextual guidance: 'Run this first when a build or device command fails for a reason that is not obviously in the app's own code' and gives three concrete 'Use when' examples. It lacks explicit when-not-to-use or alternative tool names, but the context is clear enough to guide selection.

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

• android_pitfallsA
  4.4/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is known. The description adds useful behavioral context beyond annotations, such as the meaning of an empty result ('returns an empty list when nothing matches; that means the problem is not a known environment trap') and the return structure, which is not present in the output schema.

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

  Conciseness4/5

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

  The description is well-structured with clear sections for arguments, returns, examples, and error handling. It is appropriately sized for a search tool with multiple filters and does not waste words, though the examples section could be slightly condensed without loss of meaning.

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

  Completeness5/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 and the absence of an output schema, the description fully covers the return format, the filter semantics, and the empty-result behavior. It also sets clear expectations about the curated nature of the data, making the tool complete and self-contained for an agent to use confidently alongside 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?

  The input schema already provides 100% coverage of all four parameters, so the description's parameter prose is supplemental rather than essential. The description adds helpful examples and clarifications (e.g., 'error_text' matches against known signatures), but it omits the valid topic value 'host-bridge' that appears in the schema enum, introducing a minor inconsistency. This limits the added value to a baseline level.

  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 opens with a specific verb and resource: 'Search a curated set of Android development failure modes whose symptoms point nowhere near their causes.' This clearly distinguishes the tool from sibling operational tools like android_build or android_logcat, which perform actions rather than provide knowledge.

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

  Usage Guidelines5/5

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

  The description provides explicit guidance on when to use: 'Consult this when something fails in a way that does not make sense, before spending time bisecting the app's own code.' It also gives concrete examples ('Use when: a build failed with unfamiliar output') and an exclusion ('Don't use when: the error is plainly in the app's own code'), offering clear alternatives and boundary conditions.

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

• android_buildA
  4.6/5.0
  Behavior5/5

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

  Discloses important behaviors beyond annotations: JDK auto-selection, refusal when Gradle/JDK mismatch occurs, log condensing on failure, first-build download delays, and recognized error handling for SDK and install failures. No contradiction with annotations (readOnlyHint=false is expected for a build/install tool).

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

  Conciseness4/5

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

  The description is well-structured with sections for purpose, details, args, returns, examples, and error handling. The Args section is redundant with the input schema and adds length without much value, but the rest is concise and front-loaded.

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

  Completeness5/5

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

  Even without an output schema, the description provides a full return object, concrete examples, error handling guidance, and toolchain context. It covers the tool's complexity comprehensively, including first-build delays and JDK mismatch behavior.

  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 coverage is 100%, so baseline is 3. The description's Args section mostly repeats the schema verbatim and omits the 'force' parameter entirely, which is a notable gap. It adds little meaning beyond what the schema already provides (e.g., 'implies install' is also in the schema).

  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 opens with a specific verb and resource: 'Run a Gradle assemble for an Android project and, when asked, install the APK and start it on a device.' It clearly distinguishes itself from siblings through the exclusions note ('Don't use when... use android_install') and the overall edit-run loop framing.

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

  Usage Guidelines5/5

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

  Explicit 'Use when' and 'Don't use when' guidance is provided, naming android_install as the alternative for already-built APKs. Also gives concrete scenarios: 'build and run this app on my phone' vs 'verifying a code change compiles.'

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

• android_key_eventA
  4.6/5.0
  Behavior4/5

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

  Annotations declare readOnlyHint=false and destructiveHint=false, and the description aligns by describing a send operation. It adds behavioral nuances beyond annotations: POWER toggles and can turn the screen back off, repeat value bounds (1-20), and rejection of unrecognized keys with a supported-key list. This gives the agent useful behavioral expectations without overstepping.

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

  Conciseness4/5

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

  The description is well-structured with sections: main purpose, Args, Returns, Examples, Error Handling. It is front-loaded and each section serves a purpose. The key list duplicates the schema enum, which is somewhat redundant, but the examples and error handling make the extra length worthwhile.

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

  Completeness5/5

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

  The tool has moderate complexity with 3 parameters, but the schema covers all parameters. Annotations provide safety profile. The description adds practical usage guidance, return format (even though no output schema), and error handling. It completely covers what an agent needs to decide when and how to invoke this tool.

  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 coverage is 100% and each parameter already has a description. The description's Args section restates the key list and repeat bounds but adds semantic value through the Use-when examples that tie specific keys to actions. It also clarifies serial's role minimally, though the schema provides richer context (device from android_list_devices, required when multiple). Overall, it adds moderate value beyond the schema.

  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 opens with a specific verb+object: 'Send a key event', and the title clarifies 'hardware or system key'. It explicitly lists the key categories (Back, Home, Enter, arrows, volume) and differentiates from android_input_text by stating the don't-use case. This strongly distinguishes it from siblings.

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

  Usage Guidelines5/5

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

  The description includes explicit 'Use when:' examples mapping scenarios to keys (e.g., navigating back -> BACK, screen off -> WAKEUP) and a clear 'Don't use when: typing characters (use android_input_text)', providing an alternative. It also notes error handling for unrecognized keys, giving clear context.

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

• android_launchA
  4.8/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses error behavior: it reports when the package is not installed and cannot start apps without a launcher activity. It also clarifies the effect of force_stop (guaranteeing a cold start). These are useful behavioral traits not captured in the annotations.

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

  Conciseness4/5

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

  The description is well-structured with sections for arguments, return value, examples, and error handling. It is longer than minimal but each section adds necessary information. The redundant parameter list mirrors the schema, but the added usage examples justify the length.

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

  Completeness5/5

  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, the description includes the return type and shape, error cases, and distinct usage examples. It covers the parameter semantics and edge cases (app not installed, no launcher activity) making it self-sufficient for an agent.

  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 already describes all parameters (100% coverage). The description adds value by explaining the relationship between project_path and package_name (when one can be omitted) and giving a concrete example for package_name. This extra context slightly elevates it above the baseline of 3.

  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 states 'Start an installed app's launcher activity' which is a specific verb+resource, clearly distinguishing it from sibling tools like android_install (install) and android_screenshot (capture screen). It also notes the optional force-stop capability, further clarifying scope.

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

  Usage Guidelines5/5

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

  Explicit 'Use when' and 'Don't use when' examples are provided, including a specific alternative (use android_install if not installed) and a use case for force_stop to reproduce a launch-time bug. This gives clear direction on when to choose this tool over siblings.

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

• android_tapA
  4.8/5.0
  Behavior5/5

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

  Annotations state readOnlyHint=false, destructiveHint=false, openWorldHint=true, and idempotentHint=false, but the description adds critical behavioral details: 'Coordinates outside the screen are silently ignored by Android' and 'verify with android_dump_ui afterwards.' It also explains the effect of long_press and duration. No contradiction with annotations.

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

  Conciseness4/5

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

  The description is well-structured with sections for Args, Returns, Examples, and Error Handling. It is concise and each section earns its place, though the Args section partially repeats schema information. Overall, it's efficient and easy to parse.

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

  Completeness5/5

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

  For a tool with 5 parameters and no output schema, the description fully covers return format, usage examples, prerequisite steps (android_dump_ui), and error handling. It leaves no significant gaps for an agent to successfully invoke the tool.

  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 covers 100% of parameters, so baseline is 3, but the description adds valuable meaning beyond the schema: coordinates are in 'device pixels' and 'depend on the current rotation,' and android_dump_ui returns 'ready-to-use centre point' for elements. This helps the agent choose correct coordinate values, going slightly beyond the schema's basic descriptions.

  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 begins with 'Tap at a screen coordinate,' using a specific verb and resource that clearly defines the action. It distinguishes itself from sibling tools like android_swipe (swipe) and android_dump_ui (reading UI) by focusing on the tap action and coordinate input.

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance: 'Get coordinates from android_dump_ui' and examples like 'Use when: opening a context menu -> long_press=true' and 'Don't use when: you do not know where the element is.' It also warns about re-reading UI after rotation, offering clear context and exclusions.

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

• android_clear_dataA
  4.9/5.0
  Behavior5/5

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

  Beyond the destructiveHint=true annotation, the description spells out exactly what gets destroyed (databases, preferences, cached files, signed-in sessions), notes that the app is force-stopped as a side effect, and mentions error reporting for missing packages. This gives the agent actionable safety and side-effect knowledge that structured annotations alone do not convey.

  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 well-organized into Args, Returns, Examples, and Error Handling sections, with the core purpose stated in the first sentence. Every section contributes practical information without redundancy or filler.

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

  Completeness5/5

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

  Although there is no output schema, the description provides the return shape ({ cleared, packageName, serial }), error handling behavior, and concrete use cases. For a destructive, state-changing tool, this level of context makes it nearly self-contained for an agent.

  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%, but the description's Args section adds a key semantic: project_path is used to resolve the package when package_name is omitted. It also restates the module default and serial's device-targeting role, which provides relational meaning beyond the raw schema.

  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 opens with 'Wipe an app's data and cache while leaving it installed,' which is a specific verb+resource with clear scope. It also explicitly contrasts with android_uninstall, stating that the app and its install stay put, which definitively distinguishes it from a sibling tool.

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

  Usage Guidelines5/5

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

  The description gives direct usage context: 'Use this to get back to a first-run state without uninstalling,' then provides explicit 'Use when' and 'Don't use when' examples. It names the alternative android_uninstall, satisfying both when-to-use and 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_connect_wifiA
  4.9/5.0
  Behavior5/5

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

  The description discloses significant behavioral context beyond annotations: the need for same-network connectivity, the USB requirement for promotion, the fact that a rebooted device loses TCP/IP mode, and error messages. Annotations (readOnly=false, idempotent=true, destructive=false) are consistent, and the description adds meaningful details about side effects and failure modes.

  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 well-structured with clear sections: purpose, modes, arguments, return value, usage examples, and error handling. Despite its length, every sentence contributes value, and the front-loaded first sentence immediately conveys the tool's purpose. The structure improves scannability and comprehension.

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

  Completeness5/5

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

  The description is comprehensive for a tool with no output schema. It explains return values explicitly ('Returns: { serial, host, port, alreadyConnected }'), covers both usage modes, and provides error-handling guidance. Combined with the rich schema and annotations, the agent has all necessary context to invoke the tool correctly.

  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?

  Although schema description coverage is 100%, the description enriches parameter semantics with examples (e.g., '192.168.0.12' or '192.168.0.12:5555'), default port value, and the relationship between 'host' and mode selection. It adds practical meaning beyond the schema's formal definitions, so a score above baseline is warranted, though not a 5 since the schema already covers the basic meaning.

  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 tool's function: 'Switch a USB-connected device to wireless adb, or reconnect to one that was paired before.' It specifies the verb (connect/switch) and resource (device over Wi-Fi) and distinguishes itself from siblings like android_list_devices by focusing on wireless connection setup.

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

  Usage Guidelines5/5

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

  The description provides explicit 'Use when' and 'Don't use when' guidance, including an alternative tool: 'Don't use when: you only need to know what is connected (use android_list_devices).' It also explains the two modes (with/without host) and network prerequisites, making the tool's context of use very clear.

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

• android_installA
  4.9/5.0
  Behavior5/5

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

  The description adds significant behavioral context beyond annotations: it replaces existing copies, details three common error codes with remedies, and clarifies that grant_permissions uses adb install -g. Annotations already indicate readOnlyHint=false and idempotentHint=true, and the description does not contradict them.

  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 well-organized into Args, Returns, Examples, and Error Handling sections. It is detailed but every sentence earns its place; no fluff or repetition of schema fields, as it adds usage context instead.

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

  Completeness5/5

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

  Despite having no output schema, the description explicitly documents the return object with fields. It also covers error handling and prerequisites (e.g., release requires signing config). This makes it fully self-contained for an agent to invoke correctly.

  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 coverage is 100%, so baseline is 3. The description adds extra semantics by explaining that apk_path can be omitted to use the last build output of project_path, and provides usage examples that map parameters to real scenarios. This goes beyond the schema's basic field descriptions.

  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 first sentence clearly states the action: 'Install an APK onto a device, replacing any existing copy.' This distinguishes it from siblings like android_build (which compiles) and android_uninstall. The examples further reinforce the specific use cases for apk_path vs project_path.

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

  Usage Guidelines5/5

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

  The description contains explicit 'Use when' and 'Don't use when' examples, including a named alternative: 'Don't use when: you also need to compile first (use android_build with install=true)'. This gives clear situational guidance.

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

• android_set_rotationA
  4.9/5.0
  Behavior5/5

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

  The description discloses key behavioral traits beyond annotations: fixed rotation disables auto-rotate first, sensor might override, app manifest lockdown wins, and how to detect failure. This significantly expands on the annotation hints without contradicting them.

  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 well-structured with sections for Args, Returns, Examples, and Error Handling. Despite containing substantial detail, every sentence earns its place, and the structure makes it easy for an agent to scan.

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

  Completeness5/5

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

  Given no output schema, the description supplies a return shape, error handling clues, and practical examples. It covers the essential context needed to select and invoke the tool correctly, making it complete for a tool with only two parameters.

  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 coverage is 100%, so baseline is 3. The description adds value by explaining the behavioral meaning of orientation values (fixed vs auto) and the effect of auto-rotate override, which goes beyond the schema's dry enum listing. It reinforces but doesn't fully reinvent parameter semantics.

  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 tool's purpose: force a display into a specific orientation or restore accelerometer control. It distinguishes this from sibling Android tools by specifying both the action ('force') and the resource ('display').

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

  Usage Guidelines5/5

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

  Provides explicit 'Use when' and 'Don't use when' examples, including a concrete alternative ('change the manifest') for apps with fixed orientation. Also explains when to use 'auto' to restore normal behavior, giving clear situational context.

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

• android_shellA
  4.9/5.0
  Behavior5/5

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

  The description discloses key behavioral traits beyond annotations: argument passing semantics ('not interpreted by a host shell'), device shell behavior (redirection), error return behavior (device shell's error text verbatim), and root limitations. The destructiveHint annotation is complemented by warning that commands may need root and fail on production builds. No contradiction with annotations.

  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 well-structured with clear sections (purpose, arguments, returns, examples, error handling). Every sentence adds useful information. The examples are concise and instructive. The opening line immediately conveys the tool's purpose and scope without padding.

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

  Completeness5/5

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

  Given the tool's open-ended nature (arbitrary command execution), the description provides all necessary context: usage boundaries, examples, return value shape, error handling, and device-specific caveats. Although there is no output schema, the 'Returns' field covers the response structure. No gaps for a sophisticated agent.

  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 coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining why quoting is not a concern, giving concrete examples for each parameter (e.g., command=['dumpsys', 'battery']), and clarifying the optional serial semantics implicitly through context. This extra semantic enrichment justifies a 4.

  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 opens with a specific verb+resource: 'Run an arbitrary command on the device via adb shell'. It clearly scopes the tool as a catch-all for anything dedicated tools do not cover, and distinguishes it from siblings by explicitly naming alternatives (android_logcat, android_dump_ui, android_tap) and listing sample use cases (dumpsys, pm, settings, getprop).

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance ('one-off inspection', 'for anything the dedicated tools do not cover') and when-not-to-use guidance ('Prefer a dedicated tool when one exists'), with concrete examples under 'Don't use when'. It also provides four Use-when example commands, making the selection criteria actionable.

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

• android_swipeA
  4.9/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description adds valuable behavioral context: direction semantics ('To scroll a list down... swipe from a lower y to a higher one'), duration effects ('longer is a drag, shorter is a fling'), and error handling ('A swipe that is too fast to register... raise duration_ms'). This fully discloses observable behavior without contradicting annotations.

  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 with a one-sentence summary, then organized into clear sections (Args, Returns, Examples, Error Handling). Every sentence earns its place; no fluff. It is longer than minimal but appropriately structured for the tool's complexity.

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

  Completeness5/5

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

  Given the tool's gesture complexity, the description covers: the action, param semantics, return format ('Returns: { "from": ... }'), example usage, an explicit alternative, and error handling. No output schema exists, so the description correctly carries the return-value documentation.

  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 coverage is 100%, so the baseline is 3. The description adds meaning beyond the schema by explaining the direction semantics (y-axis movement), the nuance of duration (drag vs. fling), and a concrete example mapping parameters to use cases. It does not merely repeat the schema definitions.

  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 names a specific verb ('swipe') and resource action ('between two points'), and immediately clarifies its purpose with 'Used for scrolling, dismissing, and drag gestures.' It also distinguishes from the sibling `android_tap` explicitly, saying 'Don't use when: a single tap is enough (use android_tap).'

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use guidance with concrete examples: 'Use when: scrolling a list down -> x1=540, y1=1600, x2=540, y2=600' and 'Use when: dragging an item -> duration_ms=1000'. Also states a clear exclusion: 'Don't use when: a single tap is enough (use android_tap).'

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

• android_testA
  4.9/5.0
  Behavior5/5

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

  The description goes beyond annotations by disclosing output condensing, device requirements for instrumented tests, behavior when no test sources exist (success with up-to-date task), and the JDK/Gradle pre-check. All of these are non-obvious behaviors not captured in the annotations or schema. No contradiction exists.

  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 dense but well-organized: a purpose sentence, verification role, test kind explanation, Args list, Return type, usage examples, and error handling. Every section earns its place given the tool's complexity and 7 parameters. No filler or repetition.

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

  Completeness5/5

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

  Despite lacking an output schema, the description provides a full return structure JSON, covers error cases, explains the two test kinds, and mentions the pre-check. This is complete for the tool's complexity. The agent can act with confidence.

  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 schema already covers 100% of parameters with descriptions, so the baseline is 3. The description adds value by restating parameters in a compact Args list with additional context: examples for the tests filter, the meaning of project_path (contains gradlew), and the default module 'app'. This clarifies semantics beyond the schema, earning a 4.

  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 opens with a specific verb+resource: 'Run a Gradle project's tests and report which ones failed.' It clearly distinguishes itself from siblings by explicitly naming android_build as the alternative for compilation-only needs. The scope is unambiguous.

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

  Usage Guidelines5/5

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

  The 'Examples' section provides explicit 'Use when' conditions for both unit and instrumented tests, as well as a 'Don't use when' that names android_build. This gives the agent clear decision rules for tool selection, going well beyond generic hints.

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

• android_dump_uiA
  5/5.0
  Behavior5/5

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

  Beyond annotations (readOnlyHint=true, etc.), the description discloses default filtering (meaningful nodes only), error handling ('could not get idle state'), WebView limitations, and the exact return shape. This adds significant behavioral context without contradicting annotations.

  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 well-structured with clear sections (Args, Returns, Examples, Error Handling). Every sentence contributes meaningful information, and the purpose statement is front-loaded. No redundant content.

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

  Completeness5/5

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

  Given no output schema, the description provides a full return contract, error handling, and interaction with sibling tools. It covers all necessary context for an agent to decide when and how to invoke the tool.

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

  Parameters5/5

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

  Although schema coverage is 100%, the description enriches each parameter with practical usage (e.g., filter='submit') and clarifies the response_format options. It also explains how the output (center point) feeds into android_tap, adding value beyond the schema.

  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 opens with a specific verb and resource: 'Dump the current screen's view hierarchy as text, with tap coordinates for every element.' It clearly distinguishes from android_screenshot by explaining when a screenshot is preferred, 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.

  Usage Guidelines5/5

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

  The 'Use when' and 'Don't use when' sections give explicit context and name alternatives (e.g., android_screenshot for visual rendering). It also references android_tap for coordinates, showing how the tool fits into a workflow.

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

• android_input_textA
  5/5.0
  Behavior5/5

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

  Beyond the annotations, the description thoroughly discloses behavioral limitations inherited from Android's 'input text' command, including ASCII-only rejection, '%s' escaping, focus requirement, and text append behavior. It also explains error handling up front, adding substantial context beyond the readOnly/destructive hints.

  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?

  Although lengthy, every section earns its place: limitations, prerequisites, args, returns, examples, and error handling. The structure uses clear headers and bullet points, front-loading the core purpose and limitations before details. No redundancy or filler.

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

  Completeness5/5

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

  Covers all essential aspects for correct invocation: returns object, error cases, focus prerequisite, clearing behavior, and ASCII limitations. With no output schema, the description provides a full picture of what to expect. The examples tie usage to practical scenarios and sibling-tool context (android_tap).

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

  Parameters5/5

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

  Schema coverage is 100%, but the description enriches parameter meaning with crucial constraints: text is ASCII-only, submit implies pressing Enter, and serial is tied to android_list_devices. It also explains edge cases like '%s' and clearing the field first, which the schema does not capture.

  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 opens with 'Type text into the focused input field,' a specific verb+resource statement that clearly distinguishes this tool from siblings like android_tap and android_key_event. It also explicitly differentiates its scope by explaining what it does not do (non-ASCII, '%s').

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

  Usage Guidelines5/5

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

  Provides explicit when-to-use ('filling a login form', 'entering a search term and running it'), when-not-to-use ('Don't use when: the text contains non-ASCII characters'), and prerequisites ('Tap the field first (android_tap) so it has focus'). It even suggests alternatives for non-ASCII cases, exceeding typical guidance.

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

• android_list_devicesA
  5/5.0
  Behavior5/5

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

  Beyond the annotations (readOnlyHint=true, etc.), the description adds meaningful behavioral context: devices in 'unauthorized' or 'offline' states surface here, the tool returns an empty list rather than erroring when nothing is plugged in, and detailed mode costs an extra adb round trip. It also explains the significance of the 'unauthorized' state and on-screen prompt, enriching the agent's understanding without contradicting annotations.

  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 long but highly organized with clear sections (Description, Args, Returns, Examples, Error Handling). Every sentence serves a purpose: it explains core behavior, usage timing, parameter semantics, return shape, and failure modes. It is front-loaded with the most critical 'call this first' guidance, making it efficient for quick scanning.

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

  Completeness5/5

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

  The description is self-contained and comprehensive. It defines the return object structure even though no output schema exists, covers error handling (empty list, unauthorized state), and explains when to use the tool in the broader workflow. The annotations handle safety/profile, so the description covers all other needed context 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.

  Parameters5/5

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

  Schema coverage is 100%, but the description adds significant value beyond the schema. For 'detailed' it lists exactly which properties are queried (Android version, SDK level, screen size, density, rotation) and notes the performance cost. For 'response_format' it clarifies the human-readable vs machine-readable tradeoff. The Args section is rich and directly useful for parameter selection.

  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 opens with 'List every Android device and emulator currently visible to adb, with model, Android version and screen geometry,' a specific verb+resource+scope statement. It clearly distinguishes this tool from siblings by focusing on device enumeration and serial discovery, explicitly contrasting with tools like android_logcat.

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

  Usage Guidelines5/5

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

  The description gives explicit when-to-use guidance: 'Call this first in any session: other tools need a serial when more than one device is attached.' It also provides a when-not-to-use example with a named alternative: 'Don't use when: you already have a serial and just want app logs (use android_logcat).' This fully covers usage context and exclusions.

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

• android_logcatA
  5/5.0
  Behavior5/5

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

  Annotations provide readOnlyHint=true and destructiveHint=false, but the description goes well beyond: it clarifies the non-streaming snapshot behavior, explains that the crash buffer survives process death, and discloses that clear_only wipes the buffer. Error-handling notes about package filtering requiring a live process add important behavioral context not present in annotations.

  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 organized into clear sections (Intro, Args, Returns, Examples, Error Handling), front-loaded with the core behavior, and every sentence provides practical value. It is longer than a one-liner but appropriately sized for 8 parameters and multiple usage modes, with no filler.

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

  Completeness5/5

  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 a detailed return type including fields like 'truncated' and 'diagnosis'. It covers parameter behaviors, default values, edge cases (crash buffer), and error handling, making it complete for an 8-parameter tool with branching semantics.

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

  Parameters5/5

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

  Although schema description coverage is 100%, the description adds substantive meaning: e.g., lines behaves differently with crashes_only (first N of the crash vs most recent N), package_name filtering uses the process id and 'the app must be running' is expanded with the crashes_only fallback, and priority's default changes when crashes_only is set. This goes well beyond the schema.

  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 opens with a specific verb+resource: "Read logcat from the device, filtered down to what is actually relevant." It immediately clarifies the scope (device logs filtered) and distinguishes from sibling tools like android_screenshot and android_shell. The snapshot-vs-stream clarification further sharpens the purpose.

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

  Usage Guidelines5/5

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

  The Examples section explicitly states when to use the tool (after crash, watching Log.d, reproducing a bug) and when not to use it ('Don't use when: you want to see the screen' with the alternative android_screenshot). The Error Handling section also gives concrete conditional guidance (combine package_name with crashes_only after a crash).

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

• android_screenshotA
  5/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint=true, but the description adds substantial behavioral context: typical screenshot sizes (0.5–2 MB), default inline return, the effect of output_path and include_image, and error handling for black/empty screens (secure window or locked screen). This fully discloses operational nuances beyond the annotations.

  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 compact yet well-structured, using sections for overview, args, returns, examples, and error handling. Every sentence contributes value, with no redundancy or fluff. Front-loading the core purpose makes it immediately scannable.

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

  Completeness5/5

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

  Even without an output schema, the description fully documents the return format (inline image plus JSON with bytes, outputPath, serial) and common failure mode (black image). It covers size implications, optional parameters, and practical usage scenarios, making it complete for the tool's complexity.

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

  Parameters5/5

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

  Schema covers all three parameters with descriptions (100% coverage), and the description goes further by explaining the rationale for include_image=false (avoid large images in conversation) and the optional nature of serial when a single device is connected. This adds meaning beyond the schema.

  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 opens with 'Capture the device screen as a PNG', a specific verb+resource statement. It also explicitly distinguishes from sibling android_dump_ui by noting that for UI text or tapping, dump_ui is cheaper and provides coordinates, making the tool's unique scope clear.

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

  Usage Guidelines5/5

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

  Provides explicit 'Use when' and 'Don't use when' guidance, along with a named alternative (android_dump_ui). It also advises when to set include_image=false to avoid large images cluttering the conversation, giving concrete contextual direction.

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

• android_uninstallA
  5/5.0
  Behavior5/5

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

  The annotations already indicate destructiveHint=true and idempotentHint=true, but the description adds critical context: 'deletes the app's data and cannot be undone', the effect of keep_data ('adb uninstall -k'), and error behavior ('Reports when the package was not installed to begin with'). No contradictions with annotations.

  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?

  Structured with clear sections (Description, Args, Returns, Examples, Error Handling). Front-loaded with the core purpose and destructive warning. Every sentence contributes useful information without redundancy.

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

  Completeness5/5

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

  Given the tool's complexity (5 parameters, no output schema), the description covers the return format, example use cases, error handling, and parameter resolution logic. It is self-contained and fully prepares the agent to invoke the tool correctly.

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

  Parameters5/5

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

  While schema coverage is 100%, the description adds relational semantics: 'project_path... package is resolved from it when package_name is omitted' and clarifies keep_data as 'keep app data and cache directories (adb uninstall -k)'. This goes beyond the schema's per-field definitions.

  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 opens with 'Remove an app from the device', which is a specific verb+resource statement. It further clarifies destructive consequences and distinguishes from sibling tools like android_clear_data by explicitly stating when uninstall is appropriate (e.g., INSTALL_FAILED_UPDATE_INCOMPATIBLE) versus when a less destructive alternative should be used.

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

  Usage Guidelines5/5

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

  Provides explicit use cases: 'Use when: an install fails with INSTALL_FAILED_UPDATE_INCOMPATIBLE...' and 'Use when: testing a first-run experience'. It also gives a clear exclusion: 'Don't use when: you only want to clear state; force-stopping or clearing data is less destructive', naming the alternative.

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