Enables building, testing, debugging, and automating Android applications with tools for device management, UI interaction, crash analysis, app state inspection, and deep linking
Provides build automation for Android projects through Gradle build system integration
Enables building, testing, debugging, and automating iOS applications with tools for simulator management, UI interaction, crash symbolication, app state inspection, and deep linking
Provides build automation and tooling for iOS projects through Xcode command line tools and xcodebuild
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., "@Specter MCP build my Android app in debug mode and install it"
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.
Specter MCP enables AI agents (Claude, GPT, etc.) to build, test, debug, and interact with Android and iOS applications through the Model Context Protocol. Think of it as giving your AI assistant the ability to:
Build and deploy your mobile apps
Take screenshots and interact with UI elements
Run unit tests and E2E tests (Maestro)
Analyze crash logs and debug issues
Inspect app state (preferences, databases, logs)
Related MCP server: React Native Debug MCP
Requirement | Version | Verify Command |
Node.js | 20+ |
|
Android SDK | Any |
|
Xcode CLI (macOS) | Any |
|
Maestro (optional) | Any |
|
# Android SDK (if not installed via Android Studio)
export ANDROID_SDK_ROOT="$HOME/Library/Android/sdk"
export PATH="$PATH:$ANDROID_SDK_ROOT/platform-tools"
# iOS (macOS only)
xcode-select --install
sudo xcodebuild -license accept
# Maestro (optional, for E2E testing)
curl -Ls "https://get.maestro.mobile.dev" | bashnpm install -g specter-mcpgit clone https://github.com/abd3lraouf/specter-mcp.git
cd specter-mcp
npm install && npm run buildAdd to ~/Library/Application Support/Claude/claude_desktop_config.json:
{
"mcpServers": {
"specter-mcp": {
"command": "specter-mcp"
}
}
}Add to your project's .mcp.json:
{
"mcpServers": {
"specter-mcp": {
"command": "specter-mcp"
}
}
}{
"mcpServers": {
"specter-mcp": {
"command": "specter-mcp",
"env": {
"SPECTER_DEBUG": "true",
"ANDROID_SDK_ROOT": "/path/to/android/sdk"
}
}
}
}{
"mcpServers": {
"specter-mcp": {
"command": "node",
"args": ["/absolute/path/to/specter-mcp/dist/index.js"]
}
}
}Category | Tool | Description |
Build |
| Build Android/iOS app (debug/release) |
| Install APK or .app on device | |
| Launch installed app | |
UI |
| Screenshot + UI hierarchy |
| Tap, swipe, input text | |
Testing |
| Run unit tests |
| Run Maestro E2E flows | |
| Detekt, SwiftLint, ktlint | |
Environment |
| List emulators/simulators |
| Boot/shutdown devices | |
| Clean build caches | |
Debug |
| Parse crash logs, symbolicate |
| Filter device logs | |
| Read prefs, databases | |
Navigation |
| Open deep links |
You: Build my Android app in debug mode and install it
Claude: I'll build and deploy your app.
→ build_app(platform: "android", variant: "debug")
→ install_app(platform: "android", appPath: "...")
→ launch_app(platform: "android", appId: "com.example.app")You: My iOS app crashed, help me debug it
Claude: Let me analyze the crash.
→ analyze_crash(platform: "ios", appId: "com.example.app")
→ inspect_logs(platform: "ios", minLevel: "error")You: Take a screenshot and tap the login button
Claude: I'll capture the UI and interact with it.
→ get_ui_context(platform: "android")
→ interact_with_ui(platform: "android", action: "tap", element: "Login")You: Run my login flow test on both platforms
Claude: Running Maestro flows.
→ run_maestro_flow(platform: "android", flowPath: "./maestro/login.yaml")
→ run_maestro_flow(platform: "ios", flowPath: "./maestro/login.yaml")Variable | Default | Description |
|
| Enable debug logging |
|
| Log level (error/warn/info/debug) |
|
| Default timeout (ms) |
| auto | Android SDK path |
| - | Default Android device |
|
| Default iOS simulator |
export PATH="$PATH:$ANDROID_SDK_ROOT/platform-tools"# Android: Start emulator
emulator -avd Pixel_6_API_34
# iOS: Boot simulator
xcrun simctl boot "iPhone 15 Pro"xcode-select --install{
"env": {
"SPECTER_DEBUG": "true",
"SPECTER_LOG_LEVEL": "debug"
}
}src/
├── index.ts # MCP server entry
├── config.ts # Configuration
├── platforms/ # Android/iOS utilities
│ ├── android/ # ADB, Gradle, logcat
│ └── ios/ # simctl, xcodebuild, crash parsing
├── tools/ # MCP tool implementations
│ ├── build/ # build_app, install_app, launch_app
│ ├── ui/ # get_ui_context, interact_with_ui
│ ├── testing/ # run_unit_tests, run_maestro_flow, run_linter
│ ├── environment/ # list_devices, manage_env, clean_project
│ ├── crash/ # analyze_crash
│ ├── navigation/ # deep_link_navigate
│ └── observability/ # inspect_logs, inspect_app_state
└── utils/ # Shell, image processing, XML parsingnpm install # Install dependencies
npm run build # Build TypeScript
npm test # Run tests (695 tests)
npm run test:coverage # Coverage report
npm run lint # ESLint
npm run typecheck # Type checkAPI Reference — All 15 tools with parameters
Configuration Guide — Environment variables & setup
Getting Started — First steps
MIT © Specter MCP Contributors
Analyze crash logs and device logs to identify crash patterns and root causes. Supports both Android (logcat) and iOS (crash files + oslog). For live device analysis, checks device logs automatically. For iOS, can also analyze .ips/.crash files with symbolication.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform to analyze | |
| appId | No | App ID (Android package name or iOS bundle ID) for live device log analysis | |
| deviceId | No | Device ID for analysis (optional, uses first available device) | |
| crashLogPath | No | Path to iOS crash log file (.ips or .crash) - iOS only, optional for live analysis | |
| dsymPath | No | Path to dSYM file or directory - iOS only (optional, searches common locations) | |
| timeRangeSeconds | No | Time range in seconds to search device logs (default: 300 = 5 minutes) | |
| skipSymbolication | No | Skip symbolication for faster analysis - iOS only (default: false) | |
| includeRawLog | No | Include raw log data in output (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses key behavioral traits: live device log checking, support for .ips/.crash files, symbolication handling, and default time range. It does not mention if logs are modified or output specifics, but the core behaviors are transparent.
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 three concise sentences, each providing essential information: general purpose, platform support, and special iOS features. No redundancy or filler language.
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 8 parameters and no output schema, the description covers the key aspects: platforms, log sources, optional parameters, and specific behaviors like symbolication. It lacks details on the output format or what 'identify crash patterns' returns, but remains sufficiently complete for typical analysis tasks.
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 description adds value beyond the schema by clarifying platform-specific constraints (e.g., crashLogPath is iOS only, optional for live), default values (timeRangeSeconds default 300), and behavior (skipSymbolication default false).
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: analyze crash logs and device logs to identify crash patterns and root causes. It specifies support for both Android and iOS with relevant log sources, distinguishing it from siblings like inspect_logs.
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 on when to use this tool (crash analysis) and specifics about platforms, log file types, and live analysis. It implies use cases but lacks explicit exclusions or alternatives to siblings like inspect_logs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a KMM application for Android or iOS. Returns structured build result with error details on failure.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform to build for | |
| variant | No | Build variant (default: debug) | |
| clean | No | Clean before building (default: false) | |
| iosDestination | No | iOS simulator destination (e.g., "platform=iOS Simulator,name=iPhone 15 Pro") | |
| androidModule | No | Android module name (default: androidApp) | |
| iosScheme | No | iOS scheme name (default: iosApp) | |
| timeoutMs | No | Build timeout in milliseconds (default: 30 minutes) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions returning a structured build result with error details, but lacks disclosure of side effects (e.g., workspace modification, resource consumption) or specific behavioral traits beyond the return type.
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 with a single sentence and a clause, no filler. However, it could be slightly more structured or front-loaded with key information like the required parameter.
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?
With 7 parameters, no output schema, and no annotations, the description is minimal. It does not explain the build process, required dependencies, or what constitutes the 'structured build result'. Incomplete for the complexity of a build tool.
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 description adds no additional meaning beyond the existing parameter descriptions. Default values are already annotated in the schema. Score at baseline 3, as the description does not enhance understanding of parameter interactions or usage.
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 builds a KMM application for Android or iOS, specifying the verb and resource. It also mentions the return type (structured build result with error details), distinguishing it from sibling tools like clean_project or install_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, no prerequisites or exclusions provided. Sibling tools like clean_project or run_unit_tests exist but no differentiation is given, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clean project build caches, DerivedData, and other temporary files. Helps resolve build issues caused by stale caches.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | Yes | Path to the project root directory | |
| cleanGradle | No | Clean Gradle caches and run gradlew clean (default: true) | |
| cleanDerivedData | No | Clean Xcode DerivedData (default: true) | |
| cleanBuild | No | Clean build directories (default: true) | |
| cleanNodeModules | No | Clean node_modules directory (default: false) | |
| cleanPods | No | Clean CocoaPods Pods directory (default: false) | |
| module | No | Specific Gradle module to clean (e.g., :app) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the tool cleans temporary files to resolve build issues, but omits details like whether the cleanup is destructive, reversible, or requires permissions. The description lacks depth on what gets deleted and side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action and resources, the second explains the benefit. 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?
The description is adequate for a tool with complete schema documentation but lacks behavioral context (e.g., reversibility, impact on source files). Given no output schema or annotations, it could be more complete on safety and side effects.
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 input schema fully explains each parameter. The description adds no additional meaning beyond summarizing the tool's action; thus, it meets the baseline of 3 without exceeding.
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 cleans build caches, DerivedData, and temporary files. It specifies a specific verb ('clean') and resource ('project build caches'), and it distinguishes from sibling tools like build_app or run_linter by focusing on cleanup to resolve build issues.
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 'build issues caused by stale caches' occur, providing context for when to use. However, it does not explicitly state when not to use or suggest alternatives, leaving the agent to infer usage boundaries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Capture the current UI state including screenshot and interactive elements. Returns a compressed screenshot and a list of UI elements with their properties.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform | |
| deviceId | No | Device ID or name (optional, uses first running device if not specified) | |
| includeAllElements | No | Include all elements, not just interactive ones (default: false) | |
| maxDepth | No | Maximum depth to traverse in UI hierarchy (default: 20) | |
| screenshotQuality | No | Screenshot JPEG quality 1-100 (default: 50) | |
| skipScreenshot | No | Skip screenshot capture for faster response (default: false) | |
| elementTypes | No | Filter to specific element types |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behaviors beyond output. It only mentions returns, not side effects, auth needs, or rate limits. Minimal value added.
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 main purpose and output. No redundant 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?
Despite 7 parameters and no output schema, the description only gives a high-level output summary. It omits how parameters affect results (e.g., filtering, screenshot quality, depth).
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 explains parameters. The description adds no parameter-specific meaning beyond 'current UI state'.
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' and the resource 'current UI state', and specifies the output (compressed screenshot and UI elements list). This distinguishes it from sibling tools like 'inspect_app_state' or 'interact_with_ui'.
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 (e.g., 'inspect_app_state' for app-level state). No exclusions or when-not-to-use info.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect app preferences (SharedPreferences/UserDefaults) and SQLite databases. Can list all preferences, inspect specific databases, or run SQL queries.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | App package name (Android) or bundle ID (iOS) | |
| platform | Yes | Target platform | |
| deviceId | No | Device ID (optional, uses first available) | |
| includePreferences | No | Include preferences in inspection (default: true) | |
| includeDatabases | No | Include databases in inspection (default: true) | |
| preferencesFile | No | Specific preferences file to inspect | |
| databaseName | No | Specific database name to inspect or query | |
| sqlQuery | No | SQL query to execute (requires databaseName) | |
| maxRows | No | Maximum rows to return from query (default: 100) | |
| timeoutMs | No | Timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions inspection capabilities but does not disclose potential destructive actions (e.g., SQL writes), permission requirements, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the main purpose and capabilities. 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?
Given 10 parameters and no output schema, the description provides a high-level overview but lacks details on return format, error handling, or behavior for edge cases like missing databases.
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 detailed parameter descriptions. The tool description adds context about the overall scope but does not significantly enhance understanding 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 clearly states the tool's purpose: inspecting app preferences and SQLite databases, with specific actions like listing, inspecting, and querying. It differentiates from sibling tools like inspect_logs by focusing on internal app 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?
The description implies usage for debugging app state but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Inspect device logs (Android logcat or iOS unified logs). Can filter by app, log level, tags, patterns, and time range.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform | |
| appId | No | App package name (Android) or bundle ID (iOS) to filter logs | |
| deviceId | No | Device ID (optional, uses first available) | |
| minLevel | No | Minimum log level to include | |
| tags | No | Tags to include (Android logcat) | |
| excludeTags | No | Tags to exclude from results | |
| pattern | No | Search pattern (regex) to filter messages | |
| ignoreCase | No | Case insensitive pattern matching (default: true) | |
| subsystem | No | Subsystem filter (iOS only) | |
| category | No | Category filter (iOS only) | |
| maxEntries | No | Maximum log entries to return (default: 200) | |
| lastSeconds | No | Time range - logs from last N seconds (iOS, default: 300) | |
| clear | No | Clear log buffer before capture (Android only) | |
| includeCrashes | No | Include crash/fault logs (default: true) | |
| timeoutMs | No | Timeout in milliseconds (default: 30000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description carries full burden. It mentions filtering but does not disclose side effects (e.g., clearing log buffer via 'clear' parameter) or output characteristics.
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 is efficient and front-loads the main purpose. Could include more detail without becoming verbose.
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?
With 15 parameters and no output schema, the description is too brief. It omits critical context like that the tool returns log entries, that 'clear' mutates device state, and how platform affects available options.
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%, setting baseline at 3. Description adds little beyond what schema already provides; does not explain parameter nuances like tag vs excludeTag 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?
Description clearly states the tool inspects device logs and lists filtering capabilities, distinguishing it from sibling tools like analyze_crash or inspect_app_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?
Description implies usage for inspecting logs but does not explicitly state when to use this tool versus alternatives or provide any exclusions.
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 a device or simulator. For Android, installs an APK. For iOS, installs an .app bundle.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform | |
| appPath | Yes | Path to the app artifact (APK for Android, .app bundle for iOS) | |
| deviceId | No | Device ID or name (optional, uses first running device if not specified) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden for behavioral context. It only describes the basic action without disclosing potential side effects (e.g., overwriting existing installs), error handling, permissions required, or return behavior. This is insufficient for a safe agent invocation.
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 concise sentences, immediately stating the core action and platform distinction. No filler or redundant information. It is well front-loaded.
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 lack of an output schema and the complexity of installing apps across platforms, the description omits critical context: prerequisites (e.g., device availability, app readiness), behavior when deviceId is omitted, error scenarios, and expected outcome (e.g., success indication). It is not complete enough for reliable agent operation.
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 adds minimal extra value by restating the app artifact types (APK, .app bundle), which is already detailed in the schema's parameter descriptions. No new semantic insights are provided.
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 an app) and the target (device or simulator), with platform-specific details (APK for Android, .app bundle for iOS). It effectively distinguishes from sibling tools like 'launch_app' (launches after install) and 'build_app' (builds before install).
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 explicit guidance on when to use this tool versus alternatives, such as prerequisites (e.g., app must be built, device must be connected) or when not to use it. No mention of related tools like 'list_devices' to get device IDs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform UI interactions like tap, swipe, or text input. Can target elements by ID/text or by coordinates.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform | |
| action | Yes | Type of interaction to perform | |
| element | No | Element ID, resource ID, or text to interact with | |
| x | No | X coordinate for coordinate-based interaction | |
| y | No | Y coordinate for coordinate-based interaction | |
| text | No | Text to input (for input_text action) | |
| direction | No | Swipe direction (for swipe action) | |
| durationMs | No | Duration in milliseconds (for long_press and swipe, default: 300) | |
| deviceId | No | Device ID or name (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so description must carry full burden. It discloses interaction types and targeting methods but does not cover failure behavior, timeouts, permissions, or side effects like navigation.
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 cover purpose and targeting method. No redundant information, though could be slightly more 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 9 parameters and no output schema, description lacks details on return values or error conditions. However, basic purpose and parameter mapping are clear from schema due to 100% coverage.
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 description adds no new meaning beyond what schema already provides (e.g., 'by coordinates' is already in x/y 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?
Description clearly states the tool performs UI interactions (tap, swipe, text input) and targets elements by ID/text or coordinates. It distinguishes from siblings like get_ui_context and inspect_app_state, which are for reading state rather than action.
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?
Description implies usage for performing actions on UI but does not provide explicit when-to-use or when-not-to-use guidance, nor does it mention alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Launch an installed app on a device or simulator.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform | |
| appId | Yes | Package name (Android) or bundle ID (iOS) | |
| deviceId | No | Device ID or name (optional, uses first running device if not specified) | |
| clearData | No | Clear app data before launch (Android only, default: false) | |
| launchArguments | No | Arguments to pass to the app (iOS only) |
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 only states the basic action without disclosing potential side effects, failure modes (e.g., app not installed), or blocking behavior. The description is too thin 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 sentence with no wasted words. It is front-loaded and efficiently communicates the core function.
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 (5 params, 2 required) and no output schema, the description is mostly adequate but lacks important context such as prerequisites (app must be installed), error handling, and return behavior. It is minimally complete.
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?
All parameters have descriptions in the input schema (100% coverage). The description does not add any additional meaning or context beyond what the schema already provides, so baseline score 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 the verb 'launch' and the resource 'installed app' on a specific target ('device or simulator'). It distinguishes well from sibling tools like 'install_app' and 'build_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, nor any prerequisites (e.g., app must be installed) or when not to use it. The description implies usage but provides no explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available devices (emulators, simulators, physical devices). Returns device details including status and platform.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | No | Filter by platform (optional, lists all if not specified) | |
| status | No | Filter by device status | |
| includeAvds | No | Include list of available Android AVDs (default: false) | |
| includeUnavailable | No | Include unavailable iOS simulators (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like idempotency, auth requirements, or rate limits. It only states it returns device details, lacking any depth about side effects, permissions, or limitations.
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-load the purpose and immediately describe the output. No filler words or redundant 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?
The description is minimal for a tool with 4 optional parameters and no output schema. It does not clarify the full set of device details returned or how filtering interacts with the output, leaving some 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?
The input schema fully describes all parameters (100% coverage), so the baseline is 3. The description does not add any meaning beyond the schema; it merely implies the return includes status and platform, which is already evident from parameter names.
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 it lists available devices, specifies types (emulators, simulators, physical), and mentions the returned details (status, platform). This is a specific verb+resource combination that distinguishes it from sibling tools like install_app or launch_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 is provided on when to use this tool versus alternatives (e.g., when to filter by platform/status vs. other tools). The description simply states what it does without addressing exclusions or preferred contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage device environment: boot, shutdown, or restart emulators and simulators.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | Action to perform | |
| platform | Yes | Target platform | |
| deviceId | No | Device ID, name, or AVD name (optional, uses first available) | |
| waitForReady | No | Wait for device to be fully ready after boot (default: true) | |
| timeoutMs | No | Timeout in milliseconds (default: 120000) |
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 fails to mention that shutdown/restart are destructive operations, prerequisites (device must exist), or side effects like stopping running processes.
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 that is front-loaded and to the point. Slightly verbose with 'Manage device environment:' but still 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 5 parameters and no output schema, the description is too brief. It omits behavior details (e.g., waitForReady only relevant for boot/restart) and does not explain the optional deviceId default.
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 no extra meaning beyond the action types listed. The description does not elaborate on optional parameters like waitForReady or timeoutMs.
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 the tool manages device environment with specific actions (boot, shutdown, restart) and target devices (emulators/simulators), distinguishing it from sibling tools like launch_app or install_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 vs alternatives (e.g., launch_app for app launch, list_devices for listing). Implicit usage is clear but lacks exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run code linter (Detekt, Android Lint, SwiftLint, ktlint). Returns structured lint results with issue locations and suggestions.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform | |
| projectPath | Yes | Path to the project root directory | |
| linter | No | Linter to run (default: detekt for Android, swiftlint for iOS) | |
| module | No | Gradle module for Android linters (e.g., :app) | |
| configPath | No | Path to linter configuration file | |
| timeoutMs | No | Timeout in milliseconds (default: 300000) | |
| autoFix | No | Auto-fix issues if supported by the linter (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool returns structured results (implying read-like behavior) but does not disclose that autoFix can mutate files, required permissions, or timeout implications beyond the parameter description.
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, clear and front-loaded with the core purpose and output. No redundant 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 7 parameters, 2 required, and no output schema, the description mentions structured results but does not specify fields of the output, explain how configPath or timeoutMs affect behavior, or cover auto-fix side effects. Could provide more details on output format and tool 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 baseline 3 is appropriate. The description adds minimal value beyond schema, only hinting at default linters per platform. No additional semantic context for individual 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 tool runs code linters (Detekt, Android Lint, SwiftLint, ktlint) and returns structured results with issue locations and suggestions, distinguishing it from sibling tools like run_unit_tests or build_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 for linting code but provides no explicit guidance on when to use this tool versus when not to, or how it compares to other tools. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a Maestro E2E test flow. Returns structured results with step-by-step status. On failure, generates a failure bundle with screenshot and logs for debugging.
| Name | Required | Description | Default |
|---|---|---|---|
| flowPath | Yes | Path to the Maestro flow YAML file | |
| platform | Yes | Target platform | |
| deviceId | No | Device ID or name (optional, uses first available) | |
| appId | No | App package (Android) or bundle ID (iOS) | |
| timeoutMs | No | Timeout in milliseconds (default: 300000) | |
| generateFailureBundle | No | Generate failure bundle with screenshot and logs on failure (default: true) | |
| env | No | Environment variables for the flow |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that on failure it generates a failure bundle with screenshot and logs, and returns structured results. No annotations exist, so description carries full burden; it could mention blocking behavior or side effects but 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 concise sentences, front-loaded with main purpose and key behavioral traits, no superfluous 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?
Covers purpose, return value summary, and failure handling. No output schema, so description explains key outputs. Could be slightly more detailed on return structure, but sufficient for a complex tool.
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 descriptions for each parameter. The description adds context about the failure bundle linking to generateFailureBundle, adding value 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 runs a Maestro E2E test flow and returns structured results with step-by-step status, distinguishing it from sibling tools like launch_app or inspect_logs.
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?
Implies usage for E2E testing flows, but lacks explicit when-to-use or when-not-to-use guidance. No direct alternative is mentioned, but context makes it clear among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run unit tests for Android or iOS. Returns structured test results with pass/fail status and failure details.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes | Target platform | |
| projectPath | Yes | Path to the project root directory | |
| sourceSet | No | Source set to test (test, commonTest, androidTest, iosTest) | |
| testClass | No | Specific test class to run (optional) | |
| testMethod | No | Specific test method to run (requires testClass) | |
| module | No | Gradle module for KMM projects (e.g., :shared) | |
| timeoutMs | No | Timeout in milliseconds (default: 300000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the tool returns structured results but does not disclose whether it blocks, modifies the project, requires a prior build, or is safe to run. Behavioral traits like side effects or prerequisites are missing.
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 long with no waste. It front-loads the purpose and immediately states what it returns, making it 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?
With no output schema, the description appropriately mentions the return value (structured test results). However, it does not cover prerequisites (e.g., project must be built) or handle cases like missing test classes. It is adequate but not complete for the tool's complexity.
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?
Input schema has 100% description coverage, so the schema already documents all parameters. The description adds no additional meaning beyond the schema, meriting the 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 tool runs unit tests for Android or iOS and returns structured test results with pass/fail status and failure details. This specific verb+resource combination distinguishes it from sibling tools like run_linter and run_maestro_flow.
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 build_app or run_linter. No exclusions or context for selecting this tool over others are given.
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.0analyze_crashbuild_appclean_projectdeep_link_navigateget_ui_contextinspect_app_stateinspect_logsinstall_appinteract_with_uilaunch_applist_devicesmanage_envrun_linterrun_maestro_flowrun_unit_testsScored across 15 tools
Each tool targets a distinct function: crash analysis, building, cleaning, deep link navigation, UI capture, app state inspection, log inspection, installation, UI interaction, launch, device listing, environment management, linter, E2E tests, and unit tests. There is no ambiguity between tools.
Most tools follow a verb_noun pattern (e.g., analyze_crash, build_app). One exception is deep_link_navigate (noun_verb), and interact_with_ui uses a preposition, but overall the naming is mostly consistent.
15 tools is well-scoped for a mobile app development and testing server. Each tool earns its place, covering build, test, deploy, device management, and analysis without being overwhelming.
The tool set covers core workflows: building, testing (unit, lint, E2E), installing, launching, UI interaction, logging, crash analysis, and device management. Minor gaps like uninstall or app data reset are absent but not critical.
Control real Android and iOS devices with LLM agents — tap, swipe, type, automate flows.
Drive real devices from your AI Coding tool. Embed a client SDK (Unity, Godot, Flutter, iOS/macOS, Android, React Native, Web) in your app, then capture screenshots, traverse the UI tree, inject taps and key events, and run automated test tasks on the physical device over a secure relay.
Cloud iOS simulators and Android emulators your agent can create, drive, and throw away.
Agentic CI operations for build inspection, failure diagnosis, and runner troubleshooting.
