Provides runtime access to Android apps for AI agents, enabling inspection of business state, method calls, UI state, screenshots, and runtime modifications for debugging and verification.
Provides runtime access to iOS apps for AI agents, enabling inspection of business state, method calls, UI state, screenshots, and runtime modifications for debugging and verification.
A tool for Android and iOS developers that gives AI agents runtime access to understand, explore, debug, and verify apps.
Documentation: English · 简体中文 · Français · Русский · Español · العربية
Compared with Web development, inspecting a mobile app's internal data, business state, and execution is harder. “The data request succeeded—why didn't the list update?” Questions like this depend on actual data, state, and timing that static source analysis alone often cannot explain.
Mobile Easy Use gives AI agents runtime access through MCP, connecting source code with actual app behavior so development decisions can rely on runtime evidence.
Watch the iOS runtime investigation demo (58 seconds)
Agents can connect what users see with what happens inside the app to understand its behavior and investigate problems:
Runtime information | What it tells you |
Business objects and state | Current data, caches, configuration, and business state, including changes after an action |
Method calls | Which methods run, their arguments, return values, call stacks, and execution threads |
Execution time and memory changes | Method duration and process memory changes around calls |
Business logs | How far execution progresses and what clues point to a failure |
UI and control state | Control presence, visibility, position, and properties |
Window and element screenshots | Actual appearance and visual changes after an action |
App resources | Resource identifiers and contents associated with Android controls and configuration |
Operation results and failure context | Where an action fails and the state, logs, and images captured at that point |
Available information depends on the platform and app implementation.
Related MCP server: Autonomo MCP
These capabilities can also perform traditional UI automation. Mobile Easy Use goes further by letting agents observe and change what happens inside the app, not just operate and verify the UI.
Capability | Traditional UI automation (UI-focused) | Mobile Easy Use |
UI interactions: click, type, scroll, and more | ✓ | ✓ |
UI state: locate controls, read properties, and wait for state | ✓ | ✓ |
Capture screens and elements | ✓ | ✓ |
Observe business objects and state | — | ✓ |
Hook methods: collect call chains, arguments, results, and stacks | — | ✓ |
Measure execution time and process memory changes | — | ✓ |
Temporarily change runtime conditions: override method returns or fields | — | ✓ |
Invoke internal app methods | — | ✓ |
These capabilities bring runtime information into every stage of development:
Before coding: Inspect real state and call paths alongside source code to decide where and how to make a change.
During coding: Hook relevant logic and temporarily adjust runtime conditions to check assumptions and branch behavior.
After coding: Verify that business state and UI agree, and save common actions and probes as Presets.
For example, ask your agent:
Inspect this page controlled by a configuration flag: check its current
configuration and actual call path, then temporarily toggle the flag
and verify data and UI in both states. Restore it when finished.Prepare Node.js 20+.
Android requires ADB and an available device or emulator. iOS requires macOS, Xcode and its command-line tools; physical devices also require iproxy and development signing for the XCTest Runner used for input actions.
Run from the target app project root:
npx skills add agent-easy-use/mobile-easy-use --skill '*'This selects all Skills in the repository. Follow the prompts to choose your agent and installation scope. See the Skills CLI documentation for the command and options.
Install Skills and MCP separately: Skills include Observable, Integrate, Probe, Presets, and their supporting script generation and execution workflows. MCP provides tools to connect to the app and execute operations.
In the target app project, ask the agent to use the platform's Integrate Skill:
Use to-android-integrate to integrate Mobile Easy Use into this app's debug variant.Use to-ios-integrate to integrate Mobile Easy Use into this app's internal debug configuration.Integrate acquires and verifies Release artifacts, updates the project configuration, and returns an exact compatible MCP launch command. Android integrates an AAR that starts the Runtime automatically. iOS embeds the bridge and Runtime, which MCP loads when connecting. Scope integration to internal debug builds, then build and install the app on the target device.
Complete integration workflows: Android Integrate Skill · iOS Integrate Skill.
Add mobile-easy-use to your agent's MCP configuration. Use the compatible MCP version returned by the Integrate Skill in the previous step. The version 0.1.0 below is only an example; replace it with the version in the MCP launch command returned by the Skill:
{
"mcpServers": {
"mobile-easy-use": {
"command": "npx",
"args": ["-y", "@agent-easy-use/mobile-easy-use@0.1.0"]
}
}
}npx fetches and starts the selected version without a separate global install. Use your client's configuration mechanism to set the working directory to the target app project root so MCP can resolve project Presets. The agent and MCP need shared local filesystem access to read SDK declarations and probe files.
Reload the MCP configuration and check that tools such as get_sdk_declarations and connect are visible to the agent. New connections check compatibility between the app Runtime Release and MCP version and suggest an adjustment if they do not match.
After integration, build the app debug version containing the Mobile Easy Use Runtime and install it on the target device or simulator before using Probe. Connect the device, identify the target app, and describe your question:
Use to-android-probe to investigate list refresh in com.example.app on the device.
Open the list page and refresh it. Check whether the request callback runs,
the data state updates, and the list displays the new content.Use to-ios-probe to investigate why tapping sign-in in com.example.app
does not open the home screen. Explain using relevant method calls,
business state, and UI evidence.Probe uses source code and existing Presets to generate the investigation, connect to the app through MCP, execute actions, and collect relevant evidence. It answers the original question without requiring you to write probe scripts, distinguishing observed facts, source-based explanations, and unverified behavior.
These four capabilities cover coding, integration, everyday exploration, and reuse, with separate Android and iOS implementations.
Capability | When to use it | Android / iOS Skill |
Observable | Optional coding guidance with minimal intrusion: reuse or selectively add logs, UI identifiers, and runtime entry points so the app works better with Mobile Easy Use | |
Integrate | Set up or maintain debug integration, acquire Runtime artifacts, configure the project, and select a compatible MCP version; also prepare or repair iOS Runner signing | |
Probe | Start a runtime investigation in natural language, including probe generation, execution, and evidence analysis | |
Presets | Turn common navigation, business actions, and state queries into reusable capabilities with type declarations, bundled for future probes |
Probe composes the platform's to-*-script and to-*-run Skills for generation and execution. For everyday use, start with Probe and describe your question.
Observable is not a prerequisite for using Mobile Easy Use. It prioritizes existing logs, UI identifiers, and runtime entry points, making only small, local additions when the current development task calls for them. These changes preserve business behavior while making control lookup, call observation, and state verification easier.
Invoke Observable as needed. If you want it applied during everyday coding, you can add the following rules to the target project's AGENTS.md or agent coding rules after installing the Skills. Keep only your platform's line if appropriate:
When writing or modifying Android App code, apply the android-observable-code skill.
When writing or modifying iOS App code, apply the ios-observable-code skill.Use to-android-presets to create reusable capabilities for opening a list page,
refreshing its content, and reading its data state.The target project's .meu/config.json sets the base directory through presets.directory, defaulting to .meu/presets, with separate android/ and ios/ subdirectories. The Skill generates probe.js, probe.d.ts, and an export entry, then builds presets.dist.js. MCP loads the platform bundle when connecting.
Disconnect and reconnect after updates to load the new bundle. With a device available, the Skill executes the capabilities for verification. Without one, it can generate and build them but explicitly reports runtime behavior as unverified. See the Presets Skills above for directory and build details.
Mobile Easy Use draws inspiration from quickjs-android, xLua, and Frida: embedding a scripting runtime in a host application, bridging scripts with native objects, and accessing app capabilities across runtime boundaries.
Frida is the implementation foundation and an actual dependency. The app-side Runtime is based on Frida Gadget. MCP uses frida to establish runtime connections and Java / Objective-C bridges to access platform objects. Mobile Easy Use builds on these capabilities with a mobile development SDK, MCP tools, evidence collection, and Skill workflows.
Developer question → AI agent + Skills → MCP → Frida Runtime in the app
↕
Methods / Objects / State / Logs / UISee package.json for package dependency versions. App-side binary versions and notices are documented in the Android third-party notices and iOS third-party notices. The compatibility catalog maintains Runtime Release / MCP compatibility.
npm install
npm test
npm pack --dry-runnpm package: @agent-easy-use/mobile-easy-use.
Tried your first probe? Share what you investigated and where you got stuck. If Mobile Easy Use is useful for your work, star the repository to bookmark it.
On the connection instance identified by deviceId and appId, load or reuse a probe ES Module, call one export, and return its result or error with action-scoped evidence.
| Name | Required | Description | Default |
|---|---|---|---|
| args | No | Positional arguments passed to the exported function. | |
| appId | Yes | Android package name or iOS bundle identifier. | |
| deviceId | Yes | Canonical ADB serial, CoreDevice identifier, or simulator UDID. | |
| filePath | Yes | Absolute path to a UTF-8 standard ES Module file readable by the MCP server. | |
| functionName | Yes | Name of the function exported by the ES Module. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| result | No | |
| evidence | Yes | Evidence JSON files, ordered by the first record for each action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool loads or reuses a module, invokes a single export, and returns either a result or an error with action-scoped evidence. However, it does not mention potential side effects of executing code, permissions required, or failure conditions beyond returning an error.
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 filler, front-loads the main action, and packs the key semantics—connection scope, module loading, single export call, and result/error return—into a compact definition.
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 core action and return behavior, and an output schema is presenthips. However, for a tool that executes exported functions, it lacks important context like safety warnings, side-effect expectations, or prerequisites for the probe module, and it does not guide selection among siblings.
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 schema documents all five parameters. The description adds the notion of loading/reusing a probe ES Module and calling one export, which clarifies filePath and functionName, but it does not provide substantial additional meaning beyond the parameter 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 uses specific verbs ('load or reuse', 'call', 'return') and identifies the target resource: a probe ES Module on a connection instance identified by deviceId and appId. It clearly conveys what the tool does, though it does not explicitly contrast itself with sibling tools like eval_script.
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 the action but gives no guidance on when this tool should be preferred over alternatives such as eval_script, connect, or disconnect. There are no use-case conditions, prerequisites, or exclusions, leaving the agent to infer selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create or reuse the connection identified by deviceId and appId, initialize its Android or iOS SDK runtime, and report runtime and Release compatibility. Surface compatibilityWarning and a non-null compatibility.upgradeRecommendation to the user as non-blocking advisories.
| Name | Required | Description | Default |
|---|---|---|---|
| ip | Yes | Prepared Host endpoint IPv4 address; to-run uses 127.0.0.1 for USB devices and simulators. | |
| port | Yes | Prepared Host endpoint port after ADB forwarding, iproxy, or direct simulator resolution. | |
| appId | Yes | Android package name or iOS bundle identifier. | |
| deviceId | Yes | Canonical ADB serial, CoreDevice identifier, or simulator UDID. | |
| platform | Yes | SDK platform to load into the target process. | |
| runtimePort | Yes | Device-side MobileEasyUse runtime listen port. |
| Name | Required | Description |
|---|---|---|
| ip | Yes | |
| port | Yes | |
| state | Yes | |
| target | Yes | |
| runtime | Yes | Runtime identity reported by the SDK loaded in the target App. |
| connected | Yes | |
| fridaTarget | Yes | |
| compatibility | Yes | Compatibility between the App Release and this MCP version, or null when the online catalog could not be checked. |
| compatibilityWarning | No | Non-blocking notice that compatibility could not be checked; surface it to the user. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It reveals that the operation may create or reuse a connection, initializes an Android or iOS SDK runtime, and reports runtime and Release compatibility. It also explicitly frames compatibilityWarning and upgradeRecommendation as non-blocking advisories. It does not describe what happens if a connection already exists for the same deviceId/appId, but it is substantially more transparent than a minimal 'Connects to a device'.
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 tight sentences that front-load the core create-or-reuse behavior and then add the compatibility-reporting detail. Every clause earns its place, and there is no filler or tautology.
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 schema documents all required parameters, an output schema exists to cover return fields, and the description supplies the lifecycle and compatibility context an agent needs. For a connection-establishment tool with this complexity, nothing essential is missing for correct invocation.
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 6 parameters are fully described in the schema, so the baseline is 3. The description adds some contextual meaning by identifying deviceId and appId as the connection identity and platform as the runtime selector, but it does not meaningfully elaborate on ip, port, or runtimePort 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 names a specific action ('Create or reuse the connection identified by deviceId and appId'), a concrete resource (the connection and SDK runtime), and the platform scope (Android/iOS). It clearly reads as the setup counterpart to disconnect and is unlikely to be confused with call_function, eval_script, or get_sdk_declarations.
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 that this tool establishes or reuses a connection and initializes a runtime, which suggests it should be used before call_function or eval_script and paired with disconnect. However, it never explicitly states when to use it versus alternatives or mentions exclusions, so the usage guidance is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect the MobileEasyUse instance identified by deviceId and appId, destroy its runtime, and clear its modules.
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | Android package name or iOS bundle identifier. | |
| deviceId | Yes | Canonical ADB serial, CoreDevice identifier, or simulator UDID. |
| Name | Required | Description |
|---|---|---|
| state | Yes | |
| connected | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explicitly discloses destructive behavior by stating it will destroy the runtime and clear modules, which is critical for an agent to know before calling. It does not cover side effects like irreversibility or permission requirements, but the core destructive action is clearly stated.
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 sentence that fronts the action (disconnect) and then packs in the two key behavioral details (destroy runtime, clear modules). No filler or redundancy; every word earns its place.
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 two-parameter tool with an output schema, the description covers the essential behavior and resource identification. It lacks fallback or precondition guidance (e.g., calling on a non-existent instance), but given the tool's simplicity and the availability of structured schema, the description is largely sufficient. The absence of annotations means a bit more could be said about error handling, but the core is covered.
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?
Both parameters have complete schema descriptions (deviceId and appId with format details), so schema coverage is 100%. The description refers to them but adds no extra meaning beyond what the schema already provides. Per the rubric, 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 states a specific verb (disconnect) and a precise resource (MobileEasyUse instance) and names the effects (destroy runtime, clear modules). This goes beyond a vague 'disconnect' and clearly distinguishes it from siblings like connect and call_function.
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 usage context is implied: you disconnect an instance you previously connected. However, there is no explicit statement of when to use this tool over alternatives, no mention of prerequisites (e.g., must be connected first), and no exclusions. The sibling connect is an obvious counterpart but is not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
On the connection instance identified by deviceId and appId, evaluate one inline async IIFE and return its result or error with action-scoped evidence. The source must have the form (async () => { ... })().
| Name | Required | Description | Default |
|---|---|---|---|
| appId | Yes | Android package name or iOS bundle identifier. | |
| source | Yes | Complete async IIFE source, for example `(async () => { return runtimeStatus(); })()`. | |
| deviceId | Yes | Canonical ADB serial, CoreDevice identifier, or simulator UDID. |
| Name | Required | Description |
|---|---|---|
| error | No | |
| result | No | |
| evidence | Yes | Evidence JSON files, ordered by the first record for each action. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool returns a result or error with action-scoped evidence, but it does not warn that evaluating arbitrary code can have side effects on the device, nor does it state any prerequisites like needing an active connection or running app.
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 filler. The primary behavior is front-loaded, and the critical source-format constraint is stated immediately after, making the description 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?
The description covers the core invocation details and the output schema exists, but it omits important selection context: when to use this tool instead of call_function, whether a prior connect is required, and potential side effects of executing arbitrary code. This leaves an agent with meaningful gaps for correct tool selection.
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 semantic value beyond the schema: it frames deviceId and appId as connection identifiers and repeats the source form that the schema already documents with an example.
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 a specific action: evaluating one inline async IIFE on a connection identified by deviceId and appId, and returning its result or error. The constraint on source form further differentiates it from siblings like call_function, which presumably call named functions.
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 phrase 'On the connection instance' implies that a connection must exist and that the device/app must be identified, but it does not explicitly say when to prefer eval_script over call_function or when not to use it. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Locate local SDK, platform bridge, and Frida Gum declaration files for to-script. Requires a shared filesystem, not a device connection.
| Name | Required | Description | Default |
|---|---|---|---|
| platform | Yes |
| Name | Required | Description |
|---|---|---|
| files | Yes | |
| platform | Yes | |
| sdkVersion | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint=true and openWorldHint=false already supplied, the bar is lowered, and the description adds genuine context beyond them: the operation is filesystem-local rather than device-mediated, and it requires a shared filesystem precondition. It does not describe failure behavior when files are absent, but for a read-only locator with an output schema this is acceptable. No contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences of minimal, information-dense text with no fluff or restating of the schema. The core purpose leads, and the environmental prerequisite is delivered in the second sentence. Every clause earns its place.
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 one-parameter tool that ships both annotations and an output schema, the description supplies the essentials: what is being located, for what purpose (to-script), and the environment constraint. It does not mention what happens when declarations are not found or how results are expressed, but the output schema presumably carries the return shape, so the remaining gap is small.
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 0%, so the description must compensate, but it only hints at the platform's role via the noun phrase 'platform bridge'. It never explicitly says the platform enum (android/ios) selects which platform's SDK and declaration files to locate. The enum values are fairly self-evident and the parameter is single and required, so the deficit is minor, giving partial compensation rather than none.
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 a specific verb and resource: 'Locate local SDK, platform bridge, and Frida Gum declaration files for to-script.' It clearly differentiates from the siblings (connect, call_function, disconnect, eval_script), which act over a device connection or execute scripts, while this tool only locates declaration files locally. The intended output artifact is concrete and the scope is 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 sentence 'Requires a shared filesystem, not a device connection' gives an explicit applicability condition and an exclusion: use this when the declarations live on a shared filesystem, do not use it as part of a device-connection flow, which implicitly steers the agent away from the connect/disconnect siblings. It does not name an alternative tool explicitly or state a 'when not to use' beyond the connection caveat, so it stops just short of full guidance.
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.
v0.1.2call_functionconnectdisconnecteval_scriptget_sdk_declarationsScored across 5 tools
Each tool has a distinct purpose: connect establishes a session, disconnect tears it down, call_function invokes a module export, eval_script runs an inline script, and get_sdk_declarations retrieves local files without needing a connection. The only potential overlap is between call_function and eval_script, but their descriptions clearly separate module-call versus raw-script evaluation.
All tool names use lowercase snake_case with a verb-first pattern: connect, disconnect, call_function, eval_script, get_sdk_declarations. The style is uniform and predictable, making the set easy to scan and remember.
With 5 tools, the server is well-scoped. It covers the core lifecycle (connect, disconnect), two execution modes (call_function, eval_script), and a supporting utility (get_sdk_declarations). This is a lean set that does not feel bloated or sparse for its domain.
The tool surface covers the essential workflow: establish a connection, execute code (via module call or inline script), and clean up. The auxiliary tool for SDK declarations supports the scripting workflow. There are no obvious missing operations that would cause agent failures, such as a way to list connections or inspect runtime state—though that is not critical given the straightforward lifecycle.
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.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Live App Store & Google Play data for AI agents: app discovery, ASO keywords, reviews.
