Skip to main content
Glama
smk-h

embedded-mcp-toolkit

by smk-h

serial_download

Download binary files from a device over a serial session using ZMODEM. Runs sz on the device, handles the transfer handshake, and saves the file locally.

Instructions

Download a binary file from the device over ZMODEM via an existing serial session. The device must have lrzsz installed (sz command). IMPORTANT: this tool triggers the device-side sz by itself (via send_cmd); do NOT manually run sz (or serial_exec/write sz) on the session beforehand — a pre-started sz enters its own sending state that breaks the tool's ZMODEM handshake. Just call this tool and pass send_cmd when a directory change is needed (e.g. "cd /home && sz {remote}"). remote_path resolves on the device relative to the shell's current working directory — prefer an absolute path, or combine send_cmd with a cd to pin the directory. If the remote file does not exist or is unreadable, sz errors out and the transfer fails (a partial local file, if any, is removed on failure). Blocks until transfer completes, fails, or times out; progress is logged to stderr. Two timeouts: idle_timeout aborts on stalled transfer (real failure); timeout caps total duration and reports a suggested value if still progressing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
timeoutNoOverall timeout in seconds as a safety cap against indefinite hangs (default: 300). If reached while the transfer is still progressing (no idle), reports the timeout as too small with a suggested value instead of silently truncating.
send_cmdNoDevice send command template (default: 'sz {remote}'). {remote} is replaced by remote_path. The tool runs this command itself on the device — do NOT start sz manually beforehand. Use it for directory changes, e.g. "cd /home && sz {remote}"
local_pathYesLocal destination file path
session_idYesThe session ID returned by serial_open
remote_pathYesRemote source file path on the device. Resolved relative to the shell's current working directory — prefer an absolute path, or pin the directory via send_cmd (e.g. "cd /home && sz {remote}"). The file must exist and be readable; otherwise sz errors out and the transfer fails.
idle_timeoutNoIdle timeout in seconds: if no data flows for this long, the transfer is treated as a real failure (link/device stalled) and aborted. Independent of file size (default: 15, min: 3).
Behavior5/5

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

Thoroughly discloses internal behavior: triggers device-side sz itself, uses ZMODEM handshake, blocks until completion/failure/timeout, logs to stderr, handles partial file removal on error, resolves remote_path relative to cwd, and explains the two distinct timeouts. No annotations exist, so this description fully carries the transparency burden.

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

Conciseness5/5

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

The description is well-structured with a clear main purpose, an IMPORTANT warning, and logically ordered details. Each sentence contributes essential information given the complexity of ZMODEM transfers, avoiding superfluous text.

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?

Covers prerequisites, usage, error handling, timeouts, and failure modes comprehensively. Even without an output schema, it explains what happens during and after the operation (e.g., removal of partial files, blocking behavior). Complete for a tool with this complexity.

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

Parameters4/5

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

The input schema already provides detailed descriptions for all parameters (100% coverage), but the description adds holistic context about how parameters interact (e.g., send_cmd for directory changes, timeouts interplay). This adds value beyond the schema, though the schema alone is quite informative.

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 states the action (download a binary file) and the specific method (over ZMODEM via an existing serial session), distinguishing it from sibling tools like serial_upload or ssh_sftp_download.

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

Usage Guidelines4/5

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

Provides explicit usage constraints (e.g., do NOT manually run sz, use send_cmd for directory changes) and clarifies prerequisites (existing serial session, lrzsz installed). Does not explicitly compare with alternative download methods (e.g., ssh_sftp_download), but the context makes the intended use clear.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smk-h/embedded-mcp-toolkit'

If you have feedback or need assistance with the MCP directory API, please join our Discord server