No user-submitted related servers found.
Scored across 78 tools
Most tools target a distinct device capability, and the descriptions work hard to separate near-neighbors (e.g. ACTION_GET_APP_INFO explicitly defers to ACTION_FOREGROUND_APP for a shell fallback). However there are several genuinely confusable pairs: ACTION_GLOBAL_KEY vs ACTION_GLOBAL_NAV both expose back/home/recents/notifications, ACTION_GET_TIME vs ACTION_PARSE_DATETIME both return date parts, and ACTION_TOAST vs ACTION_SEND_NOTIFICATION vs ACTION_DYNAMIC_ISLAND vs ACTION_MINI_SCREEN are four different ways to surface output to the user. With 78 tools an agent will often need to read descriptions closely before picking.
The bulk of the surface uses an ACTION_* SCREAMING_SNAKE prefix, which is a clear and readable convention. But it is mixed with lowercase control tools (agent_start, agent_stop, agent_status, screen, debug_screen, ping, mini_screen_status) and unprefixed uppercase condition nodes (CONDITION_SWITCH), so there are effectively three naming families with no rule an agent can predict.
78 tools is far past the point where an agent can hold the surface in mind; selection becomes a search problem rather than a choice. The domain (full Android device automation) is genuinely broad and most tools are non-redundant, so it is not gratuitous padding, but the set is still drastically over-scoped for a single MCP surface.
Coverage is unusually thorough: UI observation and interaction, system/device state reads, radios, media, notifications, variables, arrays, math, text, JSON/XML parsing, HTTP, loops, retry, try/catch, and both condition branch types. Gaps are minor — no file read/write node despite error hints referencing file_success, and no SMS/call-placing action to pair with the call-state waits.
