@wilsonbeam/openclaw-adb-mcp
Server Quality Checklist
Latest release: v1.0.0
- Disambiguation5/5
Every tool has a clearly distinct purpose with detailed descriptions. Even related actions like make_call vs dial_number are unambiguously differentiated by their behavior, and press_key vs press_home/back are specific. No two tools appear to perform the same function.
Naming Consistency4/5The naming pattern is mostly consistent with the 'adb_' prefix followed by a verb and object (e.g., install_app, push_file, answer_call). However, a few names are noun phrases or queries (device_info, screen_size, call_state, is_locked), deviating from the verb-first style and creating minor inconsistency.
Tool Count2/5With 30 tools, this server exceeds the typical well-scoped range and crosses the 25+ threshold. While each tool has a distinct purpose, the large number can overwhelm agents and many could be consolidated via parameters, making the count feel excessive for most use cases.
Completeness4/5The tool set covers a wide range of ADB operations including device management, app lifecycle, file transfer, UI automation, telephony, and locking. Notable omissions like reboot and logcat are not directly exposed, but the adb_shell tool allows these to be executed manually, so agents can work around these gaps effectively.
Average 3.5/5 across 30 of 30 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
Add related servers to improve discoverability.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only states the action without disclosing return format, default filter behavior, or device selection rules. This leaves significant ambiguity for the agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence, front-loaded with the main verb and object, and contains no redundant words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has two parameters and no output schema, the description is incomplete. It doesn't explain what 'packages' means (names vs. details), the default filter, or how deviceId resolves with multiple devices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with descriptions (filter enum, deviceId optional), so the baseline is 3. The description adds no extra meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists installed packages, with a specific verb and resource. It distinguishes from siblings like adb_list_devices, but doesn't mention the filter option, so it's slightly less complete than a 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like adb_shell, which could also list packages via pm list. No prerequisites, examples, or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the call 'dials immediately,' but fails to mention potential side effects (e.g., ending an active call), permissions required, or whether the action is reversible. This is a significant gap for a side-effectful 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with a parenthetical for emphasis. It is concise and front-loaded, with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool performs a significant, state-changing action, yet the description is minimal. It lacks information about return values, failure modes, whether the action blocks, or how it interacts with other call-related tools (e.g., adb_call_state). Given no output schema and no annotations, this is incomplete for an action of this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (phoneNumber, deviceId) with clear descriptions. The description adds no further parameter semantics beyond 'specified number,' which maps directly to phoneNumber. 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Make a phone call') and resource ('specified number'), with an added behavioral detail ('dials immediately'). It is specific and unambiguous, though it does not explicitly differentiate from sibling adb_dial_number, which might appear similar.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 adb_dial_number or adb_start_activity. It does not mention prerequisites, context, or exclusions, leaving the agent without direction for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only says 'Get' which implies a read operation, but it does not disclose the output format (e.g., dimensions in pixels), how the optional deviceId behaves when omitted, or any potential side effects. This is a minimal disclosure for a tool that interacts 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that is appropriately sized for a simple tool. It is front-loaded with the action and resource, containing no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description should explain the return value and behavior for omitted deviceId. It does neither, leaving the agent uncertain about result format and default device selection. The simplicity of the tool slightly mitigates this, but the lack of return information is a notable gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully describes the single parameter deviceId with a clear description, giving 100% schema description coverage. The description adds no additional meaning about the parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the screen dimensions of the device' clearly states the verb (get) and resource (screen dimensions), making the tool's purpose specific. However, it does not explicitly differentiate from siblings like adb_device_info, which could also provide screen-related information, so it lacks overt sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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. The description only states what the tool does, with no mention of scenarios, prerequisites, or comparisons to sibling tools such as adb_device_info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to indicate safety, the description carries the full burden of behavioral disclosure. It merely says 'Execute a shell command,' which implies arbitrary and potentially destructive actions but does not warn about side effects, permissions, or the need for caution. This is a significant transparency gap for a tool that can modify system state in unpredictable ways.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with no redundant wording. It gets straight to the point and is front-loaded with the key action. However, it is so terse that it borders on under-specification, though not enough to be penalized heavily.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This tool can execute arbitrary shell commands, making it potentially powerful and risky. The description provides no information about output format (stdout/stderr), exit codes, or risk considerations. With no output schema and no annotations, the description is inadequate for an agent to fully understand the tool's behavior and implications.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for both parameters ('Shell command to execute' and 'Target device ID (optional if only one device)'), covering 100% of the parameters. The description adds no additional meaning beyond what the schema already offers, so it meets 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/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: executing a shell command on an Android device. It uses a specific verb and resource, distinguishing it from sibling tools like adb_tap or adb_install_app. However, it lacks any detail about scope or limitations (e.g., arbitrary commands vs. specific allowed ones), so it's not as rich as a top-tier purpose statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use adb_shell versus the many specific sibling tools (e.g., adb_force_stop, adb_clear_data). There's no mention of alternatives or scenarios where this generic shell tool is preferred. The description simply states the action without context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the action but does not disclose any behavioral details such as whether it triggers a key event, what happens if no call is incoming, or any side effects. The description is minimal and adds little beyond the tool name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence that is front-loaded and contains no unnecessary words. Perfect conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description is enough to understand the basic action, but it lacks context about prerequisites and behavior specifics. Given the simplicity, a score of 3 is appropriate, though it could benefit from noting that a call must be incoming.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers the single optional parameter (deviceId) with a description, so baseline is 3. The tool description does not add any parameter-specific meaning, but schema coverage is 100%, so it does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Answer an incoming call' uses a specific verb (answer) and resource (incoming call), clearly indicating the action. It distinguishes from related tools like adb_make_call and adb_end_call through the action verb, though it does not explicitly mention alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. No prerequisites are mentioned (e.g., requires an incoming call), and no exclusion scenarios are provided. The usage 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention potential side effects like data loss or immediate process termination, nor does it explain what happens to the app's state. The description is too terse to inform the agent about the impact of a force-stop 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one concise sentence with no redundant words or filler. It is front-loaded and efficiently communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simplicity of the operation, the minimal description is borderline adequate, but it lacks important usage context such as side effects and device targeting. The schema covers parameters, and no output schema is needed, but the description alone is thin for a tool that forcibly terminates apps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with both deviceId and packageName already described in the input schema. The description adds no additional parameter semantics, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Force stop an application' clearly states the verb and resource, making it easy to understand what the tool does. It does not explicitly distinguish it from sibling tools like adb_clear_data, but the action is specific enough for basic selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as adb_clear_data or adb_uninstall_app. The description only states what it does, not the context or contraindications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It only states 'Install an APK file on the device' without mentioning side effects (e.g., overwriting existing app, granting permissions), failure modes, or device selection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that directly states the tool's purpose. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given 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 one-line description is insufficient. It omits behavior around optional parameters (deviceId, reinstall, grantPermissions) and prerequisites like device connectivity, even though the schema defines them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides descriptions for all four parameters (apkPath, deviceId, reinstall, grantPermissions) at 100% coverage. The description adds no extra semantics beyond the schema, hence the baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'install' with resource 'APK file' and target 'device', clearly distinguishing it from siblings like adb_uninstall_app. It is concise and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this tool versus alternatives such as adb_uninstall_app or adb_list_packages. There are no prerequisites, exclusions, or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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, but it only says 'Check if the device screen is locked.' It does not disclose what the tool returns (e.g., boolean, string), any error conditions (e.g., device not connected), or whether the device must be booted. This is a significant gap for a read-only check 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence of eight words. It is front-loaded and contains no filler or redundant information. It is appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but with no output schema, the description should explain what the agent can expect as a return value or further implications. It does not mention the response format or any behavioral context needed to use the result. The lack of such essential context makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%—the only parameter (deviceId) is clearly described in the schema as an optional target device ID. The tool description adds no additional parameter semantics, but since the schema fully documents the parameter, the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies a verb ('Check') and a resource ('device screen is locked'), which precisely distinguishes it from sibling tools like adb_lock, adb_unlock, and adb_wake. There is no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, not the context in which it should be used (e.g., before attempting an unlock or other screen-dependent operations). No prerequisites or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the basic action ('Start an activity') without revealing potential side effects, failure modes (e.g., activity not found), or device selection behavior when deviceId is omitted. No context on return values, blocking behavior, or permissions is given.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
A single, well-structured sentence that front-loads the core action and is free of redundancy. Every word adds value and directly conveys the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (2 params, no output schema, no annotations), the description provides only the bare minimum. It lacks usage guidance and behavioral context, making it incomplete for an agent to fully understand how to invoke the tool and interpret outcomes, especially across the variety of sibling ADB tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for both parameters (intent with an example and deviceId as optional). The phrase 'with the given intent' simply restates the intent parameter without adding meaningful new semantics. Schema coverage is 100%, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Start an activity with the given intent' clearly identifies the specific verb ('Start'), resource ('activity'), and scope ('given intent'). It is unambiguous and naturally distinguishes itself from sibling tools like adb_shell, adb_tap, or adb_force_stop, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 does not mention any prerequisites, typical scenarios, or explicit exclusions (e.g., 'use adb_shell for background commands'). The agent is left to infer context solely from the name and schema.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description must carry the full burden of behavioral disclosure. It only repeats the purpose (getting info) and does not mention output format, prerequisites (e.g., device connected), or any side effects, leaving the agent without behavioral clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It clearly states the action and scope, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with one optional parameter, the description is adequate but minimal. It provides example fields but omits any details about the return format or usage context, which would be helpful given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the single parameter 'deviceId' with 100% coverage, so the description doesn't need to add parameter details. However, it also doesn't add any extra semantic nuance beyond the schema, keeping the score at the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('detailed information about an Android device'), with concrete examples (model, brand, Android version). This clearly distinguishes it from sibling tools like adb_list_devices, which lists devices rather than providing details.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 such as adb_shell or adb_list_devices. It only states the tool's function without any contextual cues or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the action without explaining side effects (e.g., navigating back, closing dialog, exiting app) or behavior when no deviceId is provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no redundant words. It is appropriately sized for the simplicity of the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple (one optional param, no output schema), so the description is minimally viable. However, it lacks usage context and does not differentiate from similar key-press tools, which are gaps for an agent selecting the right tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with deviceId described as 'Target device ID (optional)'. The description adds no additional parameter meaning beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press the back button' uses a specific verb and resource, clearly identifying the action. It distinguishes from siblings like adb_press_home and adb_press_key by specifying the back button.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 adb_press_key or adb_press_home. The description gives no context for device selection or interaction with other navigation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states that it presses a key, but does not disclose potential side effects (e.g., navigation changes), error behavior for invalid keycodes, or whether it requires an active adb connection. The phrase 'using Android keycode' is a technical detail about parameters, not a behavioral trait.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words, front-loading the purpose immediately. It is appropriately sized for a simple tool, though it sacrifices depth for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity, rich schema, and no output schema, the description is minimally complete for the core action. However, with 30 sibling tools, it lacks enough detail to fully disambiguate from specialized key-press tools, so it does not exceed the minimum viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, including descriptions and examples for keycode and deviceId, so the baseline is 3. The description's mention of 'Android keycode' is redundant with the schema and does not add new meaning beyond it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool presses a key on the device using Android keycode, distinguishing it from siblings like adb_tap (touch) and adb_press_home (specific key). The verb 'press' and resource 'key on the device' are specific and accurate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no guidance on when to use this generic key press versus specialized siblings such as adb_press_home or adb_press_back. It also does not mention prerequisites like requiring an unlocked screen or a connected device, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states the action but does not mention side effects (e.g., does not unlock), requirements (e.g., device must be connected and screen off), or how the wake is performed. This is minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero waste. It captures the essential purpose effectively and is perfectly sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is functional but lacks nuance. It does not explain the relationship to lock state or how waking is achieved, which would be useful given the presence of sibling tools like adb_unlock and adb_is_locked. Complete enough for basic use but not fully contextual.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% — the single 'deviceId' parameter is already fully documented in the schema as 'Target device ID (optional)'. The tool description adds no additional meaning beyond this, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Wake up the device screen' uses a specific verb and resource, clearly distinguishing it from sibling tools like adb_unlock and adb_press_key. It concisely states the tool's core function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 adb_unlock or adb_press_key. There is no explicit context, prerequisite, or exclusion mentioned, leaving the usage scenario unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden of behavioral disclosure. 'Clear all data' implies destructive and irreversible data loss, but it does not explicitly state that the action is permanent, require any special permissions, or clarify the exact scope of 'all data' (e.g., app-specific vs. external storage).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. The action verb is front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description is largely sufficient. It clearly states the action and the schema covers parameters. However, a brief note about irreversibility would have made it complete; this is a minor gap rather than a major omission.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the input schema fully documents both parameters. The description adds no additional parameter information, which is acceptable given the high schema coverage; baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Clear') and resource ('all data for an application'), making the tool's purpose clear. It is implicitly distinguishable from siblings like adb_force_stop and adb_uninstall_app, though it does not explicitly differentiate 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/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives such as adb_uninstall_app or adb_force_stop. There are no prerequisites, side-effect warnings, or contextual hints beyond the bare action.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 disclosure. It only describes the action itself and doesn't mention behavior such as press duration release, possible context menu triggers, or prerequisites like device connection; this is insufficient for a simulated touch action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, direct and to the point; no unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The schema fully documents parameters including the default duration, and the action is simple enough that the description adequately conveys the tool's purpose; however, it could benefit from mentioning the press-release behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters are fully described in the schema (100% coverage), and the description adds no more than restating 'coordinates', so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Long press' and specifies the target resource 'screen' with coordinates, effectively distinguishing it from sibling tools like adb_tap and adb_swipe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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; the description simply states the action without mentioning that adb_tap or adb_swipe are alternatives for different gestures.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states the basic action, without disclosing behaviors like overwriting existing local files, handling of missing remote paths, or device connection requirements. Minimal 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single front-loaded sentence with no redundant words. It efficiently conveys the core purpose without any waste.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with three documented parameters and no output schema, but the description lacks behavioral context such as overwrite behavior or prerequisites. It is adequate as a bare minimum but not genuinely complete for an agent that needs to anticipate side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all three parameters (deviceId, localPath, remotePath) described in the schema. The description adds no parameter information beyond what the schema already provides, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Pull' and the resource 'file from the Android device to local machine', clearly indicating the direction and distinguishing it from adb_push_file. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The direction implies when to use this tool (device-to-local transfer) versus adb_push_file (local-to-device), but it does not explicitly state alternatives or exclusions. Usage is implied rather than clearly guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states the core action without mentioning side effects, overwrite behavior, permissions, or error handling, leaving the agent uninformed about potential consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple nature of the tool and full schema coverage, the description is minimally viable. However, it lacks behavioral context (e.g., whether the push overwrites files) and usage guidance, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema provides complete descriptions for all three parameters (100% coverage), so the description's added value is limited. It reinforces the directionality of local/remote paths but does not add details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Push' and states the direction ('from local machine to the Android device'), clearly distinguishing it from sibling adb_pull_file and other file-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided about when to use this tool versus alternatives. The description implies usage (copying files to the device), but lacks exclusions or references to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 primary destructive action but does not mention side effects like permanent removal of app data, limitations on system apps, or permission requirements. The description adds no value beyond the tool name itself.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with zero wasted words. Every word contributes to meaning, making it highly concise and clearly structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the schema is fully descriptive, so the minimal description covers the basic purpose. However, it lacks contextual details like data-handling behavior and relationship to sibling tools, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema descriptions cover all three parameters (packageName, deviceId, keepData) with 100% coverage. The description itself adds no parameter-level detail, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Uninstall' and a clear resource 'app from the device', which distinguishes it from sibling tools like adb_install_app and adb_clear_data. It unambiguously states the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when an app needs to be removed) but provides no explicit comparison to alternatives such as adb_force_stop or adb_clear_data. It lacks clear context about when not to use it, but the core usage is understandable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states the action without disclosing what happens if no call is active, whether the call is ended immediately, if any confirmation is needed, or any side effects. This is a significant gap 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence that communicates the core action without any fluff. Every word earns its place, making it highly concise and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is still incomplete. It does not cover edge cases like having no active call, whether the tool is idempotent, or what the behavior is with or without a deviceId. Richer disclosure is needed for a mutation tool with no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters with a description for deviceId, so the baseline is 3. The description does not add any additional meaning about how deviceId affects behavior, but the schema already documents it adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'End the current phone call' uses a specific verb (end) and resource (current phone call), clearly distinguishing it from sibling tools like adb_make_call, adb_dial_number, and adb_answer_call. It leaves no ambiguity about what action this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description does not explicitly state when to use the tool or mention alternatives, the action is self-explanatory: it is for ending an ongoing call. The context is clear enough for an agent to select it when the goal is to hang up the current call, though it lacks explicit conditions or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It states the action but does not mention side effects, prerequisites (e.g., whether the device must be unlocked), or behavior when the screen is already locked. This lack of detail limits 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is clear and front-loaded with the essential information. There is no wasted text or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one optional parameter and no output schema. The description covers the core action adequately. Given the tool's low complexity, the description is nearly complete, though it could have added a note about device state requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional deviceId parameter, so the schema already documents it. The description adds no additional parameter context, but this is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Lock the device screen' uses a specific verb ('Lock') and resource ('device screen'), clearly distinguishing it from sibling tools like adb_unlock and adb_is_locked. It leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: use this tool when you need to lock the device screen. However, it provides no explicit guidance on when not to use it or how it compares to related alternatives such as adb_wake or adb_press_key.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 only states the basic action and does not mention any side effects, coordinate system details, or that the swipe duration is customizable, though the schema documents the default.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that front-loads the core purpose. Every word earns its place, with no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple gesture tool, the description and schema together are sufficient. The schema fully documents all parameters including the default duration. However, it could mention the coordinate system or that coordinates are screen-relative, but this is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what the schema already provides, which is adequate given the schema richness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (swipe) and the resource (screen), with the distinction of moving from one point to another. This differentiates it from sibling tools like adb_tap or adb_long_press.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when a swipe gesture is needed) but does not explicitly state when not to use it or mention alternatives. Given the presence of many sibling input tools, some guidance would be helpful but is not strictly necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description is the only source of behavioral information. It states that the tool taps at the specified coordinates, which is clear but does not disclose any potential side effects (e.g., unintended UI interactions) or prerequisites (e.g., device must be awake). Since this is a low-risk, simple action, the lack of nuance is not egregious, so a score of 3 reflects adequacy without extra depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is immediately front-loaded with the action. It contains no wasted words and is appropriate for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description combined with the schema is nearly complete. It lacks mention of the coordinate system (e.g., screen pixels) and any required device state, but these are common assumptions in ADB tools. The absence of an output schema is fine since the tool likely returns nothing, and the parameter schema is fully documented. Overall, the context is sufficient for an agent to invoke the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema describes all three parameters with 100% coverage, including x, y, and deviceId, so the description does not need to add param details. The phrase 'specified coordinates' merely echoes the x/y descriptions. The deviceId parameter is left entirely to the schema, and the description provides no additional meaning beyond what the schema already gives, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Tap') and the resource ('screen') with the specific coordinate parameter, which distinguishes it from sibling tools like adb_swipe and adb_long_press. It is a specific and unambiguous statement of the tool's function.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 other input tools such as adb_swipe, adb_long_press, or adb_type_text. There are no stated preconditions like screen-on requirements or device connection, and no exclusions for contexts where a tap would be inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It mentions the requirement for a focused field but omits potential failure modes (e.g., missing focus), handling of special characters, or whether text is unicode-supported. This leaves significant room for misinterpretation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence that conveys the core purpose without unnecessary detail, earning the highest score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, and the description covers the primary action and object. However, the lack of details on behavioral edge cases (e.g., no focused field, special character limitations) means the description is not fully complete for an agent to predict outcomes reliably.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents both parameters ('text' and optional 'deviceId'), so the description adds no additional semantic value beyond what is already in the schema. The baseline of 3 applies as no param-specific clarifications are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Type text') and target ('currently focused input field'), distinguishing it from sibling tools like adb_tap or adb_press_key. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: the tool is for typing text into a focused field. However, it does not explicitly mention when to use it over alternatives such as adb_shell, or what to do if no field is focused. This makes it clear but lacking exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must itself convey behavioral traits. It indicates a read-only operation via 'Get' and lists possible outcomes, which implies non-destructive behavior. However, it does not explicitly state that the operation has no side effects, nor does it describe behavior when no device is specified or when the device is unavailable. Basic transparency is present but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence that is front-loaded with the action verb and resource. It contains no redundant words, making it highly efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and no output schema, the description adequately covers the purpose and the possible return values. It lists the three states, which effectively communicates what to expect. Minor omissions like default device behavior or error handling are not critical for such a simple tool, so it is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides full coverage for the only parameter (deviceId) with a clear description ('Target device ID (optional)'). The tool description does not add any additional meaning or context for this parameter, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get'), a specific resource ('call state'), and enumerates the possible states (idle, ringing, offhook). This unambiguously distinguishes it from sibling tools like adb_make_call or adb_end_call, which perform different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for querying the current call state, which is obvious from the verb and noun. However, it does not explicitly provide when-to-use vs. alternative tools, nor any exclusion criteria (e.g., 'use this to check before placing a call'). The context is clear but not elaborated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral transparency. 'Press the home button' describes the action but does not disclose potential side effects (e.g., screen state, key event details, or device selection behavior). For a simple input action, this is adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that fully communicates the tool's purpose without any waste. It is front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (one optional parameter, no output schema), the description is nearly complete. However, it does not mention behavior when deviceId is omitted or how the action behaves across multiple connected devices, though this is partially inferred from the sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter deviceId is fully described in the schema (coverage 100%), so the description adds no additional meaning. The baseline of 3 applies because the schema handles parameter semantics completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Press the home button' uses a specific verb and resource, clearly distinguishing it from siblings like adb_press_back and adb_tap. It directly matches the tool name while adding the object 'button', 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for pressing the home button but does not explicitly contrast with alternatives like adb_press_key or adb_press_back. There is no when/when-not guidance, so the usage is inferred from the name rather than explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 operation is a listing, which implies read-only behavior, but it does not disclose details such as whether the ADB server is started, what 'info' includes (e.g., serials, models), or how errors/empty results are handled. This is adequate for a simple read operation but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded with the action, and contains no extraneous words. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple, zero-parameter listing tool. The description covers the essential purpose and output components ('status and info'). While it could slightly elaborate on what 'info' includes, the tool's simplicity means the current description is largely complete, especially given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description correctly avoids adding parameter information because there are no parameters to explain, and the schema already reflects this.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('connected Android devices') and clarifies it includes 'status and info'. This clearly distinguishes it from sibling tools that operate on a specific device (e.g., adb_shell, adb_device_info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its usage—to discover connected devices—but does not explicitly state when to use it versus alternatives or mention that it should be used before other ADB commands. There is no explicit 'use when' guidance, only the implied context that it lists devices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the key behavior that the SMS is not sent automatically—the user must press send. This is crucial because the tool name suggests sending. However, it does not mention prerequisites like device unlock or what happens if the SMS app is missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that states the action first ('Open SMS composer') followed by the key caveat. No fluff or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with three parameters and no output schema, the description covers the core action and the most important behavioral caveat. However, it lacks details on prerequisites (e.g., device must be unlocked) or what the tool returns, which could be useful for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides descriptions for all three parameters (phoneNumber, message, deviceId), covering 100% of the schema. The description adds no additional meaning or constraints on the parameters, so it remains at the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool opens the SMS composer with a pre-filled message, using a specific verb and resource. It also clarifies that the user must press send, distinguishing it from a tool that automatically sends SMS. This differentiates it from sibling tools like adb_make_call or adb_type_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for composing an SMS rather than sending it directly, but it does not explicitly state when to use this tool versus alternatives. No mention of device state (e.g., unlocked) or fallback scenarios. At best, the usage is implied from the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 provides useful detail on pattern encoding (3x3 grid numbering and examples), which goes beyond the schema. However, it does not mention failure behavior (e.g., wrong credential attempts), required permissions, or return values, which would add important context for an unlock 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/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences: the first states the core purpose, the second provides a necessary clarification for pattern input. Both sentences are information-dense and free of fluff, making it an appropriately sized and well-structured description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity, the 100% schema coverage, and the additional pattern guidance, the description is nearly complete. It lacks only edge-case behavior (e.g., what happens if the device is already unlocked or if the credential is wrong), but these are not critical for basic invocation and can be inferred from the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already covers all three parameters with descriptions (100% coverage). The description adds value by explaining the pattern grid format with concrete examples ('0123' or '0147' for L-shape), which clarifies the schema's terse 'pattern as string of digits' and helps the agent invoke the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Unlock') and resource ('the device'), and enumerates the supported lock types (password, PIN, pattern, swipe). This distinguishes it from sibling tools like adb_lock and adb_is_locked.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the device is locked but does not explicitly state when to use this tool versus alternatives such as adb_shell or adb_lock. No exclusions or alternative tools are mentioned, leaving the context to be inferred from the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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 clearly states the tool's non-dialing behavior and the need for user interaction, which is the most critical behavioral trait distinguishing it from adb_make_call. It does not detail side effects like screen unlock requirements, but for a simple tool this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and parenthetically adds the key caveat. Every word earns its place, with zero redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, the description is sufficiently complete: it states what it does, what it does not do, and relies on the schema for parameter details. There is no output schema to explain, and the description covers the main behavioral nuance. It could potentially mention the need for an unlocked screen, but this is not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already provides 100% coverage for both parameters (deviceId and phoneNumber), so the description does not need to add parameter details. The description neither contradicts nor expands on the schema, giving a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb-resource pair ('Open the dialer with a number') and immediately clarifies the key distinction from adb_make_call by stating it does not dial. This clearly identifies the tool's purpose and scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to open the dialer without completing a call) and explicitly states a when-not ('does not dial - user must press call'), effectively excluding scenarios where automatic dialing is needed. However, it does not explicitly name adb_make_call as an alternative, so it misses the full 'alternatives' criterion for a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/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 discloses the key behavior: returning the screenshot as a base64 PNG. It does not explicitly state that the operation is non-destructive, but taking a screenshot is inherently safe and does not modify the device. This is sufficient for the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded with the action and output format. Every word is necessary and there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple: one optional parameter, no output schema, no annotations. The description explains what it does and the return format (base64 PNG). This is complete for the tool's complexity; no additional details are needed for an 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/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description covers 100% of the parameter (deviceId is described as 'Target device ID (optional)'). The description itself adds no additional information about the parameter, so it provides no extra value beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Take a screenshot of the device screen and return as base64 PNG'. It clearly states the action, the target, and the output format. This distinguishes it from all sibling tools, none of which mention screenshots.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly provides clear context: use this tool when you need to capture the device screen. Since no sibling tool performs screenshots, there are no alternatives to exclude. However, it lacks an explicit when-not-to-use statement, though the purpose is so specific that it is not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/wilsonbeam/openclaw-adb-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server