Transfer a file from an Android phone to PC by reading and decoding it as base64, with MD5 verification. Use root access for restricted paths and bypass adb pull issues.
手机→PC 传文件：base64 读出解码（绕开 adb pull 的不可靠/权限问题），MD5 校验
| Name | Required | Description | Default |
|---|---|---|---|
| root | No | 源在 /data/data 等受限目录时 true（su 读） | |
| local | Yes | PC 侧目标路径 | |
| max_mb | No | 超过则拒绝（大文件请 shell.run 分卷） | |
| remote | Yes | 手机侧源文件绝对路径 |
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. It usefully discloses the base64 read/decode method and MD5 verification, plus that it bypasses adb pull's permission problems. It does not say whether root/su is required (that lives in the schema), what happens on checksum failure, or how errors surface.
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 single compact sentence: direction first, mechanism second, verification last. Every clause earns its place and nothing is padded.
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 output schema and no annotations, so the description should do more. It covers the transfer mechanism and integrity check adequately for a 4-param tool, but says nothing about the return value (e.g., whether the decoded file path or MD5 is reported) or failure behavior.
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 description coverage is 100%, so all four parameters (root, local, max_mb, remote) are already documented in the schema, including the root/su behavior and the shell.run fallback. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.
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 with direction ('手机→PC 传文件') and the mechanism (base64 读出解码 + MD5 校验), which implicitly separates it from the sibling file.push (PC→phone). It does not, however, explicitly name file.push as its counterpart, so sibling differentiation relies on the reader inferring direction.
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?
The parenthetical '绕开 adb pull 的不可靠/权限问题' implies the use case (when adb pull is unreliable or blocked), which is useful. But the description itself names no alternative tool, and the fallback for large files (shell.run 分卷) appears only in the schema, not the description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.