android-root-mcp

Overview Schema Source Related Servers Discussions Admin

batch_ui_actions

Execute 2–6 predictable Android UI steps in one call—launch, wait, tap, input, swipe, or key events—without pausing between actions. Stops on failure and returns the current UI tree for correction.

Instructions

【王牌去人机感工具】单次调用连续执行多步手机操作流水线！当能够预判接下来的 2~6 步操作时（例如：启动应用 -> 等待首页 -> 点击搜索框 -> 输入关键词 -> 按回车），必须使用本工具一次性下发，彻底告别『点一下停几秒等下一轮』的卡顿体验！若中途某一步失败，会自动中断并返回当前停留页面的 UI 树供纠错。

Input Schema

Name	Required	Description	Default
`steps`	Yes	要连续执行的动作数组。支持动作类型： 1. {'action': 'launch', 'package': 'com.xxx', 'activity': '可选'} 2. {'action': 'wait_for', 'text': '搜索', 'timeout': 5} 3. {'action': 'tap', 'text': '...', 'text_contains': '...', 'id': '...', 'index': 0, 'x': 100, 'y': 200} 4. {'action': 'input', 'text': '要输入的中文', 'hint': '搜索框提示词', 'clear': True, 'enter': True} 5. {'action': 'swipe', 'direction': 'up', 'scroll_to_text': '可选滚动查找文字'} 6. {'action': 'key', 'key': 'BACK'} 7. {'action': 'sleep', 'ms': 500} 8. {'action': 'root_cmd', 'cmd': '...'}
`return_ui_after`	No	批量执行完毕后是否附带最终 UI 树。默认 False——流水线跑完再由调用方决定是否观察；流水线中途失败仍会返回当时页面供纠错

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv2.0.0Nov 5, 2026

TDQS

A4.9/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description bears the full burden of behavioral transparency. It explicitly details a crucial operational behavior: upon failure mid-workflow, the tool automatically halts and returns the UI tree of the current state, enabling error correction. This is vital context for a batch process.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The structure is excellent, front-loading the core value proposition immediately. While the language is slightly marketing-oriented (e.g., '王牌去人机感工具'), the technical instructions are well-organized and highly focused.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of handling a nested array of diverse action types, the definition is exceptionally complete. It covers the 'what' (workflow execution), the 'when' (2-6 steps), and the 'if-then' (failure recovery mechanism), providing the agent with all necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

While the schema defines the structure, the description provides a functional specification for the complex 'steps' parameter. It lists 8 concrete action types (e.g., `launch`, `wait_for`, `root_cmd`) and provides examples of their required parameters, transforming the abstract schema into an executable blueprint.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly defines the purpose: executing sequential, multi-step mobile operations in a single function call (a workflow or pipeline). This sharply differentiates it from the many single-action sibling tools, such as `tap_element` or `input_text`.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides excellent usage guidelines by stating the specific condition under which the tool *must* be used: when the agent can predict 2 to 6 consecutive steps. This directs the agent away from calling multiple single-step tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server