Retrieve text file contents from Android devices for logs, configs, and more. Specify the remote path to read plain-text files, avoiding binary formats.
Szoveges fajl tartalmanak kiolvasasa az eszkozrol (log, config, stb.).
Csak sima szoveges fajlokhoz hasznald - binaris fajlhoz a 'pull_file'-t.
| Name | Required | Description | Default |
|---|---|---|---|
| serial | No | ||
| max_bytes | No | ||
| remote_path | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It does disclose a text-only scope and the binary-file alternative, which is useful. However, it does not explain the effect of max_bytes, encoding, truncation, or failure behavior for a read operation.
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?
Two short sentences, with the core purpose front-loaded and the binary-file exclusion immediately after. Every clause earns its place, and there is no filler.
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 output schema covers return format, so that is not a gap. The description gives the core selection and invocation guidance, but omits parameter-level behavior such as what max_bytes does and what happens with large files. This makes it adequate for the common text-file case 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 needed to compensate for parameter explanations. It only implies that remote_path is a text file path; serial and max_bytes are not explained at all, and the meaning of max_bytes default is left entirely to inference.
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 uses a specific verb ('read') and resource ('text file content from the device'), with concrete examples like logs and config files. It also explicitly distinguishes itself from pull_file for binary files, making sibling differentiation clear.
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 description states 'only use for plain text files' and explicitly directs binary files to pull_file. This is an explicit when-to-use/when-not-to-use rule with a named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.