pull_file

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

With no annotations, the description carries the behavioral disclosure burden. It adds a useful safety detail: adb pull receives arguments directly (not as a shell string) so there is no shell-injection surface, and only the local target folder's existence is checked. However, it does not mention overwrite behavior, error handling, or required permissions.

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?

Three concise sentences, each serving a distinct purpose: core action, use-case scenario, and safety note. The key action is front-loaded and there is no redundant wording.

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?

The tool is simple and has an output schema, but lacks annotations. The description adequately covers purpose and a key safety aspect, yet leaves gaps around serial semantics and error conditions. It is sufficient for basic use but not fully complete.

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 0%, so the description must compensate. It implicitly clarifies remote_path as the device path and local_path as the computer path, and references the local folder existence check. It does not explain the optional serial parameter, which is relevant when multiple devices are connected.

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?

The description states a specific verb and resource: downloading a file from the device to the computer via adb pull. It gives concrete examples (photos, WhatsApp media, logs) and distinguishes itself from push_file by directionality.

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?

Provides a clear context for when to use the tool, such as retrieving files from a device with a broken screen that was previously authorized. It does not explicitly name alternatives or exclusions, but the use case is concrete enough for an agent to infer applicability.

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