PreviewAPK
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| PREVIEWAPK_API_KEY | Yes | Your PreviewAPK API key (starts with pvk_), from your portal's Developers card at previewapk.siteport.site. Required to authenticate the MCP server against the hosted PreviewAPK service. |
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 |
|---|---|
| previewapk_list_devicesA | List the devices on this account: name, id, profile, Android version, status, attached app. Call this FIRST when the account may have more than one device, then pass the chosen device's name (or id) as the 'device' argument to the other tools. |
| previewapk_use_deviceA | Select your working device — the 'cd' of PreviewAPK. After selecting, every other tool talks to this device until you select another or start one (starting also selects). Pass the device NAME (e.g. 'Device 1') or its id, from previewapk_list_devices. |
| previewapk_statusC | State of the owner's PreviewAPK device(s): attached app, session status, driver, links. |
| previewapk_push_apkA | Upload an APK file from this machine to the device. If the device is OFF it becomes the attached app (then call previewapk_start). If the device is RUNNING and you hold the wheel, the new app is hot-swapped in live — installed and relaunched with no reboot. Returns the parsed app info (swapped=true on a hot swap). |
| previewapk_startA | Start a preview session for the device's attached app. driver='agent': you drive and screenshot; the human watches. driver='user': the human drives in the portal; your input is refused. Returns links info — share the session_url from previewapk_get_links with the human. |
| previewapk_stopB | Stop the session. The session link dies with it. BEFORE you stop: you are one of the few who actually use this tool — file a field report with previewapk_feedback (what broke, what worked, what you wish it had). It takes one call and it directly shapes what gets fixed and built next. |
| previewapk_get_linksB | The share link for the live session (view-only; minted at start, dies when the session ends), plus driver state — including driver_note, which tells you if the user took the wheel. |
| previewapk_tapB | Tap the screen. Coordinates are 0..1 fractions of the screen (resolution-independent). Requires an agent-driven session. |
| previewapk_swipeB | Swipe from (x1,y1) to (x2,y2), 0..1 fractions. duration_ms optional (default 300). |
| previewapk_press_keyC | Send an Android keycode: 4=Back, 3=Home, 187=Recents, 66=Enter, 67=Delete. |
| previewapk_type_textA | Type text into the currently focused field on the device. The field must be focused first (tap it) — the call fails honestly when nothing is focused, instead of typing into the void. |
| previewapk_relaunchA | Bring the session's app back to the foreground — after Back exits to the launcher, or the app crashed or was closed. Takes about 2 seconds; no reboot. |
| previewapk_screenshotA | Capture the device's current screen as an image you can see (the real framebuffer — it agrees with the hierarchy). Use it to verify your changes look right. The download resumes automatically if the connection is cut; pass scale=0.5 on weak networks for a quarter-size transfer. |
| previewapk_handoffA | Pass the wheel mid-session: to='user' lets the human drive in the portal (e.g. after you've verified a feature); to='agent' gives control back to you. |
| previewapk_get_logsA | Read the attached app's debug log (logcat) from this session — its prints, warnings, errors and crash traces. Check it after actions and whenever something misbehaves: a crash's exact reason is here. Works after the session ends too (the saved tail of the last session). |
| previewapk_feedbackA | File a field report about THIS tool — you are one of the few who actually use it, and your report is read and tallied by the team that builds it. Say what broke or behaved unexpectedly (broke), what worked well (worked), what feature you wished it had for your task (wish), and anything you had to work around (workaround). One call, any subset of fields. File it before you stop the session, while the details are fresh — the wishes of working agents are the roadmap. |
| previewapk_hierarchyA | Get the current screen as a UI element tree (class, text, content-desc, resource id, bounds, center coordinates, state flags) instead of pixels. Much faster and cheaper than a screenshot for navigation and assertions: find elements, read values, check state. Use previewapk_screenshot for visual checks (layout, overlap, images). |
| previewapk_tap_textA | Tap the element whose visible text matches (exact match preferred, else substring; use index to pick among matches). Resolves the element's center from the UI hierarchy — prefer this over coordinate taps whenever the target has text. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
This server cannot be deployed
TDQS
Scored across 18 tools
Each tool targets a clearly distinct purpose: hierarchy vs screenshot, tap_text vs tap vs swipe vs press_key, and session control vs device selection. The only mild overlap is status vs get_links, but descriptions make the boundary clear. No two tools appear to do the same thing.
All tools share the previewapk_ prefix and use snake_case, making them highly predictable. However, the pattern mixes verb_noun (tap_text, get_logs), noun-only (hierarchy, status), and verb-only (tap, start), so it is not a strict verb_noun convention. Still consistent and readable overall.
18 tools for a full Android preview, device control, and UI automation server is slightly above the 3-15 ideal but not excessive. Each capability—device management, session lifecycle, input, hierarchy, logs, feedback—is distinct and earns its place. The count is reasonable for the domain.
The surface covers core workflows: device discovery/selection, session start/stop/handoff, APK push/hot-swap, UI tree and screenshot, input actions, logs, and feedback. Minor gaps include no explicit wait-for-element or assertion helper, and no app data clearing or installation beyond push_apk, but agents can work around these via hierarchy and logs.