mobile-freecode
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 | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_devicesA | List all discovered and paired Android devices running the FreeCode Agent app. If no devices appear, the user needs to: (1) install the FreeCode Agent app on their Android phone from the Play Store or by installing the APK directly, (2) enable the accessibility service in the app, and (3) ensure the phone is on the same WiFi network as the computer. The app automatically discovers the desktop on the local network once installed. |
| get_deviceA | Get detailed information about a specific device, including capabilities, connection state, and current foreground app. |
| pairA | Initiate pairing with a discovered Android device. The device must have the FreeCode Agent app installed and running. If a pairing code was generated on the device, pass it via the "code" parameter. Otherwise a code is generated automatically — the user enters this code on their phone to confirm pairing. |
| unpairA | Remove pairing for a device. The device will need to be paired again before it can be controlled. |
| callB | Execute a tool on a paired Android device. See docs/MOBILE_MCP_TOOLS.md for the full tool reference. Available device tools: computer.tap, computer.double_tap, computer.long_press, computer.swipe, computer.drag_path, computer.multi_touch, computer.pinch, computer.type, computer.key, computer.scroll, screen.screenshot, screen.dump, screen.observe, device.info, device.brightness, device.volume, device.clipboard, app.current, app.list, app.launch. The device routes the call through its MobileGatewayService to the appropriate service. |
| batchA | Run an operation against multiple devices concurrently. Returns results for each device. |
| screenshotC | Capture a screenshot from a device. Uses MediaProjection when active, falls back to AccessibilityService. |
| screen_streamA | Start, poll, or stop a persistent screen stream from a device. Use action="start" to begin streaming, action="poll" to fetch the most recent frames (a sliding window of the last few, oldest→newest, so you see recent motion — call this repeatedly to keep watching a screen that changes on its own, e.g. a video or animation), action="stop" to end. |
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 8 tools
Each tool maps to a distinct lifecycle stage: discovery (list/get), pairing (pair/unpair), command execution (call), multi-device execution (batch), and screen capture (screenshot/screen_stream). Some overlap exists between 'screenshot' and 'screen_stream'—and 'call' can also trigger screen.screenshot—but the descriptions clarify single-frame versus streaming.
Names are readable and snake_case, but not one consistent pattern: list_devices/get_device use verb_noun, pair/unpair are simple verbs, call/batch are generic verbs, and screenshot/screen_stream are compound nouns. This is mixed but still understandable.
Eight tools is well-scoped for an Android device-control server. Each tool has a clear role, with no obvious filler, and the count sits comfortably in the typical 3-15 range.
The core lifecycle is covered: discovery, pairing, unpairing, device info, command execution, batch execution, and screen capture/streaming. One minor gap is that the 'call' tool defers to an external docs file and the server exposes no schema-listing for the device tools, which could create dead ends if those device tools change.