Allows for automating and testing Android devices through the Gbox SDK, providing capabilities to spin up virtual or physical environments, manage applications, capture screenshots, and perform AI-powered UI actions via natural language instructions.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Android Tester MCP Install the app and use AI to click the 'Sign Up' button."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) plugin for automating Android devices using the Gbox SDK. This plugin provides tools for creating Android boxes, taking screenshots, performing AI-powered UI actions, and managing applications.
Create Android Boxes: Spin up virtual or physical Android devices
Screenshot Capture: Take screenshots of the current display
AI-Powered Actions: Perform UI actions using natural language instructions
App Management: Install, uninstall, and launch Android applications
Box Management: List and get information about your Android boxes
Related MCP server: ADB MCP Server
Install Dependencies
npm installSet Environment Variables
Create a .env file in the project root:
GBOX_API_KEY=your_gbox_api_key_hereBuild the Project
npm run buildThis is an MCP server that provides tools for Android automation. Once running, you can use the following tools:
{
"mcpServers": {
"gbox-android": {
"command": "node",
"args": ["/YOU_PATH_TO_THIS_REPO/android-tester-mcp/dist/index.js"],
"env": {
"GBOX_API_KEY": "YOUR API KEY"
}
}
}
}
create_android_box: Create a new Android box with specified configuration
list_boxes: List all current boxes belonging to your API key
get_box: Get detailed information about a specific box
get_screenshot: Take a screenshot of the Android device
ai_action: Perform UI actions using natural language (e.g., "click the login button")
install_apk: Install an APK file from local path or URL
uninstall_apk: Uninstall an app by package name
open_app: Launch an installed application
Node.js and npm
Valid Gbox API key
TypeScript (for development)
Test the apk of this project like a user, just create an android environment on gbox, and install it and test it by instructing the MCP tool ai_action. Keep developing and testing until all requirements are met.
Perform an action on the UI of the android box (natural language instruction).
| Name | Required | Description | Default |
|---|---|---|---|
| boxId | Yes | ID of the box | |
| instruction | Yes | Direct instruction of the UI action to perform, e.g. 'click the login button' | |
| background | No | Contextual background for the action, to help the AI understand previous steps | |
| includeScreenshot | No | Whether to include screenshots in the action response (default false) | |
| outputFormat | No | Output format for screenshot URIs (default 'base64') | |
| screenshotDelay | No | Delay after performing the action before the final screenshot, e.g. '500ms' |
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.
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.
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.
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.
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.
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.
Create a fresh Android box and return its metadata.
| Name | Required | Description | Default |
|---|---|---|---|
| config | No | ||
| wait | No | Wait for the box operation to be completed, default is true |
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.
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.
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.
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.
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.
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.
Get box information by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| boxId | Yes | ID of the box |
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.
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.
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.
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.
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.
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.
Take a screenshot of the current display for a given box.
| Name | Required | Description | Default |
|---|---|---|---|
| boxId | Yes | ID of the box | |
| outputFormat | No | The output format for the screenshot. | base64 |
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.
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.
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.
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.
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.
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.
Install an APK file into the Gbox Android box.
| Name | Required | Description | Default |
|---|---|---|---|
| boxId | Yes | ID of the box | |
| apk | No | Local file path or HTTP(S) URL of the APK to install, for example: '/Users/jack/abc.apk', if local file provided, Gbox SDK will upload it to the box and install it. if apk is a url, Gbox SDK will download it to the box and install it(please make sure the url is public internet accessible). |
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.
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.
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.
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.
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.
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.
List all current boxes belonging to this API Key.
| Name | Required | Description | Default |
|---|---|---|---|
| deviceType | No | Filter boxes by their device type (virtual, physical) | |
| labels | No | Filter boxes by their labels. Labels are key-value pairs that help identify and categorize boxes. | |
| page | No | Page number | |
| pageSize | No | Page size | |
| status | No | Filter boxes by their current status (pending, running, stopped, error, terminated, all). | |
| type | No | Filter boxes by their type (linux, android, all). Must be an array of types. |
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.
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.
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.
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.
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.
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.
Launch an installed application by package name on the Android box.
| Name | Required | Description | Default |
|---|---|---|---|
| boxId | Yes | ID of the box | |
| packageName | Yes | Android package name to open |
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.
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.
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.
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.
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.
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.
Open the live-view URL of the Android box in the default browser.
| Name | Required | Description | Default |
|---|---|---|---|
| boxId | Yes | ID of the box |
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.
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.
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.
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.
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.
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.
Uninstall an app from the Android box by package name.
| Name | Required | Description | Default |
|---|---|---|---|
| boxId | Yes | ID of the box | |
| packageName | Yes | Android package name to uninstall |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0ai_actioncreate_android_boxget_boxget_screenshotinstall_apklist_boxesopen_appopen_live_viewuninstall_apkScored across 9 tools
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.
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.
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.
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.
MCP server for Appcircle mobile CI/CD platform.
Mozark's MCP server for AI-powered app testing: device access, test automation, and QA insights.
MCP server for building and testing AI agents with multi-model experimentation and insights.
MCP server for Grok Imagine AI video generation
