Android Puppeteer

by pedro-rivas

Overview Schema Related Servers Score Discussions

Python

Local

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 for Android device interaction, but 'press' and 'long_press' overlap in functionality as both handle screen touches with duration parameters, which could cause confusion. Other tools like 'get_device_dimensions' and 'get_ui_elements_info' are clearly differentiated.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structure (e.g., 'take_screenshot', 'type_text', 'scroll_element'). The naming is predictable and readable throughout the set.
Tool Count5/5
With 12 tools, this server is well-scoped for Android automation, covering essential actions like input, navigation, and media capture. Each tool serves a specific role without bloat, fitting typical automation needs.
Completeness4/5
The toolset covers core Android interaction workflows including input, navigation, and media, but lacks tools for advanced tasks like app management (e.g., install/uninstall) or system settings. Minor gaps exist, but agents can perform basic automation effectively.
Average 3.2/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it implies a read-only operation by using 'Get,' it doesn't specify if this requires specific permissions, whether it returns real-time or cached data, potential performance impacts, or error conditions. The description lacks details on output format, pagination, or rate limits, which are critical for a tool that retrieves 'all' elements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose. It avoids unnecessary words and directly states what the tool does, though it could be slightly more structured by separating high-level purpose from detailed attributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of retrieving 'all interactive UI elements' with no annotations, no output schema, and an undocumented parameter, the description is incomplete. It doesn't address how the data is returned (e.g., list format, JSON structure), what 'properties' entail, or limitations (e.g., only visible elements). For a tool with such potential scope, more context is needed to guide effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter (device_id) with 0% description coverage, and the tool description provides no information about parameters. The description doesn't mention device_id at all, leaving its purpose (e.g., targeting a specific device in multi-device contexts) unexplained. With low schema coverage, the description fails to compensate by adding meaning to the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get detailed information') and the target ('all interactive UI elements on the screen'), including specific attributes like coordinates and properties. It distinguishes itself from siblings like get_device_dimensions (which focuses on device metrics) or take_screenshot (which captures visual output), though it doesn't explicitly name these 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?
The description provides no guidance on when to use this tool versus alternatives. For example, it doesn't clarify if this is for debugging UI layouts versus interacting with elements (like press or scroll_element), or if it should be used before or after other actions. There's no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions retrieving dimensions but lacks critical details: whether this requires a connected device, what format the dimensions are returned in (e.g., pixels, resolution), if it's read-only or has side effects, or any error conditions. This leaves significant gaps for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that efficiently conveys the core purpose without unnecessary words. It is front-loaded with the key action and resource, making it easy to parse. Every part of the sentence earns its place by specifying the target (Android device/emulator screen).
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 moderate complexity (retrieving device dimensions), lack of annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't address how results are returned, what happens without a device_id, or behavioral nuances, making it insufficient for an agent to use the tool effectively without additional context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage for its single parameter 'device_id', and the tool description provides no information about parameters. It doesn't explain what 'device_id' represents, how to obtain it, or if it's optional (default is null). With low schema coverage, the description fails to compensate, leaving the parameter's meaning unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Get') and target resource ('dimensions of the Android device/emulator screen'), making the purpose immediately understandable. It doesn't explicitly differentiate from siblings like 'take_screenshot' or 'get_ui_elements_info', but the focus on screen dimensions is specific enough to avoid confusion with those 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. For example, it doesn't clarify if this should be used instead of 'get_ui_elements_info' for dimension-related queries or specify prerequisites like needing an active device/emulator. The description only states what it does, not when or why to invoke it.
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 what the tool does but doesn't describe behavioral traits such as how long the press lasts, whether it requires device connection, what happens if coordinates are invalid, or if there are side effects like triggering UI actions. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is appropriately sized and front-loaded, with every word earning its place.
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 (a screen interaction with coordinates), lack of annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't address prerequisites, side effects, error conditions, or what constitutes success, making it inadequate for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description mentions 'specific coordinates' which implies the x and y parameters, but with 0% schema description coverage and 3 total parameters (device_id, x, y), it fails to explain parameter meanings. It doesn't clarify what device_id is for, coordinate units, or valid ranges, leaving significant gaps 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 ('long press') and target ('on specific coordinates on the Android screen'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'press' or 'swipe', which might also involve screen interactions.
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 'press' (which might be a short tap) or 'swipe' (which involves movement). It lacks explicit when/when-not instructions or references to sibling tools, leaving usage context unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the recording starts and where it's saved, but lacks critical behavioral details: whether it runs in background, requires specific device states, has time limits, or how errors are handled. For a tool with potential side effects, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences with zero waste. It front-loads the core action and efficiently states the tool and outcome. Every word contributes to understanding the purpose without redundancy.
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 4 parameters with 0% schema coverage, no annotations, and no output schema, the description is incomplete. It covers the basic action but misses parameter explanations, behavioral context, and output details. For a tool that likely involves device interaction and file creation, more information is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds no information about the 4 parameters (bitrate, device_id, filename, resolution), such as their purposes, formats, or defaults. The baseline for low coverage is not met, as the description fails to explain parameters 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 ('Start recording a video') and the tool used ('using scrcpy'), with the outcome ('saved to the videos directory'). It distinguishes from siblings like 'take_screenshot' or 'stop_video' by specifying video recording. However, it doesn't explicitly differentiate from all siblings (e.g., 'get_device_dimensions' is unrelated), so it's not a perfect 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., device connection), when not to use it, or how it relates to siblings like 'stop_video' for ending recording. Usage is implied by the action but lacks explicit 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 full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this requires specific permissions, what happens if no recording is active (error vs. no-op), or any side effects like file saving. This leaves significant gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence with no wasted words, clearly front-loading the core action. It efficiently communicates the essential information without unnecessary elaboration, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (a mutation with no annotations, no output schema, and low parameter coverage), the description is incomplete. It lacks details on behavior, error conditions, or output, which are critical for safe and effective use. This is inadequate for a tool that modifies system state.
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 description adds minimal meaning beyond the schema: it clarifies that 'device_id' specifies which device's recording to stop. However, with 0% schema description coverage and only 1 parameter, the baseline is 4, but the description doesn't fully compensate by explaining format or constraints (e.g., valid device IDs), so it scores slightly lower.
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 ('Stop') and the resource ('active video recording for the specified device'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'record_video' beyond the obvious inverse relationship, which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance by implying usage when there's an active video recording to stop, but it doesn't specify when to use this versus alternatives (e.g., stopping via other methods) or mention prerequisites like needing a recording in progress. No explicit when-not or alternative guidance is included.
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 only partially discloses behavior. It mentions the duration parameter for long press but doesn't cover critical aspects like whether this requires device connection, what happens if coordinates are invalid, or if there are side effects. More behavioral context is needed for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences that directly address the tool's function and key parameter usage. Every word serves a purpose, and it's front-loaded with the core action, making it efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a screen interaction tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks information about error conditions, required device state, return values, or how it differs from similar tools like 'long_press'. More context is needed for safe and effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaningful context for the 'duration' parameter (explaining it's for long press in milliseconds), which isn't evident from the schema alone. However, it doesn't explain 'x' and 'y' coordinates or 'device_id', leaving some parameters under-specified.
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 ('Tap on specific coordinates') and the resource ('Android screen'), making the purpose immediately understandable. It distinguishes from siblings like 'long_press' by mentioning duration for long press, though it doesn't explicitly contrast with all alternatives like 'swipe' or 'scroll_element'.
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 when to use this tool ('Use duration for long press') but doesn't provide explicit guidance on when to choose 'press' versus 'long_press' or other interaction tools like 'swipe'. No exclusions or prerequisites are mentioned, leaving usage context somewhat vague.
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 for behavioral disclosure. It mentions default values for distance and duration, which is helpful, but doesn't cover critical aspects like whether this requires specific permissions, if it's destructive (e.g., could trigger unintended actions), error conditions, or what happens on success/failure. For a screen interaction tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and well-structured: a clear purpose statement followed by a bullet-like parameter explanation. Every sentence earns its place, though the parameter explanations could be slightly more concise by combining related parameters (e.g., grouping coordinate parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters with 0% schema coverage and no annotations or output schema, the description does a good job explaining parameters but has gaps. It doesn't address behavioral aspects like what the tool returns, error handling, or prerequisites. For a screen interaction tool with this complexity, more context about outcomes and constraints would be needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully compensate. It provides excellent parameter semantics: it explains that direction accepts specific string values, x1/y1/x2/y2 are for custom swipes, device_id is optional for targeting, and distance/duration have defaults with units. This adds substantial meaning beyond the bare schema properties.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Swipe horizontally or vertically on the Android screen.' This specifies the action (swipe) and target (Android screen). However, it doesn't explicitly differentiate from sibling tools like 'scroll_element' or 'long_press' that also involve screen interactions, missing full sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose directional swipes versus custom coordinate swipes, or how this differs from similar sibling tools like 'scroll_element' or 'long_press' for screen interactions. Usage context is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It mentions the default device behavior and annotation option, but doesn't describe what the tool actually returns (screenshot format, location, or how to access it), whether it requires specific permissions, or potential side effects. This is inadequate for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficiently structured in two sentences with zero wasted words. The first sentence establishes the core functionality, and the second provides important parameter guidance. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and incomplete parameter documentation (missing 'name' parameter), the description is insufficient. For a screenshot tool that presumably returns visual data, the lack of information about return values or how to access the screenshot is a significant gap.
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?
With 0% schema description coverage, the description compensates well by explaining the purpose of 'device_id' (default device behavior) and 'annotate_elements' (UI element annotations). However, it doesn't mention the 'name' parameter at all, leaving one of three parameters completely undocumented.
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 ('Take a screenshot') and resource ('specified device/emulator'), making the purpose immediately understandable. However, it doesn't explicitly distinguish this tool from potential sibling tools like 'record_video' or 'get_ui_elements_info' beyond mentioning annotation capabilities.
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 some usage context by explaining what happens when no device_id is provided (uses default device) and when to set annotate_elements=False. However, it doesn't explicitly state when to use this tool versus alternatives like 'record_video' for video capture or 'get_ui_elements_info' for UI element information.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the clear_first parameter behavior ('clears existing text before typing new text'), which is useful, but doesn't describe other important traits like error conditions (what happens if no input field is focused), permissions needed, or whether this is a read-only or mutation operation. For a tool that modifies device state, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized with a clear purpose statement followed by parameter explanations. The Args section is well-structured but could be more integrated with the main description. Every sentence adds value, though the formatting as a bullet list under 'Args:' slightly disrupts flow.
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 3 parameters with no schema descriptions and no output schema, the description does well on parameter semantics but lacks completeness for a mutation tool. It doesn't explain return values, error conditions, or behavioral constraints beyond the clear_first parameter. The description is adequate but has clear gaps for a tool that modifies device state.
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 description provides clear semantic explanations for all three parameters beyond what the schema shows (0% coverage). It explains that 'text' is 'The text to type into the input field', 'device_id' is 'Optional device ID to target specific device/emulator', and 'clear_first' controls whether to 'clears existing text before typing new text'. This fully compensates for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Type text into the currently focused input field') and target resource ('Android device/emulator'), distinguishing it from sibling tools like press, swipe, or long_press. It uses precise verb+resource language that leaves no ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage context ('currently focused input field') but doesn't explicitly state when to use this tool versus alternatives like press (for buttons) or scroll_element (for navigation). No guidance is provided about prerequisites (e.g., needing an input field focused) or exclusions, leaving usage context somewhat implied rather than explicitly documented.
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 for behavioral disclosure. It states the action but doesn't mention what happens after pressing (e.g., navigation effects, potential app state changes), whether it requires device connectivity, or any side effects. This leaves significant behavioral gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that immediately conveys the tool's purpose without any wasted words. It's perfectly front-loaded and appropriately sized for this simple 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 single-parameter mutation tool with no annotations and no output schema, the description adequately explains what the tool does but lacks important context about behavioral effects, return values, and parameter usage. It's minimally viable but has clear gaps in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description doesn't mention the 'device_id' parameter at all, but since there's only one parameter and schema description coverage is 0%, the description's focus on the core action provides adequate context. The tool's purpose is clear despite the undocumented parameter, meeting the baseline for 0-1 parameters.
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 ('Press') and the target resource ('hardware back button on the Android device/emulator'). It distinguishes itself from sibling tools like 'press' (generic) and 'long_press' by specifying the exact hardware button being targeted.
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 context (Android device/emulator interaction) but provides no explicit guidance on when to use this tool versus alternatives like 'press' for other buttons or 'swipe' for navigation. No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only states what the tool does, not behavioral traits like whether scrolling is smooth/animated, if it waits for completion, error conditions, or performance implications. It mentions default values but lacks operational context.
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?
Perfectly structured with a clear purpose statement followed by a well-organized parameter breakdown. Every sentence earns its place, and the information is front-loaded with no wasted words.
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 5-parameter tool with no annotations and no output schema, the description adequately covers parameters but lacks behavioral context (how scrolling works, what happens on completion, error handling). It's minimally viable but has clear gaps in operational transparency.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides clear semantics for all 5 parameters: 'element' (index or name), 'direction' (with enum values), 'distance' (pixels with default), 'duration' (milliseconds with default), and 'device_id' (optional targeting). This adds substantial value beyond the bare 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 clearly states the specific action ('scroll'), target ('UI element'), and scope ('in the given direction for a specified distance'). It distinguishes from sibling tools like 'swipe' (which moves across screen) and 'press' (which taps) by focusing on element-specific scrolling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for scrolling UI elements but doesn't explicitly state when to use this vs. alternatives like 'swipe' (which might scroll the entire screen) or provide exclusions. It mentions 'element' parameter options but lacks contextual guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the tool's behavior by specifying it lists 'all available' items and the returned attributes, but does not mention potential limitations (e.g., pagination, rate limits, or authentication needs). It adequately describes the core action but lacks deeper behavioral context.
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 purpose and details without waste. Every word contributes to understanding what the tool does and what information it returns, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (0 parameters, no annotations, no output schema), the description is complete enough for a list operation. It specifies the resource and returned attributes, though it could enhance completeness by mentioning the output format (e.g., list of objects) or any implicit constraints. Overall, it meets most needs for this low-complexity 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?
The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the absence of inputs. The description adds no parameter information, which is appropriate here. Baseline is 4 for zero parameters, as no compensation is needed.
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 verb 'List' and the resource 'Android emulators and devices', specifying the exact information returned (name, ID, status, dimensions). It distinguishes from siblings like 'get_device_dimensions' by indicating it lists multiple items with comprehensive details rather than retrieving dimensions for a single device.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when needing a list of emulators/devices with their attributes, but does not explicitly state when to use this tool versus alternatives like 'get_device_dimensions' (which might fetch dimensions for a specific device). No exclusions or prerequisites are mentioned, leaving usage context somewhat implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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-puppeteer-mcp MCP server](https://glama.ai/mcp/servers/pedro-rivas/android-puppeteer-mcp/badges/card.svg)](https://glama.ai/mcp/servers/pedro-rivas/android-puppeteer-mcp)

Score Badge

Copy to your README.md:

[![android-puppeteer-mcp MCP server](https://glama.ai/mcp/servers/pedro-rivas/android-puppeteer-mcp/badges/score.svg)](https://glama.ai/mcp/servers/pedro-rivas/android-puppeteer-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/pedro-rivas/android-puppeteer-mcp'

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