ADB MCP Server
Server Quality Checklist
Latest release: v1.0.1
- Disambiguation4/5
Most tools have distinct purposes, but `execute_raw_adb` and `execute_shell_command` both execute arbitrary commands (on host vs device) and could be confused. Also `get_shared_preferences` and `list_shared_preferences` are similar but clearly one lists and one reads. Overall, the tool set is well-differentiated.
Naming Consistency5/5Every tool uses a verb_noun pattern, e.g., `reboot_device`, `install_app`, `pull_file`, `take_screenshot`. Even multi-word tools like `force_stop_app` and `dump_ui_hierarchy` maintain verb-first naming. No mixed conventions or camelCase.
Tool Count2/5With 42 tools, the server far exceeds the 25-tool threshold, making it heavy. While ADB is a broad domain, many tools are narrow (e.g., `get_dbinfo`, `list_shared_preferences`, `get_shared_preferences`) and could be consolidated. The count feels excessive for a typical MCP server.
Completeness4/5The tool surface covers device management, app lifecycle, file transfer, UI interaction, system diagnostics, and arbitrary execution. Minor gaps include backup/restore and some advanced device features, but the presence of `execute_shell_command` mitigates most missing functionality.
Average 3.6/5 across 42 of 42 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 3 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
This repository is licensed under MIT License.
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 provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, required permissions, read-only nature, return format, or any operational quirks. The description simply states what is retrieved, offering minimal insight beyond that.
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 sentence, front-loaded with the core action. It is readable and efficient, though the phrase 'screen time statistics' is somewhat redundant with 'app usage' and the omission of procstats is a minor structural gap.
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?
Despite schema coverage, the tool has no output schema, so the description should explain the return format or behavior. It does not, leaving the agent uncertain about the output. Additionally, the service parameter supports procstats but the description only mentions two of three services, making the tool's coverage 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?
The schema description coverage is 100%, so the parameters are already well documented. The description adds slight context by naming the services but does not explain serial or packageName beyond what the schema provides. It also omits procstats from the service list, failing to fully complement 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 retrieves app usage and screen time statistics, using a specific verb and resource. It distinguishes from siblings like get_cpu_usage and get_app_memory. However, it only mentions usagestats and batterystats, omitting the procstats option available in the schema, causing slight incompleteness.
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 explicit guidance on when to use this tool versus alternatives like get_app_memory or get_cpu_usage. It does not mention any exclusions or preferred scenarios. The only implied usage is that it retrieves app usage statistics, which is insufficient for effective 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?
No annotations are provided, so the description carries full burden for behavioral disclosure. It only repeats the tool's name ('Force stop') without explaining side effects like killing background processes, potential data loss, or whether it affects other apps. It adds little beyond what the tool name already implies.
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?
It is a single, clear sentence with no unnecessary words. The action and target are immediately stated, making it efficiently front-loaded.
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 description is minimal, lacking usage context, side effects, or relationship to sibling tools. Given that force-stopping is a potentially destructive operation and no output schema or annotations exist, the description should provide more cautionary context and clarify differences from related 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 provides complete descriptions for both parameters (serial and packageName), so baseline is 3. The description adds no extra parameter-level context, but the schema is sufficient, so the tool description doesn't need to compensate.
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 ('Force stop') and the target resource ('all processes associated with the application package'). It distinguishes itself from sibling tools like uninstall_app (removes the app) and clear_app_data (clears app data), which are related but different operations.
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 instead of alternatives. It does not mention typical use cases (e.g., unresponsive app) or contrast with similar operations like uninstall or clear data. No exclusions or conditionals 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?
No annotations are provided, and the description does not disclose side effects, persistence of the forward, or how it interacts with other tools like list_forwards. The description only states the basic operation, leaving the behavioral implications undocumented.
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 resource, containing no unnecessary words or repetition. It conveys the core purpose efficiently.
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?
With no annotations and no output schema, the description should clarify the operational context, such as how to stop the forward or verify it (e.g., via list_forwards), but it does not. This leaves a significant gap for a network operation of this type.
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 describes all four parameters with clear examples and flags, achieving 100% coverage. The description adds no additional meaning beyond what the schema already provides, 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 uses the specific verb 'Forward' with the resource 'socket connections from a local host port to a port on the connected device,' making it clear what the tool does and distinguishing it from the sibling reverse_port, which does the opposite direction.
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 reverse_port, nor mentions prerequisites such as a connected device. It merely states the function without context 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 implies a read-only retrieval but does not state side-effects, permissions, or limitations (e.g., that packageName only works for some services). It adds no transparency beyond the basic 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?
The description is a single, front-loaded sentence that conveys the core purpose without redundancy. Every word earns its place; no wasted text.
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?
With no output schema, the description should explain what kind of details are returned or how results are structured. It does not. It also leaves ambiguity about interactions between serviceName and packageName (e.g., what happens if both are provided). For a tool with three optional parameters, this is a notable completeness 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 coverage is 100%, and each parameter is already well-described. The description's mention of 'service or package' lightly reinforces the two optional parameters but adds no new detail beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve') and resource ('system diagnostic details (dumpsys)') and clearly indicates the tool targets a service or package. This distinguishes it from sibling diagnostic tools like get_cpu_usage or get_app_memory, which focus on narrower metrics.
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 vs. alternatives like get_cpu_usage, get_app_memory, or get_logcat. The phrase 'for a service or package' gives some context but does not explain scenarios, exclusions, or when a sibling would be more appropriate.
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 carry the full burden of disclosing behavioral traits. It does not mention potential side effects like overwriting existing apps, the default reinstall behavior, or the need for a connected device. The single sentence is too sparse to provide meaningful 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, clear sentence with no filler or redundant information. It is appropriately concise and front-loaded with the core action.
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 4 parameters, no annotations, and no output schema, the description is too thin. It does not explain return values, prerequisites, or usage nuances like the reinstall/downgrade flags. While the schema documents parameters, the description lacks broader context needed for an agent to fully understand the tool's 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?
The schema descriptions cover all 4 parameters (serial, apkPath, reinstall, allowDowngrade) with 100% coverage, so the baseline is 3. The description itself adds no additional parameter-level insights, but the schema already provides sufficient detail.
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 ('Install'), the resource ('APK'), and the target ('connected device'), making the tool's purpose unambiguous. It distinguishes itself from sibling tools like uninstall_app and push_file by specifying the install action and APK file type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 push_file for transferring files or uninstall_app for removal. There is no mention of prerequisites (e.g., device connection) or scenarios where installation is appropriate.
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?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It does reveal the possible state values (offline, bootloader, device), which is useful, but it does not describe behavior for multiple connected devices, error cases, or the exact return format.
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 extraneous information. Every word contributes to understanding the tool's purpose and expected output.
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, the description covers the basic purpose and example states, but it lacks usage guidance and sibling differentiation. With no annotations and no output schema, the description is adequate but not complete, missing edge-case behavior and selection criteria.
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 only parameter (serial) with a clear optionality note. The tool description adds no additional parameter semantics beyond what the schema already provides, warranting the baseline score 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: retrieving the current state of a connected device, with concrete examples of possible states. It is distinct from sibling tools like reboot_device or install_app, but does not explicitly differentiate from list_devices, which may also return device state.
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 explicit guidance on when to use this tool versus alternatives such as list_devices or get_properties. The optional serial parameter hints at usage for a specific device, but there is no stated context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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. It only states the action without mentioning side effects, device requirements, coordinate system origin, or multi-device handling (e.g., serial parameter). The behavior is not misleading but is severely under-explained for an agent needing to understand implications of the tap.
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. It efficiently states the core purpose, and there is no extraneous information. It is appropriately 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?
Given the tool's simplicity, a one-sentence description might be minimally adequate, but it lacks context about device selection, coordinate origin, and when to use it. The schema covers parameter details, but the description does not provide enough surrounding context for an agent to confidently invoke it in varied situations. It feels complete for a trivial tap but not robustly.
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 itself adds no additional meaning beyond the schema: it doesn't clarify coordinate units (though schema lists 'pixels') or the optionality of serial. The schema already documents parameters adequately, so this is a pass-through score.
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 ('the screen') with specific coordinate parameters, which distinguishes it from sibling tools like swipe_screen or send_keyevent. It is a specific verb+resource pair that unambiguously conveys 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 alternatives such as swipe_screen or send_keyevent. There is no mention of contexts like interacting with UI elements, automating taps, or needing a connected device. No exclusions or alternative indications 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 provided, the description carries the full burden of behavioral disclosure. It does not mention that uninstalling removes app data or that it is a destructive, irreversible operation, nor any prerequisites beyond 'connected 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 and directly states the tool's function with no filler words.
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 uninstall operation with 3 parameters fully described in the schema, the description is minimally adequate but does not explain when to prefer this over related tools like clear_app_data, nor does it highlight the data-loss implication. It lacks context for an agent making a nuanced choice.
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 three parameters (serial, keepData, packageName) are fully described in the schema, so the description adds no additional parameter semantics. The description does not elaborate on the keepData flag or serial selection, but schema coverage is high at 100%.
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 'Uninstall' and identifies the resource 'application package from the connected device,' which clearly states what the tool does and distinguishes it from sibling tools like install_app or clear_app_data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 compared to alternatives such as clear_app_data or force_stop_app. It only states the basic action without exclusions or context for selection.
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 adds a useful safety trait (array-based args prevent shell injection on the host), but it does not mention potential side effects, output handling, or any prerequisites like device connectivity. This is only partial disclosure for a tool that can run arbitrary commands.
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?
Two sentences with no filler. The core function is stated first, followed by a relevant safety note. Every word contributes to understanding, earning a top score.
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 a raw ADB command executor with no output schema and no annotations. The description lacks any indication of what the tool returns (e.g., stdout/stderr) and provides no warning about the destructive potential of arbitrary ADB commands. This is a significant gap for such a powerful tool, making the description 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% with a clear example for args and serial description. The description itself adds no parameter-specific semantics beyond the schema, so a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes an arbitrary ADB command using raw command-line arguments. This specific verb+resource distinguishes it from siblings like reboot_device or forward_port, and the mention of 'host machine' helps differentiate from execute_shell_command.
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 explicit guidance on when to use this tool versus the many sibling tools (e.g., forward_port, install_app). It only states what the tool does without any 'use this when...' context or exclusions, 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 must convey behavioral traits, but it only mentions 'full access' without elaborating on potential side effects, output handling, or safety considerations. Running arbitrary commands can modify device state, yet the description does not warn about this or describe what the caller should expect.
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 focused sentences, front-loaded with the core action and immediately clarifying the tool's arbitrary scope. It is concise with no redundant wording.
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 executes arbitrary shell commands, which is complex and can have broad effects, yet the description omits return values (e.g., stdout/stderr), error behavior, and potential risks. Without an output schema, the agent lacks crucial information to handle the tool's results safely and effectively.
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 little beyond the schema: it provides example command strings but does not explain the serial parameter or any additional details about command formatting or execution context.
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 executes an arbitrary shell command on the connected Android device, using a specific verb and resource. This distinguishes it from sibling tools like tap_screen or execute_raw_adb, and the examples (e.g., 'input keyevent 26') illustrate the scope effectively.
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 phrase 'arbitrary shell command' implies this is a general-purpose tool for shell operations not covered by dedicated siblings, but no explicit when-to-use or alternatives are mentioned. There is no guidance on preferring more specific tools when available, leaving usage to be inferred.
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 disclosing behavioral traits. It only states the core function without mentioning output format, required permissions, read-only status, or potential side effects. For a dump tool, this is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence, 11 words, front-loaded with the action and target. Every word earns its place; there is no redundancy or filler.
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 there is no output schema, the description should explain what the returned 'meminfo' looks like or at least note that output is raw. It also lacks behavioral context (e.g., requires root? read-only?). For a relatively simple tool, it is still incomplete for an agent that needs to know what to expect.
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%, so baseline 3 applies. The description adds no meaning beyond the schema; it reiterates 'app package name' but provides no extra context for serial or special formatting. Schema descriptions already define both parameters 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 clearly states a specific action—'Dump detailed RAM memory statistics (meminfo)'—targeting a specific resource: 'an app package name.' This distinguishes it from sibling tools like get_cpu_usage (CPU) and get_dumpsys (system-wide dumpsys) by scope and resource.
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 use for obtaining per-app meminfo, but provides no explicit when-to-use or when-not-to-use guidance. It does not mention alternatives like get_dumpsys or note prerequisites (e.g., rooted device). Context is clear enough to infer the intended use, but exclusions are missing.
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 revealing side effects, persistence of the permission grant, host requirements, or behavior in error cases. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is direct and to the point. It communicates the essential operation with 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?
There is no output schema and no annotations, so the description should compensate by explaining return values, preconditions, or error scenarios. It does none of that, leaving the agent uncertain about what happens after the call or what is required for success.
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 covers all parameters (100% coverage) with clear descriptions including an example for 'permission'. The description adds no extra parameter semantics, 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 clearly states the action (grant) and the target (runtime permission to an application package), which distinguishes it from siblings like revoke_permission. It is specific and unambiguous about the tool's core 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 usage context (when you need to grant a permission on a device) but does not provide explicit when-to-use versus alternatives, prerequisites like the app being installed, or any exclusions. This is acceptable 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 provided, the description carries full responsibility for behavioral disclosure. It only states the action without revealing side effects, prerequisites, or what happens after disconnection (e.g., device no longer listed). This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's purpose. No unnecessary words or filler.
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 covers parameter semantics, but the lack of annotations and behavioral information leaves context incomplete. The description does not explain what happens after disconnection or any post-conditions, so it is minimally adequate.
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 both host and port fully described. The description adds no new parameter details beyond that, which is acceptable given the schema's completeness. 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 clearly states the action (disconnect), the target (a previously connected TCP/IP Wi-Fi device), and distinguishes it from sibling tools like connect_device. It is specific and action-oriented.
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 phrase 'previously connected' implies the device must already be connected via TCP/IP, offering some usage context. However, it does not explicitly mention when to use it over alternatives or any exclusions, so guidance is only implied.
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 mentions using dumpsys cpuinfo, implying a read-only operation, but does not state whether a device must be connected, what permissions are needed, or what the output format looks like. This is a significant gap for a shell-based 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, concise sentence that front-loads the action ('Retrieve') and resource ('CPU load statistics'), with no wasted words or redundant content.
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 parameter, no output schema), and the description provides the essential method. However, it lacks context on the return value format, device requirements, or any caveats, making it adequate but minimal.
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 has 100% coverage for the single optional parameter 'serial' with its description 'Specific device serial number'. The tool description adds no additional parameter semantics, 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 uses a specific verb 'Retrieve' and identifies the resource as 'current CPU load statistics', with the method 'dumpsys cpuinfo' distinguishing it from sibling tools like get_dumpsys or execute_shell_command.
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 phrase 'current CPU load statistics' implies the use case of needing CPU information, but there is no explicit guidance on when to use this tool versus alternatives like get_dumpsys or execute_shell_command, nor any exclusions or prerequisites.
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. 'Retrieve' implies a read operation, but it does not specify whether special permissions are needed, how verbose affects output, or what the return format is. No behavioral traits beyond the basic operation are disclosed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence, front-loaded with the primary action and resource. Every word earns its place with no filler.
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 optional parameters and no output schema. The description provides enough context to understand its core purpose, but could be more complete by explaining what diagnostics are included or that a device connection is required. It is minimally sufficient.
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 each parameter (serial, verbose, packageName) described in the schema. The description adds no meaning beyond the schema, only restating the optional package filter. Baseline 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 ('Retrieve') and resource ('SQLite database statistics and diagnostics'), and clarifies it uses dumpsys dbinfo. It distinguishes from siblings like query_sqlite (queries data) and get_dumpsys (general dumpsys) by focusing on database diagnostics.
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 through its focus on SQLite stats, but does not explicitly state when to use it versus alternatives like query_sqlite or get_dumpsys. No exclusions or alternative guidance are provided.
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 fully disclose behavior. It only says 'List', which implies a read-only operation, but it does not explicitly state that it is non-destructive, what output it returns, or how the serial parameter behaves (e.g., default device). This leaves important behavioral context undisclosed.
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, well-structured sentence that immediately identifies the action and subject. It includes the key optional behaviors (filtering) without any unnecessary words or repetition.
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 list tool with no output schema, the description is adequate but has gaps: it doesn't describe the return value format, the default behavior when serial is omitted, or explicitly confirm the operation is read-only. These omissions reduce completeness, especially with no annotations to fill 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 input schema has complete descriptions for all three parameters, so the baseline is 3. The description adds only a brief summary of the filter options ('by name or package type'), which does not go beyond the schema's own parameter descriptions.
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: 'List all installed application packages on the device' with a specific verb and resource. It also mentions filtering options, which distinguishes it from sibling tools that list other resources (e.g., list_forwards, list_devices).
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 by stating what the tool does and its filter options, but it does not explicitly say when to use it versus alternatives. There are no exclusion criteria or named alternative tools, though the unique purpose makes it fairly obvious.
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 describes the action as 'copy', but does not disclose important behavioral traits such as whether existing remote files are overwritten, whether directories are recursively copied, or whether any permissions are required. Such details are critical for a file transfer 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, well-structured sentence that front-loads the purpose ('Copy a file or directory') and specifies the source and target. It contains no redundant or repetitive content, making it appropriately concise for a simple tool.
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 straightforward file transfer tool, the description covers the basic purpose and direction. However, with no annotations or output schema, it lacks crucial contextual details like overwrite semantics, error handling, and whether parent directories are automatically created. These omissions leave the description slightly incomplete for a production 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 clear descriptions for localPath and remotePath. The description adds no new parameter-specific information beyond the schema. It confirms file/directory support, which is also already noted in the schema. Thus, 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 uses a specific verb ('Copy') and clearly states both source (host machine) and destination (connected device), including support for files or directories. This unambiguously distinguishes it from sibling tools like pull_file (which copies in the opposite direction) and install_app (which handles APK installation).
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 transferring files from host to device, which indirectly differentiates it from pull_file. However, it does not explicitly state when to prefer this tool over alternatives, nor does it mention any prerequisites or exclusions. The context is clear enough for a simple transfer but lacks explicit guidance.
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 carry the full burden of behavioral disclosure. It lists the reboot modes but does not warn that the operation will disconnect the device, may interrupt ongoing operations, or requires the device to be in a stable state. This is a significant gap for a state-changing 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?
The description is a single, clear sentence that leads with the action and resource, then lists the valid modes. No irrelevant information is included, and the structure is easy to scan.
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 tool's relative simplicity and 100% schema coverage, the description is adequate for a basic understanding. However, it lacks usage guidance, side-effect warnings, and prerequisite context (e.g., needing a connected device with proper authorization), which are not compensated by 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?
Schema description coverage is 100% for both parameters, and the description adds no additional meaning beyond what the schema already provides. The mode list is duplicated in the description and enum, 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 ('Reboot') and resource ('connected device'), and it enumerates the supported modes (system, bootloader, recovery, sideload), making it distinct from all sibling tools. No ambiguity exists.
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 should be used when a device reboot is needed, but it does not explicitly contrast with alternative approaches (e.g., using execute_shell_command or other device-control tools). 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?
No annotations exist, so the description carries full burden. It only restates the basic operation and save behavior already implied by the schema. It does not disclose prerequisites, duration limits, or what happens after recording.
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. Every word earns its place.
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 three-parameter tool with full schema coverage, the description adequately conveys the primary purpose. However, it lacks behavioral context and usage guidance, making it minimally sufficient rather than 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?
Schema coverage is 100% with descriptions for all parameters. The description adds no new semantic meaning; the 'given duration' and 'save to host' phrases simply echo the schema descriptions.
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 records the device screen as an MP4 video for a duration and saves it to the host. This distinguishes it from sibling take_screenshot by specifying video format and duration.
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 screen recording but does not explicitly state when to choose this over alternatives like take_screenshot. No exclusions or alternative tool names 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It mentions the operation but does not disclose potential side effects, required permissions, error conditions, or impact. This mirrors the gap noted in comparable mutation tools.
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 redundancy or filler. Every word adds value, making it highly concise.
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 scope, full schema coverage, and no output schema, the description is minimally acceptable. However, it lacks behavioral context (e.g., handling of optional serial, effect on app state) and alternative tool guidance, leaving some operational gaps.
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?
Input schema coverage is 100%, with each parameter already clearly described. The description adds no additional parameter-level nuance, 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 action ('Revoke') and the resource ('runtime permission from an application package on the device'). This is a specific verb+resource construction that distinguishes it from sibling tools like grant_permission.
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 via its action, but does not explicitly state when to use this tool versus alternatives, nor any exclusions or prerequisites. The sibling grant_permission is an obvious alternative, but no mention is made.
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 mentions 'hardware/system key simulation' but does not explain potential side effects (e.g., POWER key affects device state, APP_SWITCH may trigger system UI) or error behavior when the device is not connected or the keycode is invalid. This is a significant gap for an input simulation 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 sentence, front-loaded with the core action and supported by relevant examples. Every word contributes to understanding, with no unnecessary detail or repetition.
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 tool's low complexity (2 params, no output schema) and full schema documentation, the description is adequate for the essential purpose. However, it lacks guidance on device selection (serial) and failure modes, making it minimally complete but not thorough.
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 tool description adds extra keycode examples (APP_SWITCH=187) beyond the schema's examples, clarifying the range of accepted keys. However, it does not add meaning beyond the schema for serial or keycode semantics, relying heavily on the schema's own descriptions.
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 purpose: 'Send a keyevent (hardware/system key simulation) to the device' with concrete examples (BACK=4, HOME=3, POWER=26). This distinguishes it from sibling input tools like tap_screen, swipe_screen, and type_text, which handle different input types.
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 hardware/system key events via examples, but it does not explicitly state when to use this tool vs alternatives (e.g., execute_shell_command could send key events via adb shell). There is no mention of when not to use it or which sibling tools are preferred for other input types.
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 connection action but does not mention side effects, whether it replaces an existing connection, authentication requirements, or the need for the device to be in ADB-over-Wi-Fi mode. This leaves behavioral ambiguity.
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 direct, front-loaded, and contains zero redundant words. It efficiently conveys the core action and key parameters.
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 only two parameters and no output schema, the description covers the essential purpose and connection method. However, it omits potential prerequisites like the device being previously configured for TCP/IP, which would make the invocation more robust. Still, it is a straightforward tool and the description is largely sufficient.
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 host and port having descriptions. The description echoes 'IP address and optional port' but adds no new semantic detail beyond the schema, so it meets the baseline for well-documented parameters.
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 'connect' and names the resource 'Android device' over TCP/IP (Wi-Fi), which clearly distinguishes it from siblings like disconnect_device and list_devices. It states the exact action and method.
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 establishing a Wi-Fi connection to an Android device before other operations, but it does not explicitly mention when to use this tool versus alternatives like USB connection or when not to use it. It lacks exclusions or prerequisite context.
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 full responsibility for behavioral disclosure. It mentions the debug/root prerequisite but fails to warn that the tool can execute arbitrary SQL commands, including destructive operations like DELETE or DROP, with no confirmation. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and wastes no words. The critical debug/root note is included without bloat.
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 complex because it executes raw SQL, yet there is no output schema and the description doesn't explain return format, error behavior, or side effects. The debug/root limitation is present, but missing output/return details 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?
The schema covers all parameters with descriptions and examples, so the baseline is 3. The tool description adds no extra parameter semantics beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool executes SQL queries/commands on a SQLite database within an app's sandboxed directory. It uses a specific verb and resource and is distinct from siblings like get_dbinfo or execute_shell_command.
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 gives clear context (executing SQL against an app's sandboxed database) and includes an important prerequisite/exclusion: only works on debuggable apps or rooted devices/emulators. It doesn't explicitly call out alternatives, but the constraint is valuable usage guidance.
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?
The description discloses the space-formatting behavior for compatibility with the adb shell, which adds value beyond the minimal schema. However, it does not mention other potential behaviors like special character handling or failure modes when no field is focused; with no annotations, the description carries the full burden but only partially fulfills it.
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 long, front-loaded with the action, and contains no redundant information. Every clause contributes to understanding the tool's purpose and behavior.
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 fully described schemas, the description adequately covers purpose and key behavior. It could be more complete by noting the requirement of a focused field or the scope of text formatting, but overall it is sufficient.
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 both text and serial parameters. The tool description does not add semantic information beyond what the schema already provides, 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 clearly states a specific action ('Type text') targeting a specific resource ('the currently focused input field'), which distinguishes it from sibling input-related tools like tap_screen or send_keyevent. The scope is precise 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?
No guidance is provided on when to use this tool versus alternatives such as send_keyevent or execute_shell_command. The description implies a focused field but does not explicitly state prerequisites, exclusions, or preferred scenarios.
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 full burden of behavioral disclosure. While 'Dump' implies a read-only operation, the description does not mention side effects, permissions, or how the output is delivered (e.g., stored as a file on device vs. returned directly). It lacks detail on potential behavioral traits beyond the basic 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?
The description is two concise sentences, front-loaded with the core action and purpose. Every part contributes value, and there is no unnecessary elaboration.
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 has one optional parameter and no output schema. The description clearly explains the tool's purpose and when to use it, but it does not specify the output format or behavior (e.g., whether the XML is returned or saved as a file). This leaves some ambiguity for an agent invoking the 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 coverage is 100% for the only parameter (serial), and the description adds no extra meaning about it. The baseline of 3 applies since the schema already documents the parameter sufficiently, and the description does not need to compensate for any gaps.
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 'Dump' and resource 'current layout tree (UI hierarchy XML)', clearly identifying the tool's function. It also mentions 'using uiautomator' and 'inspect what UI elements are currently visible', which distinguishes it from sibling tools like take_screenshot or get_dumpsys.
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 ('Highly useful for AI agents to inspect what UI elements are currently visible'), implying it should be used when UI structure understanding is needed. It does not explicitly mention alternatives or exclusions, but the context is sufficient for basic 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?
There are no annotations, so the description carries the full burden. The description only restates the basic operation, offering no disclosure about overwriting behavior, permission requirements, or behavior for missing paths. It is essentially a synonym for the tool name without adding behavioral nuance.
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, economical sentence that is immediately understandable. No filler or redundant information.
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 complete, so the description is minimally adequate. However, given the lack of annotations and output schema, a bit more context (e.g., overwrite behavior, recursive directory pull) would increase completeness. It does not rise above a viable baseline.
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 schema fully documents all three parameters. The description does not add any extra meaning to the parameters beyond what is already in the schema, which puts it 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 clearly states the action ('Copy'), the resource ('file or directory'), and the direction (from device to host). This distinguishes it from push_file, its obvious sibling, which copies in the opposite direction.
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 phrase 'from the connected device to the host machine' provides clear context for when to use this tool (when you need a file off the device). It does not explicitly name alternatives, but the direction is self-explanatory and differentiates it from push_file.
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 behavior disclosure burden. It explains the gesture pattern and that duration simulates drag, but does not disclose coordinate origin, default duration behavior, or potential side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the core action and avoids filler, 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.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple gesture tool with full schema coverage, it is mostly adequate, but it lacks usage guidance relative to sibling gesture tools and does not mention default duration or coordinate system; return behavior is not described but likely irrelevant for this action.
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 covers all 6 parameters (100%), so the baseline applies. The description adds minimal context by relating duration to drag actions, but does not provide meaningful meaning beyond the schema's parameter descriptions.
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?
Description uses the specific verb 'swipe' and resource 'screen', clearly distinguishing it from sibling actions like tap_screen by describing movement between starting and ending coordinates, with an optional duration.
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 phrase 'simulate drag actions' implies a use case for drag gestures, but there is no explicit guidance on when to use swipe versus alternatives like tap_screen or send_keyevent, and no exclusions are mentioned.
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?
Despite lacking annotations, the description clearly indicates a read-only operation via the verb 'retrieve'. It names the exact command (getprop) and the target (Android device), making the behavior transparent. It does not disclose potential nuances like the default device selection when serial is omitted, but that is a minor gap for a simple getter.
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 action and resource. It is free of redundant wording and earns its place with no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/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 a well-defined schema and no output schema required, the one-liner is adequate. It could have hinted at the optionality of the property name parameter or the output format, but the schema already covers those aspects, making the description sufficiently complete for this context.
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 full descriptions for both parameters (serial and propertyName), with 100% schema coverage. The tool description adds no extra meaning beyond the schema, 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 retrieves system property values (getprop) from an Android device. It is specific about the resource and action, and the parenthetical 'getprop' disambiguates it from other system information tools like get_dumpsys.
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 explicit guidance on when to use this tool versus alternatives such as get_dumpsys or execute_shell_command. It only states what it does, leaving the agent to infer usage context without any exclusions or alternative suggestions.
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?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, and 'active' indicates current state, but the description does not disclose potential side effects, permission requirements, or what happens when serial is omitted. It adds some context but lacks deeper behavioral detail.
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 is concise and directly states the tool's function. Every word adds value with no waste.
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 list tool with one optional parameter and no output schema, the description covers the core functionality. However, it does not clarify the behavior when 'serial' is absent (i.e., whether it lists connections for all devices or only the current one), which is a minor gap. Overall, it is nearly complete for the tool's simplicity.
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%, and the only parameter 'serial' already has a clear description. The tool description adds no extra meaning about parameter behavior, such as whether omitting serial lists across all devices. Baseline of 3 is appropriate since the schema handles parameter documentation.
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 'List' with a clear resource ('active reverse port connections') and directional scope ('from device to host'). It clearly distinguishes itself from sibling list_forwards by specifying the direction.
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 inspecting reverse port connections, but it does not explicitly mention alternatives like list_forwards or state when not to use it. The directionality offers some context, but no direct guidance on tool selection.
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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It discloses that root or a debuggable app is required and that the target is the app sandbox, but it does not explicitly state that it is a read-only operation or describe the output format, leaving some behavioral aspects implicit.
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 extremely concise: two sentences with no filler. It front-loads the core action and resource, then adds the key prerequisite. 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 listing tool with a small schema, the description covers the primary scope (all SharedPreferences files in the sandbox) and a critical prerequisite. It does not explain the return format or mention edge cases (e.g., what happens if none exist), but given the tool's simplicity, the description is nearly 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 already provides helpful descriptions for both serial and packageName (100% coverage). The description adds only the context of 'application sandbox,' which slightly reinforces packageName's purpose but does not materially extend beyond the schema. Baseline 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 states the action 'List all' and the resource 'SharedPreferences (preferences XML files) inside an application sandbox.' This is specific and distinguishes the tool from siblings like get_shared_preferences, which likely reads content rather than listing files.
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 to enumerate SharedPreferences XML files for a given package. It mentions a prerequisite (debuggable app or root) but does not explicitly contrast it with alternatives such as get_shared_preferences or list_packages, offering no 'when-not-to-use' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden of behavioral disclosure. It only defines the direction and one example; it does not mention persistence of the reverse mapping, prerequisites like a connected device, failure modes, or the effect of the noRebind flag. This is sparse for a networking mutation.
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 clear and includes a concrete example. It has no filler, does not repeat schema content, and efficiently conveys purpose and one key use case.
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 all parameters and required fields, and the description gives a crisp purpose with a canonical use case. Still, the absence of annotations and output schema leaves behavioral and alternative-usage details unexplained, so it is not a fully complete picture but is sufficient for basic selection and invocation.
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 have descriptions in the schema (100% coverage), so the baseline is 3. The description does not add significant meaning beyond 'device' and 'local host', and the 'tcp:8081' example is already present in the schema. It maps loosely to parameter roles but adds little new semantic detail.
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 ('Reverse') and resource ('socket connections') and clearly states direction ('from a port on the device to a port on the local host'). The React Native bundler example reinforces a concrete use case, and the direction implicitly distinguishes it from the sibling forward_port without being ambiguous.
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 a clear, actionable context: 'critical for React Native bundler reverse tcp:8081', which tells the agent a canonical scenario. However, it does not explicitly contrast with forward_port or list_reverses, nor does it state when not to use this tool, so exclusions are missing.
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. It discloses the mechanism (restart adbd) and the outcome (restore non-root privileges), but lacks side effects such as whether the change is persistent, if it affects running root processes, or if any prerequisites exist. This is adequate but not rich.
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 efficiently conveys the action and result without any unnecessary words. Every element 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 tool with one optional parameter and no output schema, the description is largely complete. It states the core behavior and effect. It could benefit from a note on when to use it, but given the simplicity, the current level is sufficient.
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% since the only parameter 'serial' has a description. The tool description adds no additional meaning to the parameter, 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 clearly states the tool's function: restarting the adbd daemon without root permissions, restoring non-root privileges. It uses a specific verb + resource and distinguishes from siblings like root_device and reboot_device by focusing on the adbd daemon.
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 usage context is implied from the name and description (use to unroot), but there is no explicit guidance on when to choose this over alternatives, nor any exclusions or conditions. It does not mention scenarios like 'use when you need to remove root access' or distinguish from reboot_device.
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?
No annotations are provided, so the description carries the burden of disclosing behavior. It clearly communicates that the tool deletes all app data and clears cache, which is a strong destructive signal. However, it does not mention irreversibility, required permissions, or whether the app remains installed, though the 'resets app' phrasing partially implies this.
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 immediately states the action and then adds a clarifying parenthetical, making it highly scannable.
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 only two parameters and no output schema, the description adequately covers the core behavior and context. It clearly explains what is deleted and the result (clean state), but could be more complete with usage guidance or mention of the tool's effect on app installation.
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 covers 100% of parameters with descriptions, including an example for packageName. The tool description adds no additional parameter semantics beyond what the schema already provides, 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 clearly states the verb 'Delete' and the resource 'all data associated with a package,' making the tool's function unambiguous. The parenthetical 'resets app to clean state, clears cache' also distinguishes it from sibling tools like uninstall_app and force_stop_app.
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 phrase 'resets app to clean state' implies a use case but does not explicitly state when to use this tool versus alternatives like uninstall_app or force_stop_app. No exclusions or alternative recommendations are provided.
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 burden. It clearly states the destructive effect (clearing/flushing buffers) and the practical intent (discarding logs). However, it doesn't mention irreversibility, device scope, or any prerequisites, leaving some behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, focused sentences. The first states the action and resource; the second explains when to use it. No redundant or filler content.
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 one-parameter destructive tool with no output schema, the description is sufficient: it names the action, the resource, and a typical use case. The optional serial parameter is explained in the schema, and the description's 'all current' clarifies scope.
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 already covers the single optional parameter 'serial' with a description, giving 100% coverage. The tool description adds no extra meaning about this parameter, which is acceptable at the baseline but not enhanced.
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 specific verbs ('Clear', 'flush') and identifies the exact resource ('all current logcat buffers'), clearly distinguishing this destructive action from read-only siblings like get_logcat.
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 a clear use case: run before a test to discard old irrelevant logs. It doesn't explicitly mention alternatives or when not to use it, but the context is unambiguous for a simple utility tool.
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 disclosing behavioral traits. It indicates 'snapshot' which suggests a non-streaming, non-destructive read operation, but it does not explicitly state that it is read-only, what the output format is, or any potential side effects or prerequisites (e.g., device connection). The description offers some insight but not comprehensive 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, well-structured sentence that is front-loaded with the main action ('Dump a snapshot') and concisely mentions the key customization options. Every word earns its place, with no redundancy or filler. It is appropriately sized for the simple function it describes.
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 covers the essential function and main parameters. It lacks explicit mention of the return value or device targeting, but the schema fills these gaps with parameter details. The absence of an output schema and annotations means the description could do more to specify the output format, but the overall context is sufficient for a tool 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 schema provides 100% coverage with detailed descriptions for each parameter, including examples for 'filterSpec'. The tool description's mention of 'custom line limits and filter criteria' merely paraphrases the schema without adding new meaning. Since the schema already does the heavy lifting, the baseline of 3 is appropriate; the description adds no significant semantic value 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 a specific verb 'dump' with a clear resource ('recent system logs (logcat)') and scope ('snapshot' with custom line limits and filter criteria). It clearly distinguishes this tool from its sibling 'clear_logcat' which clears logs rather than retrieves them. The purpose is unambiguous and well-defined.
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: it is for retrieving recent logs with configurable limits and filters. It implies the tool is the appropriate choice when such a snapshot is needed, and there is no direct alternative among the siblings for reading logs. However, it does not explicitly state when not to use it or mention alternatives like 'clear_logcat', but the intent is still clear.
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. It discloses a key requirement ('Requires a debuggable app or root') and clarifies the file location, but does not mention behavior for missing files or the exact output format (e.g., raw XML string vs. parsed structure). This is adequate but not fully transparent.
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, front-loaded with the core action and resource, followed by the essential access prerequisite. Every word earns its place, with no filler or redundancy.
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 a well-described schema, the description covers the critical information: what is retrieved, where, and the access requirement. The phrase 'XML contents' gives a clear expectation of the return value, though explicitly stating the output format (e.g., raw XML) would make it 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 already provides descriptions for all three parameters with 100% coverage, including examples for filename and packageName. The description does not add additional parameter-level details beyond what the schema 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Retrieve and read') and a specific resource ('XML contents of a specific Shared Preferences file'), clearly distinguishing it from sibling tools like list_shared_preferences and get_dbinfo. It also specifies the location scope ('inside an app's sandbox'), leaving 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'a specific Shared Preferences file' implies the tool is for retrieving known file contents, and the prerequisite 'Requires a debuggable app or root' gives context for when it can be used. It does not explicitly name alternatives or exclusions, but the contrast with list_shared_preferences (which likely lists files) is implicit.
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 full behavioral burden. It discloses the core behavior (listing active port forwards) but omits details like the optional serial filter, return format, or any side effects. This is adequate but leaves room for improvement.
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 words. It conveys the essential verb, resource, and scope efficiently.
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 low complexity (one optional parameter, no output schema), the description is mostly complete. It could mention the serial filtering behavior or return details, but the core purpose is clear and the tool is simple enough that this is minor.
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 'serial' parameter, which is described as 'Specific device serial number'. The description does not add extra meaning about how the serial parameter affects the listing, so it stays at baseline.
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 clearly identifies the resource as 'active port forwarding connections from host to device'. It distinguishes itself from sibling tools like list_reverses by specifying direction (host to device).
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 phrase 'from host to device' provides clear context for when to use this tool versus list_reverses (device to host). However, it does not explicitly name alternatives or state when not to use it.
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?
No annotations are provided, so the description carries the full burden. It states the main behavior and the platform limitation, but does not disclose potential side effects like disconnecting the adb session or requiring prior root status. This is adequate but not rich.
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?
Two succinct sentences: the first states the action, the second gives a crucial caveat. No wasted words, and the most important 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?
For a tool with one optional parameter and no output schema, the description covers purpose and a key prerequisite. It lacks details on side effects, but the simplicity of the tool keeps it reasonably 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 covers the only parameter (serial) with a clear description, and the tool description adds no additional parameter meaning. With 100% schema coverage, a baseline of 3 is appropriate; the description does not need to compensate.
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 ('Restart the adbd daemon') and the context ('with root permissions'), distinguishing it from siblings like reboot_device and unroot_device. The verb and resource are 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?
The description provides a clear prerequisite ('Only works on userdebug/eng builds or rooted devices') which helps the agent decide when to use it. It does not explicitly mention alternatives or exclusions, but the context is sufficient for a simple tool.
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 must convey behavioral traits. It discloses the key prerequisite (emulator vs physical device setup) and implies a state change on the device. However, it doesn't mention whether location services need to be enabled, if the change is reversible, or any side effects, leaving some transparency gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core action, and every sentence earns its place. It efficiently conveys both the purpose and the important usage caveat without unnecessary fluff.
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 setter tool with no output schema, the description covers the core functionality and crucial prerequisite. It doesn't detail return values or error handling, but overall it is reasonably complete for the tool's simplicity.
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, with 100% coverage. The tool description adds no param-specific meaning beyond what the schema offers, so the baseline 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 states the tool's function: 'Set a mock GPS location (latitude and longitude) on the device.' The verb 'Set' and resource 'mock GPS location' are specific, and no sibling tool has a similar purpose, making it easily distinguishable.
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 explicit usage conditions: 'For emulators, this works directly. For physical devices, you must configure a Mock Location App in Developer Options first.' This gives clear context on when and how to use the tool, though it doesn't mention alternatives or when not to use it.
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 disclosure. It adds useful context about the default launcher activity behavior, but it does not mention failure cases (e.g., app not installed), whether the call blocks, or any prerequisites. This is partial 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 concise: two sentences with no redundant information. It front-loads the core purpose and immediately follows with a useful behavioral detail. 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 launch tool with three well-documented parameters and no output schema, the description covers the essential function and the key nuance of default activity behavior. It could mention error handling or prerequisites, but the level of detail is appropriate for this tool.
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 parameters at 100% coverage, so the baseline is 3. The description adds value by explaining the optionality of activityName and what happens if it is omitted, which is not explicitly clear from the schema alone.
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 and resource: 'Launch an app or a specific activity on the device.' This distinguishes it from sibling tools like install_app or force_stop_app, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 launch an app or specific activity) and even mentions the fallback behavior when no activity is provided. However, it does not explicitly mention exclusions or alternative tools, so it stops short of 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, the description carries the full burden. It transparently discloses what the command returns (serial numbers, connection status, and device details). The read-only nature is evident from the verb 'List,' and no side effects or special behaviors are hidden.
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, well-structured sentence that front-loads the action and resource, then adds enumerative detail. Every word earns its place, with no redundant or vague language.
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?
For a parameterless listing tool, the description is fully complete. It specifies the scope (all connected), the item type (devices and emulators), and the included fields. No output schema exists, but the description sufficiently indicates what the result will contain.
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 score is 4. There is no parameter detail to add beyond the schema, and the description correctly focuses on the tool's output rather than inputs.
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 opens with the specific verb 'List' and identifies the resource 'all connected Android devices and emulators.' It further specifies the included details (serial numbers, connection status, product, model, device, transport), which clearly distinguishes this tool from the many device-action siblings like reboot_device or get_device_state.
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 clearly implies its use as an enumeration tool, providing clear context that it lists all connected devices. It does not explicitly name alternatives or state when not to use it, but the purpose is self-evident, and the lack of exclusions is acceptable for a simple listing tool.
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. It discloses the key behavioral distinction: if savePath is provided, the file is saved locally; otherwise, the image is returned to the client. This is helpful context beyond the schema, though it does not cover device selection or error conditions.
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?
Two concise sentences, front-loaded with the primary action and followed by a clear conditional. Every word earns its place; no redundancy or filler.
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?
For a simple tool with two optional parameters and no output schema, the description covers the primary behavior and the return type (PNG image). It is complete enough for an agent to use correctly without additional context.
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?
Schema coverage is 100%, so parameters are already documented. The description adds meaning by explaining the consequence of providing savePath (saves to host) versus omitting it (returns PNG directly), which is not fully captured in the schema descriptions alone.
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 'Capture the device screen' with a specific verb and resource. It distinguishes itself from siblings like record_screen (video) and dump_ui_hierarchy (UI layout) by focusing on the screenshot capture and the conditional output behavior.
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 clarifies when to use it: whenever a screenshot is needed. It also provides guidance on choosing between saving to the host (via savePath) vs. returning the image directly to the client, though it does not explicitly contrast with alternative tools.
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/abhinav7895/adb-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server