Run shell commands or multi-line scripts on an Android device via adb, with optional root access. Use it to execute scripts without quote or pipe escaping issues.
执行 shell（root=true 走 su，设备需已 root）；风险命令需 allow_risk。script=多行脚本模式：base64 推到手机 /data/local/tmp 执行（规避嵌套引号/管道符转义地狱），与 cmd 二选一
| Name | Required | Description | Default |
|---|---|---|---|
| cmd | No | ||
| root | No | ||
| script | No | 多行 shell 脚本（推荐：可含管道/引号） | |
| allow_risk | No |
Changes observed during successful MCP inspections.
v0.5.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses real behavior beyond the schema: root mode routes through su and presupposes a rooted device, risky commands are gated behind allow_risk, and script mode base64-pushes to /data/local/tmp to dodge quote/pipe escaping. It does not explain what allow_risk actually bypasses or how errors/output are surfaced, leaving a gap for a tool with arbitrary-command execution power.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A compact, front-loaded passage: the core action leads, with mode and precondition details packed into parentheticals. Dense but every clause carries information, so it earns its length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema, so the description is the sole carrier of behavioral context. It covers preconditions and mode mechanics well but says nothing about return values, exit status, or failure handling, which matters for an arbitrary shell-execution tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 25% (only script is documented in-schema), so the description must compensate and largely does: it explains root's su semantics, allow_risk's risk gating, and script's multiline/base64 mechanism. cmd is only referenced obliquely via '二选一', so one of four parameters stays thin, but the compensation is substantial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource (执行 shell) and immediately qualifies it with the two operational modes (root via su, script mode). Clear and specific. There is no sibling shell tool in the list, so sibling differentiation is largely unnecessary here; the description does its job without it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives conditional guidance that is really parameter-level: root=true requires an already-rooted device, risky commands require allow_risk, and script/cmd are mutually exclusive (二选一). It never states tool-level when-to-use versus alternatives, but no sibling tool competes with it, so the omission is minor.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.