mobile-easy-use
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_sdk_declarationsA | Locate local SDK, platform bridge, and Frida Gum declaration files for to-script. Requires a shared filesystem, not a device connection. |
| connectA | 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. |
| disconnectA | Disconnect the MobileEasyUse instance identified by deviceId and appId, destroy its runtime, and clear its modules. |
| call_functionB | 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. |
| eval_scriptA | 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 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.