mobile-mcp-opengl
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ADB_PATH | No | Path to the adb executable, if it is not already on PATH. | |
| MOVE_STEP_MS | No | Pacing interval for MOVE events during drags, in milliseconds (default 20). | 20 |
| OPENAI_MODEL | No | Model identifier for the OpenAI provider (default 'openai:gpt@5.6-terra'). | openai:gpt@5.6-terra |
| OPENAI_API_KEY | No | API key for the OpenAI provider when using a non-Runware endpoint (e.g., OpenAI). | |
| OPENAI_BASE_URL | No | Base URL for the OpenAI provider. Defaults to Runware's /v1/chat/completions endpoint. Set to https://api.openai.com/v1 to use OpenAI directly. | |
| RUNWARE_API_KEY | No | Your Runware API key. Required for the default provider ('runware') and also used by the 'openai' provider when it points at Runware's endpoint. | |
| VISION_PROVIDER | No | Vision provider to use: 'runware', 'openai', 'openrouter', or 'openai-compatible'. Defaults to 'runware'. | runware |
| VISION_ALERT_USD | No | Per-call cost alert threshold in USD (default 0.0015). | 0.0015 |
| ADB_DEVICE_SERIAL | No | Serial of the adb device to target when more than one is connected. | |
| VISION_SESSION_CAP_USD | No | Daily cumulative vision spend cap in USD (default 2.00). | 2.00 |
| OPENAI_COMPATIBLE_MODEL | No | Model name for the OpenAI-compatible provider. | |
| OPENAI_COMPATIBLE_API_KEY | No | API key for the OpenAI-compatible provider. | |
| OPENAI_PRICE_PER_1M_INPUT | No | Cost per 1M input tokens for the OpenAI provider, used for spend tracking. | |
| OPENAI_COMPATIBLE_BASE_URL | No | Base URL for the OpenAI-compatible provider (e.g., a local Ollama server). | |
| OPENAI_PRICE_PER_1M_OUTPUT | No | Cost per 1M output tokens for the OpenAI provider. | |
| OPENAI_COMPATIBLE_PRICE_PER_1M_INPUT | No | Cost per 1M input tokens for the OpenAI-compatible provider, if you want spend tracking. | |
| OPENAI_COMPATIBLE_PRICE_PER_1M_OUTPUT | No | Cost per 1M output tokens for the OpenAI-compatible provider. |
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| screenshot_askA | Take a screenshot of the current screen and ask a short question about it (e.g. "Is there an error dialog visible?", "How many word icons are on screen?", "What color is the strength indicator?"). Use this when you need to check state WITHOUT performing an action first. Phrase the question so a short answer is possible (yes/no, a number, a short label) - see this server's README "Cost model". |
| tap_and_askA | Tap at device screen coordinates (x, y), wait briefly for the UI to react, take a screenshot, and ask a short question about the result - all in one call. Use this for any "tap here, then check what happened" step instead of calling separate tap/screenshot/ask tools. |
| swipe_and_askA | Swipe (or drag, for drag-and-drop UIs) from (x1, y1) to (x2, y2), wait briefly, take a screenshot, and ask a short question about the result - all in one call. |
| long_press_and_askA | Long-press at (x, y) for durationMs, wait briefly, take a screenshot, and ask a short question about the result. |
| record_and_askA | For checking an ANIMATION or any effect that plays out over time (e.g. "does the strength indicator pulse smoothly?", "does the XP label fly up and fade out?", "does the sprite return to its start position?"). Optionally performs one action first (tap or swipe, or neither), then takes Sequential single-frame calls were chosen over sending several frames in one request: Runware's imageCaption does accept an undocumented multi-image array, and it works fine for exactly 2 frames, but degrades noticeably at 3+ (truncated/malformed answers in testing) - sequential calls are both more reliable and, per-frame, no more expensive. Keep frameCount modest (3-6) - each frame is a full separate vision call and cost scales linearly with it. |
| type_textA | Type text into whatever field currently has focus. No screenshot/vision call - pair with screenshot_ask if you need to confirm the result. |
| press_keyA | Send an Android keyevent code (e.g. 4 = BACK, 66 = ENTER, 187 = APP_SWITCH). No vision call. |
| logcat_grepA | Read the last N logcat lines, optionally filtered by a regex (e.g. your app's tag, or "Exception|FATAL"). No vision call, no cost - prefer this over screenshot_ask whenever what you need is already in a log line (crashes, your own debug prints, network errors). |
| vision_spend_reportA | Report the cumulative vision-provider spend for today and the configured alert/cap thresholds, without making any device or vision call. |
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 9 tools
Each tool has a clearly distinct purpose: screenshot_ask is passive state-checking, while tap/swipe/long_press_and_ask each combine a specific gesture with screenshot-and-ask. record_and_ask targets animations, type_text and press_key are direct input without vision, logcat_grep handles logs, and vision_spend_report tracks cost. No two tools overlap in function.
All tool names follow a consistent snake_case pattern, with a clear <action>_and_ask convention for vision-verifying interactions and simple verb_noun for the rest. The naming logically separates gesture tools from non-vision tools, making the set easy to navigate.
Nine tools is well-scoped for a mobile automation/verification server. Each tool addresses a concrete need—actions, verification, logging, cost monitoring—and none feel redundant or purely decorative. The count fits the domain without bloat or sparsity.
The tool surface covers the full cycle of mobile UI interaction and verification: direct input (type_text, press_key), gestures (tap/swipe/long_press), visual state checking (screenshot_ask, record_and_ask), log inspection (logcat_grep), and cost governance (vision_spend_report). No obvious dead ends or missing operations for the stated purpose.