Android MCP Server

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, but there is some overlap that could cause confusion. For example, 'analyze_screen', 'capture_screenshot', and 'get_ui_tree' all involve screen capture and analysis, with 'analyze_screen' combining both visual and UI tree aspects, potentially making it ambiguous when to use each. Similarly, 'click_element' and 'smart_click' both handle clicking, though 'smart_click' is described as more reliable with fallback strategies, which helps differentiate them. Overall, the tools are well-defined, but a few overlaps exist.
Naming Consistency5/5
Tool names follow a highly consistent snake_case pattern with clear verb_noun structures throughout, such as 'analyze_screen', 'click_element', 'get_device_info', and 'list_apps'. There are no deviations in naming conventions, making it easy to predict and understand tool purposes based on their names.
Tool Count3/5
With 37 tools, the count is borderline high for an Android automation server. While it covers a wide range of functionalities from UI interaction to file management and testing, it may feel heavy and overwhelming for agents to navigate efficiently. A more focused set of 15-25 tools might improve usability without sacrificing core capabilities.
Completeness5/5
The tool set provides comprehensive coverage for Android automation, including UI interaction (e.g., click, swipe, input), device management (e.g., install, uninstall, get info), file operations (e.g., push, pull, list), testing support (e.g., run_test_scenario, assert_element_exists), and recording features. There are no obvious gaps; it supports full lifecycle operations from app installation to UI testing and performance monitoring.
Average 3.7/5 across 37 of 37 tools scored. Lowest: 2.9/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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.json to 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 full burden but discloses minimal behavioral traits. It doesn't state whether installation overwrites existing apps, requires debug mode, what happens if device_id is omitted (default device selection), or describe success/failure indicators for this mutation operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence that is front-loaded with the action and contains no redundant or wasted words. However, the brevity borders on under-specification given the lack of annotations and output schema, though this primarily impacts completeness rather than conciseness of the existing text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation operation (installing apps) with no annotations and no output schema, the description is insufficient. It lacks critical context: error handling behavior, prerequisites (developer mode, APK signatures), side effects (app replacement vs fresh install), and return value semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'local file path' which aligns with the local_path parameter, but adds no semantic details beyond the schema such as path format requirements, APK validation, or device_id selection behavior when multiple devices are connected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific verb 'Install' and resource 'APK file' with clear scope ('onto the Android device'). It implicitly distinguishes from siblings like push_file by specifying 'APK' and 'Install' versus generic file transfer, though it doesn't explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus push_file (which transfers files without installing) or prerequisites like device connectivity/APK compatibility. No mention of when installation might fail or require specific permissions.
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 provided, so description carries full burden of behavioral disclosure. It fails to mention that this executes mutations on the device state (side effects), whether it blocks until completion, error handling behavior (despite having a stop_on_error parameter), or idempotency characteristics. 'Replay' implies execution but lacks safety or behavioral specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of six words with no redundancy. Information is front-loaded and dense. While underspecified overall, the brevity itself is structurally optimal for the content provided.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Inadequate for a complex 4-parameter mutation tool with no output schema and no annotations. Missing critical context: supported recording formats, whether the device must be in a specific state, what determines success/failure, and how this relates to the broader recording workflow implied by sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params documented). The description adds no parameter-specific context, but meets baseline expectations since coverage is moderately high. However, it does not compensate for the undocumented 'stop_on_error' parameter, which has no schema description and no mention in the text regarding its error-handling semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb (replay) and resource (action sequence). The phrase 'previously recorded' effectively distinguishes this from siblings start_recording and stop_recording. However, it omits the context that this executes UI automation on a device, which would strengthen clarity given the tool's ecosystem.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use versus alternatives (e.g., run_test_scenario or individual actions like click_element), nor prerequisites such as requiring an existing recording created via start_recording. The description is purely definitional without operational 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 provided, the description carries the full burden of behavioral disclosure. While 'force-stop' is technically accurate for Android, the description lacks critical context about side effects (data loss, cleared state, background service termination) or requirements (root/ADB privileges).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is appropriately sized and front-loaded with the action verb. It contains zero redundancy or filler—every word earns its place by conveying the core operation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with complete schema documentation and no output schema, the description is minimally adequate. However, given the lack of annotations and the destructive nature of force-stopping processes, the description should disclose behavioral implications to be considered complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the baseline is 3. The description mentions 'by its package name' which aligns with the package_name parameter but adds no syntax details, format examples, or semantics for the optional device_id parameter beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (force-stop) and target (Android application) using a specific technical verb. It implicitly distinguishes from siblings like 'open_app' and 'uninstall_app' through the verb choice, though it doesn't explicitly name alternative tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like 'open_app' or prerequisites such as requiring ADB access or device permissions. It fails to mention when force-stopping is appropriate versus other termination methods.
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 states 'Upload' implying a write operation, but fails to disclose critical behavioral traits such as whether existing files are overwritten, if parent directories are created automatically, or what error conditions might occur.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence of ten words. Every word contributes essential information (action, resource, source, destination) with no redundancy or filler content, and the action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a three-parameter file transfer operation with no output schema and no annotations, the description meets minimum viability by identifying the core operation and endpoints. However, it lacks important context for a destructive-capable operation (overwrite behavior, return value) that would be necessary for robust agent usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for all three parameters (local_path, remote_path, device_id), establishing a baseline score of 3. The description adds directional context ('from local machine to Android') but does not provide additional syntax constraints, validation rules, or examples beyond what the schema already documents.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb (upload), resource (file), and directionality (local machine to Android device). However, it does not explicitly distinguish from the sibling tool `pull_file` by name or explicitly contrast the upload vs download directions, only implying it through prepositions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives (e.g., `pull_file` for the reverse direction), nor does it mention prerequisites such as requiring a connected device or existing parent directories on the remote path.
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. 'List all' implies a safe read-only operation, but fails to disclose what 'all' encompasses (session vs. persistent storage), return format, or behavior when no recordings exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single efficient sentence with zero waste. Every word earns its place by identifying the action and target resource. Appropriate length for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the input side is fully covered (no params), there is no output schema provided. The description omits what the tool returns (recording names? IDs? metadata?), which is critical information for an agent intending to use 'replay_recording' with these results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool accepts zero parameters and schema coverage is 100% (of empty schema). Per scoring rules, 0 parameters warrants baseline score of 4. No additional parameter semantics are needed or provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific verb 'List' and resource 'saved action recordings/macros' clearly. The term 'macros' helps clarify the domain, but it doesn't explicitly distinguish this viewing operation from sibling execution tools like 'replay_recording' or capture tools like 'start_recording'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives. Given siblings like 'replay_recording', 'start_recording', and 'stop_recording', the description should clarify this is for retrieval/inspection rather than execution or capture.
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 disclosure burden. It successfully signals behavioral traits through 'tracked state,' 'history,' and 'recent actions,' indicating temporal accumulation rather than a single snapshot. However, it omits safety considerations (though likely read-only), return format structure, or history retention limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero redundancy. It front-loads the core action and resource in the first sentence and follows with usage context in the second. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool returns complex structured data (three distinct data types) but lacks an output schema. The description partially compensates by listing the three returned components (app, history, actions), but does not describe the data structure, types, or relationships between these fields, leaving significant gaps for an agent attempting to parse the response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage (device_id is documented as 'Device serial number'), establishing a baseline of 3. The description implies device targeting but does not add syntax details, validation rules, or explain the default 'default' value behavior beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('tracked state of a device') and clearly enumerates the three components returned: current app, screen history, and recent actions. The term 'tracked' effectively distinguishes it from sibling tools like get_device_info (likely static) and get_current_app (snapshot only).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While it mentions the tool is 'Useful for understanding context,' it provides no explicit guidance on when to select this tool versus similar siblings like get_current_app, get_ui_tree, or get_device_info. Given the large number of overlapping device-query tools available, the lack of selection criteria is a significant gap.
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. While it states the installation prerequisite, it fails to describe error behavior if the app is missing, whether the operation is synchronous, or what occurs when the optional device_id parameter is omitted.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two sentences with zero redundancy: the first front-loads the action and primary parameter, while the second states the critical prerequisite. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with full schema coverage but no output schema or annotations, the description covers the essential prerequisite but leaves gaps regarding default device selection behavior (when device_id is omitted) and failure modes, making it adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description reinforces the package_name example from the schema but adds no additional semantic context about the device_id parameter's behavior when omitted or valid formats beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Launch'), target resource ('Android application'), and mechanism ('by its package name'), effectively distinguishing it from sibling tools like close_app or install_apk through the verb choice and prerequisite clause.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear prerequisite ('The app must be installed') indicating when not to use the tool, but lacks explicit guidance on alternatives (e.g., 'use install_apk if not installed') or differentiation from related app-management tools like get_current_app.
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 provided, so description carries full burden. States the action but fails to disclose mutation effects (e.g., HOME backgrounds app, POWER locks screen), error behavior for invalid keycodes, or that device_id omission likely uses default device.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence for action definition followed by targeted example list. No redundancy or filler; every word earns its place. Efficiently front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a 2-parameter tool with no output schema, covering basic functionality. However, gaps remain regarding optional parameter defaults (device_id), side effects of specific keys, and error handling scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with keycode already documented as accepting names or numeric codes. Description expands the example list beyond the schema's examples, adding some value, but baseline 3 is appropriate given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific action (press) and target (hardware/software key) with concrete examples (HOME, BACK, POWER) that distinguish it from siblings like tap, click_element, or input_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage through examples of hardware keys, but lacks explicit guidance on when to choose this over tap/click_element for navigation or input_text for text entry. No prerequisites or error conditions 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 full behavioral disclosure burden. It fails to specify critical file operation behaviors: overwrite behavior for existing local files, handling of binary vs. text files, permission preservation, or error conditions (e.g., remote file not found). 'Download' implies a read operation but lacks safety or side-effect details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 11 words with no redundancy. The action is front-loaded ('Download'), and every word serves to define scope or directionality. Efficient and unambiguous.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a file transfer tool with no output schema and no annotations, the description is minimally viable. It covers the basic operation but omits behavioral specifics (overwrite, error handling) that would be necessary for robust agent usage. The 100% schema parameter coverage compensates partially for the lack of operational detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema fully documents all three parameters ('Absolute path on the Android device', 'Local filesystem path'). The description reinforces the semantics by stating the transfer direction ('from...to'), but adds no additional syntax constraints, path format requirements, or examples beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Download'), clear resource ('file'), and explicit directionality ('from the Android device to the local machine'). This scope clearly distinguishes it from sibling tool 'push_file' and UI automation tools like 'click_element' or 'list_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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the directional language ('from Android to local') implicitly signals when to use this tool versus 'push_file', there is no explicit guidance on prerequisites (e.g., device connection state), error handling, or explicit cross-reference to sibling alternatives.
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 disclosure burden. While it specifies 'tap its center' (behavioral detail), it lacks critical information: failure behavior if element not found, handling of multiple matches, timeout/wait behavior, side effects, or whether the action is destructive. For a state-modifying UI tool, this is insufficient behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Exactly two sentences with zero waste. The first sentence front-loads the core action; the second provides comparative context. Every word earns its place in guiding tool selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (9 nested selector criteria, state-changing action, no output schema, no annotations), the description is incomplete. It omits error handling, return values, visibility requirements, and multi-match resolution strategy—all critical for a UI automation tool with rich selection logic.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description references 'selector' generically but does not add semantic context about selector syntax, precedence of matching criteria, or practical examples beyond what the schema's property descriptions already provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool 'Find a UI element matching the selector and tap its center,' providing specific verb (find/tap), resource (UI element), and scope. It explicitly distinguishes from sibling tool `tap` by noting this is preferred 'rather than using raw coordinates.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance by stating this is the 'preferred way to interact with UI elements rather than using raw coordinates,' establishing when to use this over coordinate-based alternatives. However, it does not address when to use this versus siblings like `smart_click`, `double_tap`, or `long_press`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the full burden. It successfully explains the mechanism (screenshots + UI tree) and return value (list with coordinates/descriptions), but fails to disclose safety properties (read-only vs. destructive), side effects, or performance characteristics that would help an agent assess invocation risks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of three efficient sentences with zero redundancy: the first defines the action and method, the second specifies the return value, and the third provides usage context. Information is front-loaded appropriately.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of an output schema, the description appropriately compensates by detailing the return structure ('list of all clickable/focusable elements with their coordinates'). It covers the tool's primary function adequately, though it could strengthen completeness by clarifying the read-only nature of the operation given the lack of safety annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for its single parameter ('Device serial number'), establishing a baseline of 3. The description adds no additional parameter context (e.g., where to obtain the device ID or validation rules), but this is acceptable given the schema's completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects interactive elements using a specific method (screenshots + UI tree analysis) and implies comprehensive coverage ('all clickable/focusable elements'). However, it does not explicitly distinguish this from the sibling tool 'find_element', which likely serves a similar but more targeted purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes an explicit 'Use this when' clause ('when you need to find elements to interact with'), providing positive guidance. However, it lacks negative constraints ('do not use when...') or named alternatives (e.g., when to prefer 'find_element' or 'get_ui_tree' instead).
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 burden but omits critical behavioral details: timing between taps, coordinate system (pixels, origin), what happens if coordinates are out of bounds, or whether it waits for UI animations to complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. The core action is front-loaded in the first sentence, while the second provides contextual use cases without verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (3 simple parameters) and 100% schema coverage, the description is adequate, though it could improve by specifying the coordinate system (e.g., screen pixels) and default behavior when optional device_id is omitted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with basic descriptions ('X coordinate', 'Device serial number'), establishing a baseline of 3. The description mentions 'specific coordinates' reinforcing x/y parameters but does not elaborate on coordinate system details, optional device_id defaults, or valid value ranges.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the exact action (double tap), target (Android screen), and mechanism (specific coordinates), clearly distinguishing it from siblings like 'tap' (single), 'long_press', and 'click_element' (which likely uses selectors rather than coordinates).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides implied usage through examples (zooming, selecting text) but lacks explicit guidance on when to prefer this over 'tap' or when to use coordinate-based vs element-based tools like 'click_element' or 'smart_click'.
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. It compensates partially by listing specific return fields (model, Android version, etc.) since no output schema exists, but fails to disclose safety properties (read-only vs destructive), error conditions (what if device_id is invalid?), or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action verb and immediately specifies the resource and return attributes. No words are wasted, and the structure is appropriately dense for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter) and lack of output schema, the description appropriately compensates by enumerating the specific device attributes returned. It could be improved by noting error conditions (e.g., device not connected) or relationships to list_devices, but is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage for the single optional parameter, the schema adequately documents the device_id parameter and its default behavior. The description adds no additional parameter semantics, meeting the baseline expectation for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('connected Android device'), and distinguishes from siblings like get_device_state and get_screen_size by enumerating specific static fields returned (model, Android version, SDK version, etc.), clarifying this retrieves hardware/software metadata.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like list_devices (which likely enumerates available devices first) or get_device_state (which probably returns dynamic runtime data). It does not mention that device_id can be obtained from list_devices or prerequisites for use.
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 partially compensates by disclosing return values ('Returns file names, types, sizes, and permissions'), which is critical given the lack of output schema. However, it omits safety characteristics (read-only vs destructive), error handling for invalid paths, and whether hidden files are included.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. The first sentence front-loads the action and target, while the second sentence addresses the return value. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter listing tool without output schema, the description is reasonably complete. It compensates for the missing output schema by detailing the return structure. It could be improved by mentioning error cases (e.g., permission denied, path not found) given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already fully documents both parameters (path with example, device_id as serial number). The description references 'given path' and 'Android device' but adds no semantic meaning beyond what the schema already provides, warranting the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb (List) and resource (files and directories) with scope (at a given path on the Android device). It effectively distinguishes from siblings like pull_file (which retrieves content) and list_apps (which lists applications rather than filesystem entries).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that this is for browsing directories before using pull_file, or caution against using it for listing installed applications (which requires list_apps).
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. It discloses return values ('percentage of pixels that changed and whether the screen has significantly changed'), but omits critical behavioral details: error handling when no previous screenshot exists, whether the comparison updates the reference screenshot, and any side effects like saving diff images.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently structured: first defines the action, second specifies return values, third states the use case. No redundancy or filler. Front-loaded with the core comparison concept.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool without output schema, the description adequately compensates by describing return values. However, it fails to mention the critical state dependency—that this tool requires a previously captured screenshot to exist—and what happens if called without one, which is essential for correct invocation sequencing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description mentions 'significantly changed' which loosely maps to the threshold parameter's purpose, but adds no syntax details, valid ranges, or semantic context beyond what the schema already provides for device_id or threshold.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (compare current screen with previously captured screenshot) and the resource (screenshots). It effectively distinguishes from sibling capture_screenshot by emphasizing the comparison with a previously captured state rather than capturing new.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides implicit usage context ('Useful for verifying that an action had an effect'), indicating when to use it. However, it lacks explicit prerequisites (requires a prior screenshot to exist), does not mention error conditions if none exists, and does not contrast with alternatives like analyze_screen.
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. It successfully discloses the composite return type (visual + text), but omits operational details like whether this is a read-only operation, performance costs relative to single-mode alternatives, or return format specifics (file paths vs base64 vs objects).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three efficiently structured sentences: action definition, return value specification, and usage context. Each earns its place with no redundancy or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of output schema, the description adequately explains the return values (screenshot + UI tree summary). However, it could improve by specifying return formats (e.g., base64 encoded image, JSON tree structure) or mentioning the optional nature of the device_id parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% description coverage for the single device_id parameter. The description does not mention parameters, but with complete schema documentation, the baseline score of 3 is appropriate as no additional parameter semantics are required from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool captures a screenshot and returns both visual and UI tree data, distinguishing it from siblings like capture_screenshot (likely image-only) and get_ui_tree (likely text-only). The specific dual-return nature is explicitly documented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use this when you need to understand the full screen context' which provides a when-to-use hint, but lacks explicit comparison to siblings or guidance on when to use the simpler capture_screenshot or get_ui_tree alternatives instead.
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, description carries burden of disclosing behavior. It clarifies specific return value type (package name vs. app label or activity) and target state (focused/foreground). However, omits read-only safety confirmation, error conditions (no device connected), or return format details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence (11 words) with zero waste. Front-loaded with action verb and resource identifier. No redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for simple single-parameter tool. Specifies return value concept (package name) despite lack of output schema. Could marginally improve by indicating return type (string) or null behavior when no foreground app exists, but sufficient for tool complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% ('Device serial number'), establishing baseline 3. Description adds no parameter context, but none is required given complete schema documentation. Does not clarify device_id selection when multiple devices present, though this is minor.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with clear resource 'package name of the currently focused/foreground Android application'. Effectively distinguishes from siblings like 'list_apps' (all apps) and 'get_device_info' (hardware) by specifying 'currently focused/foreground' scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage context through 'currently focused/foreground' qualifier, suggesting use when identifying active applications. However, lacks explicit when-to-use guidance comparing it to alternatives like 'get_ui_tree' or 'analyze_screen', and no prerequisites mentioned.
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, description carries full burden. It discloses return content (per-tool latency, success/failure counts, action history) but omits safety profile (read-only vs destructive), rate limits, or authentication requirements that annotations would typically cover.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First establishes scope (MCP server), second specifies metric types (latency, counts). Front-loaded and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool without output schema, description adequately compensates by enumerating specific metric categories returned. Minor gap on return format structure, but sufficient for agent selection given the tool's observational nature.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema contains zero parameters. Per scoring rules, zero parameters warrants baseline score of 4. Description appropriately does not fabricate parameter details where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses specific verb 'Get' with clear resource 'performance metrics and action history for the MCP server'. Explicitly distinguishes from mobile automation siblings by specifying it targets the MCP server itself, not the device under test.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to invoke this tool (e.g., after test runs, during debugging) or when not to use it. No alternatives mentioned, though none exist in the sibling set, explicit context for invocation timing is absent.
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 specifies the return format (width x height in pixels) and target (connected Android device), but omits error handling (no device connected, multiple devices), return schema structure, or whether this requires ADB shell permissions. Just meets minimum viable disclosure for a read-only 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Front-loaded with the action and resource, parenthetical clarification of format (width x height in pixels), and scope (connected Android device). Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-purpose getter with 100% schema coverage and no output schema, the description is appropriately complete. It compensates for missing output schema by specifying the return format (width x height in pixels). Minor gap: does not specify primary vs. secondary display handling for multi-screen devices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage for the device_id parameter ('Device serial number. If omitted, uses the only connected device.'). The description adds no parameter-specific context, but per guidelines, the baseline is 3 when schema coverage is high (>80%).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb ('Get'), clear resource ('screen resolution'), and precise scope ('width x height in pixels of the connected Android device'). This clearly distinguishes the tool from siblings like capture_screenshot (image), analyze_screen (content), and get_device_info (general hardware info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the purpose is clear enough to imply usage (whenever display dimensions are needed), the description lacks explicit guidance on when to use this versus get_device_info which may also return display metrics, or how it behaves when multiple devices are connected. No 'when-not-to-use' 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?
No annotations provided, so description carries full burden. It successfully discloses the default filtering behavior (third-party vs system), but omits output format details, pagination behavior, or permission requirements that would help predict the response structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. First sentence declares purpose; second sentence declares default behavior. Every word earns its place and critical information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a simple 2-parameter listing tool with full schema coverage. Covers core functionality and filtering logic. Minor deduction for lacking any hint about return value structure (package names, versions, etc.) given no output schema exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% description coverage (device_id and include_system both documented), establishing baseline 3. The description adds context that 'third-party apps' are shown by default, reinforcing the include_system=false semantics, but doesn't elaborate on device_id format or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'List' + resource 'installed applications' + context 'Android device'. The default behavior 'third-party apps only' clearly distinguishes it from generic app queries and siblings like get_current_app (single app) or install_apk (modification).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implied usage guidance by stating the default filter (third-party only), hinting when to use include_system=true. However, lacks explicit when-not-to-use guidance or named alternatives (e.g., doesn't clarify to use get_current_app for foreground app details).
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 minimally indicates the tool returns version information and filters for 'loaded' plugins, but lacks details on output format, pagination, or whether this triggers any server-side state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the action verb. Every element serves a purpose: 'List' (action), 'all loaded' (scope filter), 'MCP server plugins' (resource), and 'their versions' (specific data points returned).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (zero parameters, simple listing operation) and absence of an output schema, the description is sufficiently complete to enable tool selection. However, it could have briefly indicated the return structure (e.g., array of objects) to fully compensate for the missing output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema contains zero parameters, so there is no additional parameter semantics to convey beyond the baseline. The description appropriately does not invent parameters where none exist.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' with the clear resource scope 'loaded MCP server plugins and their versions.' It effectively distinguishes itself from siblings like list_apps, list_devices, and list_files by explicitly mentioning 'MCP server plugins' rather than device-side entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention prerequisites or conditions where it might be preferred over other listing tools like list_apps.
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. It discloses the return format ('detailed pass/fail results per step') and execution order ('ordered'), but omits critical behavioral details like the stop_on_failure semantics, whether failed assertions halt execution, or side effects on device state.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-constructed sentences with zero waste. First sentence front-loads core functionality (execution + assertions), second sentence covers output contract. Appropriate length for the complexity level.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema exists, the description adequately explains return values ('pass/fail results per step'). For a complex orchestration tool with nested step definitions, it covers the essential contract, though mentioning execution flow control (stop_on_failure) would improve completeness given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 75% (3 of 4 params described). The description adds valuable semantic context for the complex 'steps' structure, explaining that each step 'performs an action and optionally verifies the result,' which helps interpret the nested action/args/assert structure. Does not compensate for the undocumented stop_on_failure parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific verb (Execute), resource (test scenario), and key capabilities (ordered steps, assertions). It effectively distinguishes this from single-action siblings like tap or click_element by emphasizing 'multiple steps' and 'scenario' orchestration.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this composite tool versus individual action tools (tap, swipe, click_element) available as siblings. No mention of prerequisites or when to prefer this over replay_recording for automation.
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 disclosure burden. It successfully notes the persistence behavior ('save it to disk'), but omits error handling (what happens if no active recording exists?), synchronization characteristics, and whether it returns file metadata or path.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Information density is high: action (Stop), scope (active), target (recording), and side effect (save to disk) are all front-loaded and essential.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a single-parameter tool with no output schema. Captures core functionality and persistence. Minor gap regarding error state behavior when no recording is active, which would be useful given the lack of annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% ('Recording ID from start_recording'), so the baseline applies. The description itself does not add parameter semantics beyond the schema, but the schema is self-sufficient for the single required parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb (Stop), target resource (active recording), and side effect (save to disk). It clearly distinguishes from sibling tools like start_recording, replay_recording, and list_recordings by emphasizing 'active' and the persistence action.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'active recording' implies prerequisite state (recording must be in progress), and the schema references start_recording. However, there is no explicit guidance on when to use versus alternatives, error conditions if called without an active recording, or sequencing requirements.
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 clearly describes the core action (coordinate-to-coordinate swipe) and gesture types, but omits behavioral details like error handling (what happens if coordinates are out of bounds), blocking vs. async execution, or whether the action wakes a sleeping device.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. It is front-loaded with the core action ('Swipe from one point to another') followed immediately by use case guidance, making it easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (6 parameters, simple action) and complete parameter documentation in the schema, the description is sufficiently complete. It could be improved by mentioning success/failure behavior or coordinate system details (absolute vs. relative), but these are minor gaps for a gesture automation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already clearly documents all parameters (start/end coordinates, duration, device_id). The description aligns with this by mentioning 'from one point to another,' but does not add significant semantic meaning, syntax examples, or constraints beyond what the schema provides. Baseline 3 is appropriate for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Swipe') and resource ('Android screen'), clearly defining the tool's function. It effectively distinguishes from sibling tools like 'tap', 'click_element', and 'long_press' by specifying this is for continuous gestures between two points.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists appropriate use cases ('scrolling, swiping between pages, or drag gestures'), giving positive guidance on when to use the tool. However, it lacks explicit negative guidance ('when not to use') or named alternatives (e.g., 'use tap for single clicks instead').
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. It adds valuable behavioral context about coordinate scaling ('will be scaled to screen size'), but lacks disclosure of side effects, error behaviors (out-of-bounds coordinates), or whether the operation is idempotent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero redundancy: the first establishes the core action, and the second provides critical implementation details about coordinate formats. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description adequately covers the input parameters but omits expected return values, success/failure indicators, or error conditions that would help the agent handle the tool's output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 100% description coverage (baseline 3), the description adds meaningful semantic context about the coordinate value ranges (0-1 normalization) and runtime behavior (scaling), enhancing understanding beyond the schema's basic type definitions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Tap') and target ('specific coordinates on the Android screen'), effectively distinguishing it from sibling tools like click_element (which implies element-based targeting) and double_tap/long_press (which imply different gesture 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
While the description explains HOW to specify coordinates (absolute pixels vs normalized 0-1 range), it does not explicitly state WHEN to use this tool versus coordinate-based siblings (double_tap, long_press) or element-based alternatives (click_element).
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 full burden. It effectively discloses key behavioral traits: returns only the first match, returns properties and bounds, and implies a read-only operation. Could improve by mentioning error behavior when no element is found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences: first defines the action, second specifies return behavior (first match, properties/bounds), third provides usage context. Zero redundancy; every sentence earns its place with information not duplicated in schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates well for missing output schema by describing return values (properties and bounds). Covers the essential behavioral context for a 2-parameter tool with 100% input schema coverage. Minor gap regarding error handling when no match exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, providing detailed descriptions for all selector sub-properties and device_id. The description references 'selector criteria' which aligns with the schema but adds minimal semantic meaning beyond the structured definitions. Baseline score appropriate given schema completeness.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the specific action (Find), resource (UI element on Android screen), and mechanism (selector criteria). It distinguishes from interaction siblings like click_element by emphasizing this is for locating components before interacting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides implicit workflow guidance ('before interacting with it'), suggesting when to use it in the sequence. However, it lacks explicit alternatives or exclusions (e.g., when to use wait_for_element instead, or when to use detect_elements_visually for visual matching).
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 successfully discloses the critical behavioral constraint that the field must be focused first. However, it lacks details on error behavior (what happens if not focused), side effects, or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with zero waste. The first sentence front-loads the action and target; the second sentence provides the essential 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/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 2-parameter tool with 100% schema coverage and no output schema, the description adequately covers the essential domain-specific constraint (Android focus requirement). It could be improved by mentioning error handling or success indicators, but it is sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, establishing a baseline of 3. The description implies the 'text' parameter ('Type text') and 'device_id' context ('Android device'), but does not add syntax details, format constraints, or examples beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description provides a specific verb ('Type'), target resource ('currently focused input field'), and context ('Android device'). It clearly distinguishes from siblings like 'press_key' (individual keys) and 'tap'/'click_element' (focusing actions) by emphasizing the text-input-on-focused-field 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states the prerequisite condition ('The field must already be focused') which implies the necessary workflow sequence. However, it does not explicitly name which sibling tools (e.g., tap, click_element) should be used to achieve the focused state, though 'tapped' provides a hint.
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 burden. It discloses return content ('status and model information') but omits safety profile, error behavior (e.g., empty list vs error when no devices), performance characteristics, or prerequisites like ADB connection requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with zero waste. Every clause earns its place: action ('List'), scope ('all connected'), resource ('Android devices'), and return value ('status and model information'). Front-loaded with the action verb.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (no inputs) and lack of output schema, the description adequately covers the tool's purpose and hints at return content. It could be improved by explicitly stating it returns a collection/array format, but is sufficiently complete for a discovery tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Tool has zero parameters and schema coverage is 100% (of empty schema). Per rubric, zero parameters establishes baseline of 4. No parameter semantic description is needed or expected.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description provides specific verb ('List'), clear resource ('connected Android devices'), and scope ('all'). The phrase 'all connected' effectively distinguishes this from sibling tools like get_device_info or get_device_state which likely operate on single 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through the scope 'all connected' (suggesting enumeration/discovery use case), but provides no explicit when-to-use guidance or named alternatives. It doesn't state when to prefer this over single-device query tools.
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 provided, so description carries full burden. Adds valuable behavioral context via use cases (context menus, drag initiation), but omits execution semantics like blocking behavior, failure modes, or whether the gesture includes a release 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with zero waste. First sentence front-loads the core action ('Long press at specific coordinates'), second provides usage context. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriately complete for a 4-parameter gesture tool with full schema coverage. Covers action, location paradigm, and use cases. Lacks mention of return behavior or error handling, but tool complexity is low enough that the description suffices.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (x, y, duration, device_id all documented). Description mentions 'coordinates' reinforcing x/y purpose, but adds no syntax details, format constraints, or semantic meaning beyond what the schema already provides. Baseline 3 appropriate when schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb 'Long press' combined with resource 'coordinates on the Android screen' clearly defines the action. Distinguishes from siblings 'tap' and 'click_element' by specifying 'long press' and 'coordinates' rather than elements or short taps.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear usage contexts ('context menus, drag initiation, or selection') indicating when to use the tool. However, lacks explicit comparison to alternatives (e.g., when to use 'tap' vs 'long_press') or prerequisites.
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?
Without annotations, the description carries the full burden and successfully discloses the internal strategy cascade (four fallback methods). However, it omits what happens if all strategies fail (error vs. silent failure) and whether the operation includes implicit waits or verification.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences with zero waste. It front-loads the critical technical detail (the strategy cascade) in the first sentence and provides the value proposition ('most reliable') in the second.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex multi-strategy tool with nested parameters and no output schema, the description adequately explains the mechanism. It could be improved by mentioning failure modes or timeout behavior, but the strategy disclosure provides sufficient context for an agent to understand the tool's robustness profile.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema coverage, the baseline is 3. The description mentions 'element' (mapping to selector) and 'Coordinates fallback' (mapping to fallback_x/y), but does not add semantic context beyond what the schema already provides for the eight selector sub-properties or device_id.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action (click) and target (element), and distinguishes itself from sibling tools like click_element and tap by specifying the multi-strategy cascade (UIAutomator → Accessibility → Vision → Coordinates) and claiming it is 'the most reliable way to click elements.'
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool should be used when reliability is needed ('most reliable way'), but lacks explicit guidance on when NOT to use it (e.g., when speed is prioritized over robustness) or when to prefer simpler alternatives like click_element or tap.
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 and discloses the destructive nature and server constraint via the allowDestructiveOps requirement. It fails to clarify whether app data is preserved, if the operation is reversible, or what happens when the package is not found.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of exactly two sentences with zero redundancy: the first declares the action and the second states the critical prerequisite. Information is front-loaded with the primary verb, and every word serves a necessary function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter destructive operation, the description adequately covers the essential safety guard (allowDestructiveOps) and the schema fully documents inputs. It is missing only details on failure modes and return values, which would be helpful given the lack of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema achieves 100% description coverage with 'Android package name to uninstall' and 'Device serial number,' making the parameters self-documenting. The description does not add syntax details or examples beyond what the schema provides, meeting the baseline for high-coverage schemas.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the specific verb 'Uninstall' followed by the clear resource target 'an application from the Android device,' precisely defining the scope. This effectively distinguishes the tool from siblings like close_app (which merely stops apps) or install_apk (which adds rather than removes software).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides critical usage context by stating 'Requires allowDestructiveOps to be enabled in server configuration,' establishing a necessary prerequisite. However, it lacks explicit guidance on when to prefer this over close_app for temporary shutdowns or alternatives for system apps.
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 provided, so description carries full burden. It successfully discloses critical behavioral traits: boolean return values ('true/false') and error safety ('without throwing an error'). Lacks details on timeout behavior or performance characteristics, but covers the essential safety profile for an assertion tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose declaration, return behavior, and use case guidance. Front-loaded with the core action, zero redundancy, and no tautology. Efficiently avoids repeating the 10 selector sub-properties already defined in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complex nested selector schema with 10 properties, the description appropriately focuses on behavioral semantics rather than parameter enumeration. It compensates for the missing output schema by specifying the boolean return type. Could mention timeout behavior or device_id default handling, but otherwise complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with all selector options and device_id fully documented in the schema. The description references 'selector' and 'current screen' but does not add semantic meaning beyond the structured schema, which is appropriate given the comprehensive schema coverage establishes the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the specific action ('Check'), resource ('UI element'), and scope ('on the current screen'). It effectively distinguishes from siblings like 'find_element' by emphasizing 'Returns true/false without throwing an error,' signaling this is a safe boolean check rather than a retrieval operation that might error on missing elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context with 'Useful for test assertions and conditional logic,' indicating appropriate use cases. Implicitly differentiates from 'find_element' via the 'without throwing an error' clause, though it could explicitly name alternatives like 'use find_element if you need element details.'
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 and successfully discloses the return format (base64-encoded PNG) and capabilities (can be displayed or analyzed visually). It implies synchronous capture of current state but omits prerequisites like device connection status or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: first establishes action, second discloses return format (critical given no output schema), third provides usage intent. Front-loaded with the core action and appropriately sized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Compensates effectively for the missing output schema by detailing the base64 PNG return format. With 100% schema coverage and no complex nested objects, the description provides sufficient context for tool selection, though it could mention device state requirements (e.g., screen on).
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both save_to_disk and device_id are fully described in the schema), establishing the baseline. The description does not add parameter-specific semantics, but none are needed given complete schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') with clear resource ('screenshot of the current Android device screen') and distinguishes from siblings like analyze_screen (analysis) and detect_elements_visually (element detection) by focusing on full-screen image capture.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear when-to-use guidance ('Use this to see what is currently on screen'), establishing the tool's role in visual state inspection. Lacks explicit alternative naming (e.g., when to prefer analyze_screen over capture_screenshot) or exclusion criteria.
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 and adequately discloses the return structure (properties, text, bounds, states). However, it omits operational details like required permissions (ADB/accessibility service) or performance characteristics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero waste: action definition, return value specification, and usage guidance. Information is front-loaded and each sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description compensates by detailing the return structure (elements with properties, text, bounds, states). It appropriately covers the two optional parameters for a straightforward inspection tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% (both format and device_id are fully documented in the schema), establishing the baseline score. The description adds no supplemental parameter guidance, but none is needed given the comprehensive schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Capture') with a clear resource ('UI hierarchy from the Android screen'), distinguishing it from visual capture tools like capture_screenshot by emphasizing 'structured representation' rather than image data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The statement 'This is the primary way to understand what is currently on screen' provides clear context for when to use the tool (introspection/debugging), though it does not explicitly name alternatives like capture_screenshot or analyze_screen.
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 provided, so description carries full burden. Discloses critical implementation detail: 'Polls the UI tree at regular intervals until the element is found.' This reveals the active polling mechanism vs. event-driven waiting. Missing explicit documentation of timeout failure behavior (exception vs. null return).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: (1) core function, (2) usage context, (3) implementation mechanism. Front-loaded with essential purpose. No redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Appropriate for a 3-parameter polling tool with good schema coverage. Covers the polling mechanism and timeout concept. Lacks explicit documentation of return values on success/failure, but no output schema exists to set that expectation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 100% description coverage, establishing baseline 3. Description references 'timeout period' which aligns with timeout_ms parameter, but adds no additional semantic detail about selector composition or device_id scoping beyond what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb ('Wait') + resource ('UI element') + scope ('within a timeout period'). Clearly distinguishes from immediate-action siblings like find_element or click_element by emphasizing the temporal waiting aspect.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'after navigation, loading screens, or animations.' Provides clear contextual guidance for timing-sensitive operations, though does not explicitly name alternatives like find_element for non-waiting scenarios.
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 provided, so description carries full burden. Compensates well by disclosing return values (uptime, ADB availability, device count, configuration summary) since no output schema exists. Could improve by mentioning idempotency/safety for repeated health checks.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: first defines action and scope, second documents return payload. No redundancy or filler. Every sentence delivers distinct value (purpose vs. return values).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter health check tool without output schema, the description is complete. It explains both the check performed (server + ADB) and the data returned, covering everything an agent needs to invoke and interpret results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters with empty schema (100% coverage). Baseline 4 applies as there are no parameters requiring semantic clarification beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Excellent specificity: verb 'Check' + resources 'health status of the MCP server and ADB connectivity' clearly defines scope. The mention of 'MCP server' distinguishes it from sibling device-manipulation tools (click_element, swipe, etc.) that operate on devices rather than server health.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use guidance (e.g., 'call before operations to verify connectivity' or troubleshooting scenarios). While the diagnostic purpose is clear from naming, it lacks explicit differentiation from similar state-checking siblings like get_device_info or get_device_state.
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 full burden and adequately discloses key behaviors: it explains the stateful nature (recording starts and persists), the capture scope (subsequent calls), and the persistence mechanism (requires stop_recording to save). Minor gap: doesn't mention what happens if called twice or session ends prematurely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, zero waste. Front-loaded with the core action, followed by mechanism scope, and closed with the explicit next step. Every sentence earns its place with no redundant or tangential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequately complete for a stateful recording tool with no output schema. Covers initiation, operation scope, and termination workflow. Minor gap: doesn't specify what the immediate return value indicates (success confirmation?), but the functional behavior is fully documented.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear descriptions for both 'name' and 'device_id'. The description appropriately focuses on behavioral context rather than repeating parameter details that are well-documented in the schema. Baseline 3 is correct when schema provides complete coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
States specific action ('Start recording actions') and resource ('macro') clearly. Explicitly distinguishes from sibling 'stop_recording' by stating this initiates the process while stop_recording saves, and differentiates from capture_screenshot/replay_recording by emphasizing the action-recording nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit workflow guidance: 'All subsequent tool calls will be recorded' establishes the scope, and 'Use stop_recording to save' explicitly names the complementary tool needed to complete the operation, establishing clear when-to-use boundaries.
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:

[![android_mcp MCP server](https://glama.ai/mcp/servers/divineDev-dotcom/android_mcp/badges/card.svg)](https://glama.ai/mcp/servers/divineDev-dotcom/android_mcp)

Score Badge

Copy to your README.md:

[![android_mcp MCP server](https://glama.ai/mcp/servers/divineDev-dotcom/android_mcp/badges/score.svg)](https://glama.ai/mcp/servers/divineDev-dotcom/android_mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/divineDev-dotcom/android_mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server