The MobAI MCP Server enables AI assistants to automate and interact with Android/iOS devices, emulators, and simulators through a DSL-first interface. Key capabilities include:
Device Management: List connected devices, get details, start/stop automation bridges, and claim/release exclusive device leases.
Screenshots: Capture low-quality screenshots for AI analysis (with scale factor) and save full-quality PNGs to disk.
App Management: List, install, uninstall, and launch apps in debug mode with log capture.
Automation: Execute DSL scripts (execute_dsl) for complex interactions (tap, swipe, type, observe, assert, web automation, conditional branches, retry/failure strategies, screen recording).
Test Management: Get active test project, list all projects, and run .mob test cases on a device with optional parameter substitution.
iOS Debugging: Attach to apps (by bundle ID or PID), set breakpoints, evaluate Swift/ObjC expressions, step through code, and manage debug sessions.
Resource Access: Retrieve reference documentation for DSL, predicates, failure strategies, and testing workflows via MCP resources.
Provides tools for automating Android devices, emulators, and simulators, including actions like tap, type, swipe, screenshot, app management, and assertion-based automation.
Provides tools for automating iOS devices and simulators, including actions like tap, type, swipe, screenshot, app management, and assertion-based automation.
Click on "Install 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., "@MobAI MCP Server Open the Settings app on my Android device and navigate to Wi-Fi"
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.
MCP (Model Context Protocol) server for MobAI — AI-powered mobile device automation. Lets AI assistants (Claude Code, Cursor, Windsurf, Cline, and other MCP-compatible tools) control Android and iOS devices, emulators, and simulators via a single DSL-first interface.
All device interaction is batched through one primary tool: execute_dsl. Instead of exposing dozens of fine-grained tools (tap, swipe, type…), the server accepts a JSON script describing a sequence of actions with predicates, assertions, waits, and conditional branches. This keeps round-trips low and encodes retry/failure strategies server-side.
A small set of companion tools handles device discovery, screenshots, app management, and running .mob test files.
Related MCP server: Android-MCP
Node.js 18+
MobAI desktop app running locally (HTTP API on 127.0.0.1:8686)
A connected Android or iOS device, emulator, or simulator
claude mcp add mobai -- npx -y mobai-mcpAdd to .cursor/mcp.json:
{
"mcpServers": {
"mobai": {
"command": "npx",
"args": ["-y", "mobai-mcp"]
}
}
}Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS):
{
"mcpServers": {
"mobai": {
"command": "npx",
"args": ["-y", "mobai-mcp"]
}
}
}The server speaks stdio — use your client's generic MCP configuration:
{
"command": "npx",
"args": ["-y", "mobai-mcp"]
}Tool | Description |
| List all connected Android and iOS devices |
| Get details about a specific device |
| Start the automation bridge on a device (required before interaction) |
| Stop the automation bridge |
| Claim exclusive use of a device for this session (usually optional: acting on an unclaimed device auto-claims it) |
| Release one or all device leases held by this session |
Tool | Description |
| Fast, low-quality screenshot for LLM visual analysis (may be downscaled; response includes scale factor) |
| Full-quality PNG to disk for reporting, debugging, or sharing |
Tool | Description |
| List installed apps on the device |
| Install an |
| Uninstall an app by bundle ID / package name |
| Launch an app in debug mode and write stdout/stderr to a log file |
Tool | Description |
| Primary tool. Execute a batch of DSL steps: tap, type, swipe, observe, assertions, web automation, metrics, screen recording, and more. |
Tests are .mob files on disk inside project directories. You read, write, and edit them directly using your assistant's filesystem tools — MobAI watches for changes and updates the UI live. MCP is only needed to discover projects and run tests.
Tool | Description |
| Get the active test project directory and its |
| List all known test project directories with their |
| Run a |
Read these before attempting any device interaction — they describe the DSL schema, action set, predicates, failure strategies, and .mob syntax.
URI | Purpose |
| How to control devices — guide, all DSL actions, predicates, and failure strategies |
| Testing workflow, rules, error fixes, and |
Open the iOS Settings app, navigate to Wi-Fi, and verify the toggle exists:
{
"version": "0.2",
"steps": [
{"action": "open_app", "bundle_id": "com.apple.Preferences"},
{"action": "wait_for", "predicate": {"text": "Settings"}, "timeout_ms": 3000},
{"action": "tap", "predicate": {"text_contains": "Wi-Fi"}},
{"action": "wait_for", "predicate": {"type": "switch"}, "timeout_ms": 3000},
{"action": "assert_exists", "predicate": {"type": "switch"}},
{"action": "observe", "include": ["ui_tree"]}
]
}Pass this as the commands argument (a JSON string) to execute_dsl along with a device_id from list_devices.
"Connection refused" / "Could not reach the MobAI desktop app" — Make sure the MobAI desktop app is installed and running, and the API is reachable at http://127.0.0.1:8686. If you don't have it yet, download and install it from https://mobai.run/download.
"Bridge not running" — Call start_bridge first. The iOS bridge can take up to a minute to come up.
Screenshots not visible — get_screenshot saves to /tmp/mobai/screenshots/ by default and returns the file path. Use your assistant's file-reading capability to view them. DSL observe screenshots are extracted from the response and saved to the same directory.
git clone https://github.com/MobAI-App/mobai-mcp.git
cd mobai-mcp
npm install
npm run build
node dist/index.jsApache 2.0 — see LICENSE.
Launch an app in debug mode and write logs to a file. Returns the log file path — use Read/Grep to inspect logs. Use kill_app to stop.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| bundle_id | Yes | Bundle ID of the app to debug | |
| log_path | No | Directory for log file (supports ~/). Defaults to OS temp directory. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions launching, logging, and return path, but does not detail side effects (e.g., whether app runs until killed) or potential permissions needed.
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?
Two sentences, no fluff. Every sentence provides essential information efficiently.
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, description explains return value and follow-up actions. With sibling tools listed, behavior is sufficiently contextualized.
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 description adds little beyond schema. Mentions using Read/Grep ties to return value, but no new parameter-specific info.
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 'Launch an app in debug mode and write logs to a file', specifying the verb (Launch) and resource (app in debug mode). It distinguishes from siblings like debug_attach or kill_app.
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?
Provides guidance on next steps: use Read/Grep to inspect logs and kill_app to stop. Does not explicitly mention when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a debug session for an iOS app. Provide either bundle_id (launches and attaches) or pid (attaches to a running process). Optional breakpoints[] are armed before the target resumes. Read mobai://reference/debugging first.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| bundle_id | No | App bundle ID to launch and attach. Either this or pid is required. | |
| pid | No | Attach to an already-running PID. Either this or bundle_id is required. | |
| breakpoints | No | Initial breakpoint specs. "File.swift:42" (preferred), "Module.Type.method" (no parameter signature), "-[Class method:]", or runtime symbol. | |
| stop_on_entry | No | Simulator only — pause at first instruction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that breakpoints are armed before target resumes, and that stop_on_entry is simulator-only. However, lacks details on session lifecycle, cleanup, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, each with essential information. No redundancy, front-loaded with purpose and options.
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?
Covers key aspects of usage and breakpoints, but lacks description of return value or session handling. Moderate complexity with 5 parameters, no output schema, so more detail on what 'start a debug session' yields would be beneficial.
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 has 100% description coverage, but description adds value by explaining the mutual exclusivity of bundle_id/pid, the timing of breakpoint arming, and the simulator constraint for stop_on_entry. Enriches beyond schema.
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?
Clearly states it starts a debug session for iOS apps, distinguishes between launching with bundle_id vs attaching to pid, and mentions breakpoints. Differentiates from siblings like debug_breakpoint and debug_detach.
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?
Explicitly instructs to provide either bundle_id or pid, and to read reference first. Provides clear context on when to use each parameter, but does not explicitly state when not to use this tool in favor of siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add or remove a breakpoint in the active debug session. For action=add provide spec; for action=remove provide id.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| action | Yes | "add" or "remove" | |
| spec | No | Breakpoint spec for action=add. "File.swift:42", "Module.Type.method", "-[Class method:]", or runtime symbol. | |
| id | No | Breakpoint id for action=remove. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the need for an active debug session and the conditional parameters, but omits details like side effects, permissions, error behavior, or what happens to existing breakpoints.
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?
Two sentences with no wasted words. The purpose is front-loaded, and the conditional logic is explained efficiently.
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?
The description covers the essential conditional parameters for a 4-param tool, but lacks prerequisites (e.g., active session required), error conditions, and return value information, leaving gaps for an agent.
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 coverage is 100%, so baseline is 3. The description adds value by clarifying the conditional requirements for 'spec' and 'id' based on action, and provides examples for the spec format.
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 ('Add or remove') and the resource ('a breakpoint'), and distinguishes it from sibling tools by specifying 'in the active debug session' and the conditional action parameter.
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 explains when to use action=add vs remove based on parameter needs, but it does not mention when to use this tool versus alternatives like debug_state or debug_step, nor does it provide explicit exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End the debug session. Pass kill=true to terminate the debuggee; otherwise it keeps running.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| kill | No | Terminate debuggee on detach. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Describes the effect of the 'kill' flag on the debuggee; no annotations exist, so description carries full burden and does so adequately.
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?
Two concise sentences, front-loaded with the primary action, no unnecessary words.
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?
Sufficient for a simple command with no output schema; could note if any side effects, but overall complete enough.
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 coverage is 100%, so the description adds little beyond what the schema already provides. Baseline 3 is appropriate.
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?
States 'End the debug session' with a specific verb and resource, clearly distinguishing from sibling tools like debug_attach or debug_state.
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?
Provides guidance on the 'kill' parameter but does not explicitly contrast with alternatives, though the action (ending session) is distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Evaluate a Swift/ObjC expression at the current pause. Session must be paused. Examples: "p defaultPrivate", "po self.viewModel.user.email", "frame variable".
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| expression | Yes | Expression to evaluate | |
| frame_id | No | Optional frame id to evaluate in |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries the full burden. It mentions evaluation 'at the current pause' but does not disclose potential side effects of expressions (e.g., assignments) or error conditions like invalid syntax or un-paused session. Minimal but adequate for basic behavior.
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?
Three sentences, each purposeful: purpose, prerequisite, examples. Front-loaded and efficient with no wasted words.
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?
Covers purpose, prerequisite, and input style. Lacks description of output format (e.g., return value type) and error behavior. Given no output schema and moderate complexity, it is mostly complete but could be enhanced.
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 coverage is 100% with each parameter described, but the description adds value by giving example expressions and noting that frame_id is optional. The prerequisite of paused session provides context for device_id. Adds meaning beyond the schema.
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 tool evaluates Swift/ObjC expressions during a debug pause, with examples showing typical usage. It distinguishes from sibling tools like debug_step (stepping) and debug_state (viewing state).
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?
Explicitly states the prerequisite 'Session must be paused,' which is crucial for correct usage. Provides concrete examples of expressions, guiding the agent on what inputs are appropriate. No mention of alternatives, but the prerequisite is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Query the current debug session. Returns {state, breakpoints} by default. Set include_stack=true to also fetch the stack of the stopped thread; include_vars=true to also fetch frame[0] locals; include_threads=true to enumerate all threads.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| include_stack | No | Include stack of stopped thread. | |
| include_vars | No | Include frame[0] locals. | |
| include_threads | No | Include all threads. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Describes default and optional behavior but omits side effects, authentication, or confirmation that operation is non-destructive. Could explicitly state it does not modify state.
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?
Two sentences, front-loaded with primary purpose, no redundant words. Efficiently conveys default behavior and optional extensions.
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?
Covers default and optional outputs but does not detail the structure of 'state' or 'breakpoints' objects. Lacks mention of prerequisites (e.g., active debug session). For a read operation with no output schema, more detail on return types would improve 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 coverage is 100% but descriptions are brief. Tool description adds meaningful detail for each optional parameter (e.g., 'fetch the stack of the stopped thread', 'enumerate all threads'), providing context beyond the schema.
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?
Description clearly states verb 'Query', resource 'debug session', and default return values '{state, breakpoints}'. Distinguishes from sibling tools like debug_attach, debug_step, debug_eval.
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?
Explains when to use optional parameters (e.g., include_stack, include_vars) with concrete effects. Does not explicitly contrast with alternative tools or provide when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Advance the target. "in" — step into next call (blocks ~ms, returns {state, breakpoints, stack, frame0_locals}) "over" — step over next call (same shape) "out" — run until current frame returns (same shape) "continue" — resume until next breakpoint (fire-and-forget; returns just {state, breakpoints} — poll debug_state for next stop)
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| direction | Yes | "in" | "over" | "out" | "continue" | |
| include_stack | No | Include the new stack. Default true. Ignored for direction="continue". | |
| include_vars | No | Include the new frame[0] locals. Default true. Ignored for direction="continue". |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears full responsibility. It thoroughly discloses behavioral traits: blocking vs. fire-and-forget for each direction, approximate timing (~ms), and the exact return shapes. This is comprehensive and leaves no ambiguity.
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 well-structured with a clear header and bullet-like entries for each direction. It is concise but informative; every sentence adds value. Minor redundancy could be trimmed, but overall it is efficient.
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 (4 parameters, no output schema), the description covers the main behaviors and return formats. However, it does not clarify the exact impact of the optional boolean parameters when set to false (e.g., whether the stack field is omitted or just empty). This slight omission prevents a perfect score.
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 coverage is 100%, providing a baseline of 3. The description adds significant value by explaining how each direction affects return values and behavior, and that optional booleans are ignored for 'continue'. This goes beyond the schema's field descriptions.
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 tool's purpose ('Advance the target') and immediately enumerates the four possible directions with specific behavioral details. The inclusion of return shapes for each direction distinguishes it from sibling debug tools.
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 implicit context for when to use this tool (when stepping through code) and explicitly notes that 'continue' requires polling debug_state for the next stop. However, it does not directly compare to alternative tools like debug_state or debug_eval, nor does it state when NOT to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a batch of DSL commands on a device. This is the primary tool for all device interaction — tap, type, swipe, observe, launch apps, assertions, web automation, and more.
You MUST read the MCP resource mobai://reference/device-automation to learn how to control devices before using this tool.
Input: JSON string with "version": "0.2" and "steps" array. Example: {"version":"0.2","steps":[ {"action":"open_app","bundle_id":"com.apple.Preferences"}, {"action":"tap","predicate":{"text_contains":"Wi-Fi"}}, {"action":"wait_for","predicate":{"type":"switch"},"timeout_ms":3000} ]}
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| commands | Yes | DSL script as JSON string with version and steps |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility. It gives an example but fails to disclose behavioral traits such as destructiveness, error handling, rate limits, or side effects. The agent lacks crucial safety and failure information.
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 concise and well-structured: a clear purpose sentence, a necessary instruction to read a resource, and an illustrative example. Every sentence earns its place without redundancy.
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 complex tool with no output schema, the description adequately explains input format and points to a resource for complete usage. It could mention return behavior, but the reference compensates. The example helps ground the DSL syntax.
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 coverage is 100%, and the description adds value by explaining the 'commands' parameter as a DSL script with 'version' and 'steps' and providing a concrete example. This goes beyond the schema's brief descriptions, aiding understanding.
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 that the tool executes a batch of DSL commands for device interaction, listing specific actions like tap, type, swipe, etc. It distinguishes itself from siblings, which focus on debugging, installation, or queries, making the purpose unambiguous.
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?
It explicitly says it is the primary tool for device interaction and instructs to read a resource before using. However, it does not mention when not to use or provide alternatives, though no sibling tool serves the same purpose, so the guidance is strong for this context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details about a specific device
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. It implies a read-only operation but does not explicitly state safety, permissions, or error conditions. The basic intent is clear but depth is lacking.
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, concise sentence with no extraneous information. It is appropriately sized for the tool's simplicity and front-loads the core purpose.
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 tool with one parameter and no output schema, the description fails to detail what kind of details (e.g., OS version, model, status) are returned. This vagueness leaves the agent without necessary context for using the response 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?
Schema coverage is 100% with the single parameter 'device_id' described as 'Device ID'. The description adds no additional semantic meaning beyond 'get details', which is functionally equivalent to the schema. No value is added.
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 states 'Get details about a specific device', clearly indicating the action and resource. However, it does not differentiate from sibling tool 'list_devices' which lists all devices, nor specify what 'details' encompasses, leaving room for 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?
No guidance on when to use this tool vs alternatives like 'list_devices'. No preconditions or context for invocation are provided, leaving the agent to infer usage solely from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture a fast, low-quality screenshot for LLM visual analysis. Returns the file path to the saved image. The image may be downscaled by an integer factor so its long edge stays ≤ 2000px; when that happens the response includes a scale factor — multiply any coordinates you read off the image by that factor before using them in device actions (tap, swipe, drag, long-press, etc.). UI tree coordinates are already in device pixels, do not scale those. Use this for AI/LLM processing only — for full-quality screenshots use save_screenshot instead.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but description fully discloses downscaling behavior, scale factor, coordinate multiplication advice, and distinction from UI tree coordinates. This is rich behavioral context beyond what the schema provides.
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?
Description is fairly long but all sentences are informative. No wasted words, but could be slightly more concise. Still clear 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 low complexity (1 param, no output schema), description covers essential behavior, usage context, and coordinate scaling. It mentions response includes scale factor, but does not fully specify the response structure (e.g., JSON format). This minor gap prevents a 5.
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?
Only one parameter 'device_id' with schema description 'Device ID'. Description does not add further semantics (e.g., how to obtain ID). Schema coverage is 100%, so baseline 3 is appropriate.
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 (Capture), resource (screenshot), and distinguishes from the sibling tool 'save_screenshot' by specifying low-quality for LLM analysis versus full-quality.
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?
Explicitly says when to use (for AI/LLM processing) and when not to (use save_screenshot for full-quality), providing clear alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install an app on the device from a local file path (.apk for Android, .ipa for iOS)
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| path | Yes | Local file path to the app (.apk or .ipa) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It mentions the input file types but fails to disclose important behavioral traits such as whether installation overwrites existing apps, requires permissions, or triggers a device restart. This lack of detail hampers agent decision-making.
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 concise sentence that immediately conveys the core action and method. No unnecessary words; the structure is front-loaded and efficient.
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 tool with only two required parameters and no output schema, the description covers the essential purpose and input details. It specifies platforms (.apk/.ipa), which adds useful context. However, it lacks discussion of result behavior (success/failure) or duration, but for a simple installation action, this is adequate.
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 baseline is 3. The description redundantly notes file types already present in the schema and adds no new semantic information about the parameters.
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 ('install'), the resource ('app'), and the method ('from a local file path'), with specific file extensions for Android and iOS. It effectively distinguishes from sibling tools like 'uninstall_app'.
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 installing an app from a local path, but lacks explicit guidance on when to use this tool versus alternatives, prerequisites, or when not to use it. The context of siblings like 'debug_app' suggests different purposes, but no direct exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List installed apps on the device
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the action (list) and resource (installed apps), which is straightforward, but lacks details on output format or side effects. Adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that is front-loaded and contains no unnecessary words.
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 simple list tool with one required parameter and no output schema, the description is minimally adequate. It tells what the tool does but could benefit from mentioning what fields are returned or any limitations.
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 coverage is 100% (one parameter with clear description). The description adds no additional meaning beyond what the schema already provides, so baseline score of 3 applies.
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 'List installed apps on the device' uses a specific verb and resource, clearly distinguishing from sibling tools like install_app, uninstall_app, and debug_app.
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. The description only states what it does, not when to use it or when not to.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all connected Android and iOS devices
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It states the tool lists devices but does not clarify the meaning of 'connected' (e.g., via ADB), whether it is read-only, or the format of the returned data. For a simple listing tool, this is adequate but not comprehensive.
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, concise sentence that front-loads the key action and resource. Every word is meaningful, and there is no redundant or irrelevant 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 has no parameters, no output schema, and no annotations, the description provides the essential context of listing devices. However, it could be more complete by mentioning what the output contains (e.g., device identifiers) or any prerequisites. As is, it is slightly lacking but mostly sufficient.
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 tool has zero parameters and the schema coverage is 100% (empty), so no additional parameter information is needed from the description. The baseline for no parameters is 4, and the description does not add anything beyond what the schema already provides.
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 uses a specific verb 'List' and clearly identifies the resource as 'all connected Android and iOS devices'. This clearly differentiates the tool from siblings like 'get_device' (which targets a specific device) and 'install_app', making its purpose unambiguous.
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 the agent needs to obtain the list of currently connected devices, but it does not explicitly state when to use or not use this tool. No alternatives or exclusions are mentioned, leaving the agent to infer context from sibling tool names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Save a full-quality PNG screenshot to disk. Use this when you need a high-quality image for reporting, debugging, or sharing — not for LLM processing (use get_screenshot instead).
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| path | No | Directory to save screenshot to (supports ~/). Defaults to OS temp directory. | |
| name | No | Optional filename (without .png extension) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions saving to disk and the default directory, but does not disclose potential side effects (e.g., overwriting behavior), required permissions, or return value. This is adequate but not comprehensive.
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 consists of two concise sentences with no superfluous words. The primary action ('Save') is front-loaded, and the alternative guidance is efficiently integrated.
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?
The tool has 3 parameters, no output schema, and no annotations. The description does not mention the return value (e.g., file path or success status) or handle error cases. While adequate for a simple save operation, some contextual details are missing.
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 already documents all 3 parameters clearly. The description does not add any extra parameter-level details beyond what the schema provides, earning the baseline score of 3.
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 explicitly states 'Save a full-quality PNG screenshot to disk.' It identifies the verb (save), resource (screenshot), format (PNG), and quality (full-quality), clearly distinguishing it from the sibling tool get_screenshot.
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 explicitly states when to use this tool ('when you need a high-quality image for reporting, debugging, or sharing') and when not to use it ('not for LLM processing'), directly naming the alternative tool get_screenshot.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start the automation bridge on a device. Required before interacting with the device.
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions the start action and prerequisite, but does not disclose idempotency, side effects, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with the key information front-loaded. No extraneous content; every sentence adds value.
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 has one parameter and no output schema, the description covers the essential purpose and usage hint. Lacks some behavioral details but is adequate for its simplicity.
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 coverage for the single parameter 'device_id' is 100% with a basic description. The tool description adds no additional meaning beyond the schema, so baseline 3 is appropriate.
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 'Start' and the resource 'automation bridge on a device'. It also notes a prerequisite, distinguishing it from sibling 'stop_bridge'.
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 clear context: 'Required before interacting with the device.' This implies when to use, but does not explicitly exclude alternatives or provide when-not scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stop the automation bridge on a device
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description fails to disclose any behavioral traits such as destructiveness, side effects, or required permissions. Only states the action without context.
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?
Single sentence with no wasted words. Front-loaded with the action.
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?
Minimal description for a simple tool. Lacks context about bridge state, potential errors, or what happens after stopping. Incomplete given no annotations or output schema.
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 has 100% coverage with a single parameter ('device_id') described as 'Device ID'. Description does not add meaning beyond schema, but schema coverage is high so baseline is 3.
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?
Clearly states the action ('stop') and the resource ('automation bridge on a device'). Differentiates from sibling 'start_bridge' by name, but does not explicitly distinguish in description.
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. Does not mention prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the currently active test project directory and its .mob test cases. Use this to discover the project path and available tests. The agent can then read/write/create/delete .mob files directly in the returned directory.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool returns a directory path and that agents can interact with files there. It does not detail how 'active' is determined, but for a simple getter, this is adequate.
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?
Two sentences, front-loaded with purpose and clear guidance. Every sentence adds value without waste.
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 simplicity (no params, no output schema), the description is fairly complete. It explains the output and permissible actions. Could mention edge cases like no active project, but still adequate.
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?
There are zero parameters, and schema coverage is 100%. Per guidelines, baseline is 4. No additional parameter info is needed.
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', the resource 'active test project directory and .mob test cases', and the purpose 'discover the project path and available tests'. It distinguishes from siblings like test_list_projects and test_run.
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 context: 'Use this to discover the project path and available tests' and hints at subsequent actions. However, it lacks explicit guidance on when not to use this tool versus siblings like test_list_projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all known test project directories with their .mob test cases. Each project is a directory containing .mob script files.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description sufficiently discloses it is a read-only listing operation. It does not claim any destructive behavior or side effects, but could mention if the list is always up-to-date.
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?
Two concise sentences that front-load the action and resource with no extraneous information. Every sentence adds value.
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 simple, parameterless tool with no output schema, the description is sufficiently complete to explain what the tool does. Minor gap: doesn't indicate if the list is flat or includes paths, but not critical.
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?
Zero parameters, so schema coverage is 100% by default. The description adds value by specifying the content of the listing (directories with .mob files), fulfilling the need for parameter semantics.
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 the resource 'test project directories with their .mob test cases', making it unambiguous. It naturally distinguishes from siblings like test_run and test_get_active by focusing on listing directories.
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 siblings; however, the simplicity of the tool (0 parameters) reduces the need. Implied usage is for initial exploration of projects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a .mob test case on a device. The case_path is relative to the project directory. Pass params to supply values for ${name} substitution in the script.
| Name | Required | Description | Default |
|---|---|---|---|
| project_dir | Yes | Absolute path to the project directory | |
| case_path | Yes | Relative path to the .mob file within the project, e.g. auth/login.mob | |
| device_id | Yes | Device ID to run the test on | |
| params | No | Optional key-value parameters for ${name} substitution in the script |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as success/failure outputs, side effects, or return values. For an execution tool, 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. Information is front-loaded and easy to parse.
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 4 parameters, no output schema, and the nature of running tests, the description omits important details like return values, prerequisites, and execution 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 coverage is 100%, and the description adds context about case_path being relative and params for substitution, but largely repeats schema descriptions. Baseline of 3 is appropriate.
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 'Run a .mob test case on a device', using a specific verb and resource. It distinguishes from sibling tools like test_list_projects and debug commands.
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 when to use (to execute a test) but provides no explicit guidance on when not to use or comparisons with siblings.
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 device
| Name | Required | Description | Default |
|---|---|---|---|
| device_id | Yes | Device ID | |
| bundle_id | Yes | App bundle ID (iOS) or package name (Android) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description lacks critical behavioral details such as side effects (data removal), required permissions, or confirmation prompts. The tool is destructive but reveals nothing else.
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?
Very concise single sentence with no unnecessary words. However, it may be too terse and could benefit from additional context without sacrificing brevity.
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 simple two-parameter tool with no output schema, the description is adequate but lacks important context about destructive nature and prerequisites.
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 coverage is 100% with clear parameter descriptions, so the description adds no additional meaning. Baseline score is appropriate.
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 (uninstall) and the target (app from device), which is specific and distinguishes from siblings like install_app or list_apps.
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, prerequisites (e.g., app must be installed), or alternatives. However, the purpose is straightforward, making it minimally adequate.
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. Dates show when Glama detected each change.
v2.3.1debug_appdebug_attachdebug_breakpointdebug_detachdebug_evaldebug_statedebug_stepexecute_dslget_deviceget_screenshotinstall_applist_appslist_devicessave_screenshotstart_bridgestop_bridgetest_get_activetest_list_projectstest_rununinstall_appEach tool has a distinct purpose, with clear separation between debugging, device automation, screenshots, and test management. Only minor potential overlap between debug_app and debug_attach, but their descriptions clearly differentiate them.
Tools follow a consistent verb_noun pattern with snake_case, and use prefixes like debug_, test_ for grouping. Some variation exists (e.g., execute_dsl vs. start_bridge), but it is still predictable and readable.
20 tools is slightly above the typical range, but each tool serves a specific need in debugging, device automation, and testing. The count is justified by the breadth of functionality.
The tool set covers the full lifecycle for debugging (attach, breakpoints, step, eval, detach) and device automation (bridge management, DSL execution, screenshots, app management). Test management includes listing, running, and file-level operations. No obvious gaps.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Drive real Android & iOS devices and web browsers from natural language for mobile + web QA. 290+ tools across device control, app management, automation sessions, browser automation, and flow recording / replay. Bearer-auth — get a token at robotactions.com → Profile → API Tokens.
Melaya is a remote MCP server. It gives an assistant hands on your own Android phone and browser: it reads the screen through the accessibility tree, then taps, types and navigates inside the apps and sites you allow-list, with no per-app API. It also builds, schedules and runs agent pipelines across 6k+ connected tools. OAuth 2.1, nothing to install.
AI-powered browser automation — navigate, click, fill forms, and extract data from any website.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/MobAI-App/mobai-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
