Android Tester MCP

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 targeting specific resources like boxes, APKs, or UI actions, but 'ai_action' is broad and could overlap with more specific tools like 'open_app' or 'install_apk' if natural language instructions cover those tasks. The descriptions help clarify boundaries, but some ambiguity remains.
Naming Consistency4/5
Tools follow a consistent verb_noun pattern (e.g., 'create_android_box', 'get_screenshot', 'install_apk') with minor deviations like 'ai_action' (which uses a prefix instead) and 'list_boxes' (where 'boxes' is plural but aligns with the resource). Overall, the naming is readable and mostly predictable.
Tool Count5/5
With 9 tools, the count is well-scoped for managing Android boxes, covering creation, listing, interaction, and app management. Each tool earns its place by addressing a core aspect of the domain without being excessive or sparse.
Completeness4/5
The toolset provides good coverage for Android box management, including CRUD-like operations (create/list/get boxes) and app lifecycle (install/uninstall/open). Minor gaps exist, such as no tool for updating box configurations or handling system settings, but agents can work around these with the available tools.
Average 3.5/5 across 9 of 9 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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=false and openWorldHint=true, indicating it's a mutable, flexible operation. The description adds that it performs actions on the UI, which aligns with annotations but doesn't disclose additional behavioral traits like potential side effects, error handling, or performance implications beyond what annotations cover.
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 details, though it could be slightly more structured by explicitly mentioning key parameters or context.
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 complexity (6 parameters, mutable operation) and lack of output schema, the description is minimal. It covers the basic action but doesn't explain return values, error cases, or how it integrates with sibling tools, leaving gaps for an AI agent to infer 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?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description mentions 'natural language instruction' which hints at the 'instruction' parameter but doesn't add meaningful semantics beyond what the schema provides, such as examples of complex actions or parameter interactions.
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 ('perform an action') and resource ('UI of the android box'), specifying it's a natural language instruction. It distinguishes from siblings like get_screenshot (read-only) or install_apk (specific operation) by focusing on general UI interaction, though it doesn't explicitly contrast with open_app which is more specific.
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 explicit guidance on when to use this tool versus alternatives. It mentions 'natural language instruction' but doesn't specify scenarios where this is preferred over more specific tools like open_app or get_screenshot, nor does it mention prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and openWorldHint=true, suggesting a write operation with open-world semantics. The description adds value by specifying 'fresh' (implying new creation) and metadata return, but doesn't detail behavioral traits like permissions, side effects, or rate limits beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core action and outcome with zero wasted words, 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.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and moderate schema coverage, the description is minimal but adequate for a creation tool. It covers the basic purpose but lacks details on return values, error handling, or integration with siblings, leaving room for improvement in completeness.
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 50%, with parameters like 'config' and 'wait' documented in the schema. The description adds no parameter-specific details beyond the schema, but since coverage is moderate, it doesn't fully compensate for gaps, resulting in a baseline score.
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 ('Create') and resource ('Android box'), specifying it returns metadata. However, it doesn't differentiate from sibling tools like 'list_boxes' or 'get_box' beyond the creation aspect, missing explicit sibling distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/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 alternatives is provided. The description lacks context about prerequisites, use cases, or comparisons to siblings like 'list_boxes' or 'get_box', leaving usage unclear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe read operation with open-world semantics. The description adds no behavioral context beyond what annotations cover, such as rate limits, error handling, or what 'box information' entails. No contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste—'Get box information by ID.' It's front-loaded and appropriately sized for a simple tool, earning full marks for conciseness.
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 tool's low complexity (1 parameter, no output schema) and rich annotations (readOnlyHint, openWorldHint), the description is minimally adequate. However, it lacks details on return values or error cases, which could be helpful despite annotations covering safety.
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 the parameter 'boxId' fully documented in the schema. The description mentions 'by ID' but adds no extra meaning beyond the schema, such as ID format or examples. Baseline 3 is appropriate when schema does the heavy lifting.
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 'Get' and resource 'box information by ID', making the purpose specific and understandable. However, it doesn't differentiate from sibling tools like 'list_boxes' or explain what 'box information' includes, 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 no guidance on when to use this tool versus alternatives like 'list_boxes' or 'get_screenshot', nor does it mention prerequisites or context for usage. It's a bare statement with no usage instructions.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating a safe, non-destructive operation with potentially variable outcomes. The description adds context about capturing 'the current display,' implying real-time capture, but doesn't elaborate on behavioral aspects like latency, permissions needed, or what happens if the box is inactive. No contradiction with annotations exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action, making it easy to parse quickly.
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 tool's moderate complexity (capturing a screenshot with format options), annotations cover safety and variability, but the description lacks details on output (no schema provided), error conditions, or dependencies. It's minimally adequate but leaves gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with clear documentation for both parameters (boxId and outputFormat with enum values). The description mentions 'given box,' aligning with boxId, but adds no additional semantic context beyond what the schema provides, such as box state requirements or format implications.
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 the target resource ('current display for a given box'), making the purpose immediately understandable. However, it doesn't explicitly differentiate this tool from potential screenshot-related siblings (none exist in the provided list, but the description doesn't acknowledge this uniqueness).
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., needing an active box), exclusions, or relationships with sibling tools like 'open_live_view' (which might be a visual alternative) or 'get_box' (which provides box 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?
Annotations indicate this is a write operation (readOnlyHint: false) and open-world (openWorldHint: true), but the description adds useful context: it handles both local files and URLs, with specific behaviors for each (uploading or downloading). However, it lacks details on permissions, rate limits, or error handling, which are important 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 directly states the tool's purpose without unnecessary words. It's front-loaded and wastes no space, making it easy to parse quickly.
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 mutation tool with no output schema and rich annotations, the description is adequate but incomplete. It covers the basic action and parameter handling, but lacks details on return values, error cases, or integration with sibling tools, leaving gaps for an agent to infer behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents both parameters (boxId and apk). The description adds minimal value beyond this, as it repeats the apk handling details already in the schema. Baseline 3 is appropriate when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('Install') and resource ('APK file into the Gbox Android box'), making the purpose specific and understandable. However, it doesn't explicitly differentiate from sibling tools like 'uninstall_apk' beyond the obvious opposite action, 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 no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a box ID from 'list_boxes' or 'get_box'), compare with 'ai_action' for broader automation, or specify scenarios like installing versus opening apps with 'open_app'.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, indicating this is a safe read operation with potentially large result sets. The description adds minimal behavioral context beyond this, mentioning 'all current boxes' which aligns with openWorldHint. No contradictions with annotations exist, but the description doesn't add rich behavioral details like pagination behavior or rate 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 is a single, clear sentence that efficiently communicates the core purpose. It's appropriately sized and front-loaded with the essential information, with no wasted words or unnecessary elaboration.
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 tool's moderate complexity (6 optional parameters, no output schema), the description is adequate but minimal. With annotations covering safety and scope, and schema covering parameters, the description provides basic purpose but lacks guidance on usage versus siblings or details about return format. It's complete enough for a basic list operation but could be more helpful.
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 6 parameters well-documented in the schema. The description doesn't add any parameter-specific information beyond what's already in the schema, so it meets the baseline of 3. No parameter semantics are explained in the description itself.
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 ('List') and resource ('all current boxes belonging to this API Key'), making the purpose immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'get_box' (which likely retrieves a single box) or 'create_android_box' (which creates rather than lists).
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. The description doesn't mention sibling tools like 'get_box' for retrieving a single box or explain that this is for listing multiple boxes with optional filtering. Usage context is implied but not explicitly stated.
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?
Annotations indicate readOnlyHint=false (mutation) and openWorldHint=true (broad scope), and the description adds value by specifying that it's a destructive uninstall operation on an Android box, which goes beyond the annotations. However, it doesn't detail potential side effects (e.g., data loss, permissions needed) or response behavior, keeping it from a perfect score.
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 any fluff or redundancy. It's appropriately sized and front-loaded, making it easy to understand at a glance, which is ideal for conciseness.
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 tool's complexity (a destructive mutation with no output schema), the description is adequate but not fully complete. It covers the basic action and parameters, but lacks details on what happens after uninstallation (e.g., success/failure indicators) or error handling, which would be helpful for an agent to use it effectively.
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 input schema fully documents both parameters (boxId and packageName). The description adds minimal semantic context by mentioning 'by package name,' but doesn't provide additional meaning beyond what the schema already states. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('uninstall') and target resource ('an app from the Android box'), distinguishing it from sibling tools like 'install_apk' (opposite action) and 'create_android_box'/'list_boxes' (different resources). It precisely communicates what the tool does without being vague or tautological.
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 to remove an app from an Android box, but it doesn't explicitly state when to use this tool versus alternatives (e.g., 'install_apk' for adding apps) or provide context about prerequisites like having the box ID and package name ready. It offers basic context but lacks explicit guidance on exclusions or comparisons.
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?
Annotations indicate readOnlyHint=false (mutation) and openWorldHint=true (broad applicability), which the description aligns with by describing a launch action. It adds value by specifying the target ('Android box') and method ('by package name'), though it doesn't detail side effects like app state changes or permissions required.
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 core action ('Launch an installed application') and includes essential details ('by package name on the Android box') without any redundant or unnecessary 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?
Given the tool's moderate complexity (mutation with two parameters) and annotations covering safety (readOnlyHint=false) and scope (openWorldHint=true), the description is mostly complete. However, without an output schema, it doesn't explain return values or potential errors, leaving a minor gap.
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 parameters 'boxId' and 'packageName' fully documented in the schema. The description adds no additional meaning beyond implying these are required for the launch operation, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/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') and resource ('an installed application by package name on the Android box'), distinguishing it from siblings like 'install_apk' (installation) and 'uninstall_apk' (removal). It precisely defines the tool's function without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when launching an app on an Android box, but provides no explicit guidance on when to use this tool versus alternatives like 'open_live_view' or prerequisites (e.g., app must be installed). It lacks context on exclusions or comparisons with sibling tools.
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?
Annotations indicate readOnlyHint=false (implying a side effect) and openWorldHint=true (suggesting external interaction), which the description aligns with by specifying it opens a URL in the browser—a non-destructive but interactive action. The description adds valuable context beyond annotations: it reveals the tool launches an external application (the browser) and accesses a live stream, which isn't captured in the structured data.
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 front-loads the core action and resource without any fluff. Every word earns its place by specifying the tool's function, target, and outcome efficiently, making it easy for an agent to parse and understand quickly.
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 (interactive but non-destructive), the description covers the essential behavior—opening a live view in a browser. With annotations providing safety hints and no output schema, the description adequately explains what the tool does, though it could benefit from mentioning potential side effects like browser pop-ups or network requirements for completeness.
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, with 'boxId' clearly documented as the ID of the box. The description doesn't add any parameter-specific details beyond what the schema provides, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate as the description doesn't compensate but also doesn't detract.
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 ('Open'), the resource ('live-view URL of the Android box'), and the target ('in the default browser'), making the purpose immediately understandable. It distinguishes itself from siblings like 'get_screenshot' (which captures images) or 'open_app' (which launches apps on the device) by focusing on streaming live video access.
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 live monitoring of an Android box is needed, but it doesn't explicitly state when to use this tool versus alternatives like 'get_screenshot' for static images or prerequisites (e.g., the box must be online). No exclusions or clear alternatives are mentioned, leaving some ambiguity for the agent.
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-tester-mcp MCP server](https://glama.ai/mcp/servers/zhenweiwang1990/android-tester-mcp/badges/card.svg)](https://glama.ai/mcp/servers/zhenweiwang1990/android-tester-mcp)

Score Badge

Copy to your README.md:

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

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