Kronvox MCP server — gives any MCP-capable agent (Claude, OpenClaw, Hermes) a smartphone.
Kronvox provides 9 well-named tools with consistent verb_noun patterns (list_devices, screenshot, tap, swipe, type, key, open_app, ui, screen_size). All tools have descriptions (avg ~80 chars, within baseline 34-392). Input schemas are present with type definitions for all parameters. However, descriptions are terse and lack actionable context for LLM selection. Parameter descriptions are minimal (e.g., 'X coordinate in pixels' for tap coordinates lacks range/constraint info). No output schemas documented. Error handling guidance absent. Missing tool annotations (readOnlyHint/destructiveHint). Composition is sound, each tool has one responsibility, and serial parameter enables multi-device chaining.
Press a hardware/navigation key: back, home, enter, tab, delete, search, menu, recent, space, power, volume_up, volume_down.
List the virtual phones (Android devices/emulators) currently attached.
Launch an app by its Android package name (e.g. com.android.chrome).
Get the phone screen size in pixels.
Take a screenshot of the phone's screen. Returns a PNG image of the current screen.
Swipe from one coordinate to another (for scrolling, dragging).
Tap a pixel coordinate on the phone screen.
No output schemas documented. LLMs cannot infer what fields to expect from tool responses (e.g., does list_devices return serial, model, status?). This forces agents to guess downstream field names and risks broken tool chains.
Parameter descriptions lack constraints and ranges. 'X coordinate in pixels' for tap does not specify valid range (0-width?), precision (int vs float), or what happens if out-of-bounds. LLMs cannot validate inputs without explicit constraints.
kronvox_key parameter 'key' accepts free-form strings ('back', 'home', 'enter', etc.) but is not declared as an enum. LLMs will hallucinate invalid key names. Should be: enum=['back', 'home', 'enter', 'tab', 'delete', 'search', 'menu', 'recent', 'space', 'power', 'volume_up', 'volume_down'].
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | 2026-07-28+ | v2 |
Type text into the currently focused input field.
Get a structured view of the current screen: a list of on-screen elements (text, ids, whether clickable) with their pixel coordinates. Prefer this over screenshots for deciding where to tap.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). LLMs cannot distinguish safe read-only tools (screenshot, ui, list_devices) from destructive ones (tap, swipe, type, key, open_app) without explicit hints. This risks unintended side effects.
Descriptions are terse and lack actionable context. 'Tap a pixel coordinate on the phone screen' does not explain when to use tap vs ui (which provides clickable elements). LLMs need guidance on tool selection: 'Use kronvox_ui first to find clickable elements, then tap their coordinates.'