Skip to main content
Glama
smk-h

embedded-mcp-toolkit

by smk-h

serial_upload

Upload a binary file to a device over serial using ZMODEM, running the receive command automatically. Set idle and total timeouts to handle stalled transfers and avoid hangs.

Instructions

Upload a binary file to the device over ZMODEM via an existing serial session. The device must have lrzsz installed (rz command). IMPORTANT: this tool triggers the device-side rz by itself (via recv_cmd); do NOT manually run rz (or serial_exec/write rz) on the session beforehand — a pre-started rz enters its own waiting state that breaks the tool's ZMODEM handshake. Just call this tool and pass recv_cmd when a working directory change is needed (e.g. "cd /home && rz"). 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.
recv_cmdNoDevice receive command (default: 'rz'). The tool runs this command itself on the device after disabling flow control — do NOT start rz manually beforehand. Use it for directory changes or options, e.g. "cd /home && rz -e" to receive into /home, or 'rz -e' to escape control chars
local_pathYesLocal source file path
session_idYesThe session ID returned by serial_open
remote_nameNoRemote file name (default: basename of local_path). The device rz will name the file accordingly.
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?

There are no annotations, so the description carries the full behavioral burden. It discloses that the tool triggers the device-side rz itself, blocks until completion/failure/timeout, logs progress to stderr, and explains the distinct semantics of idle_timeout versus timeout, including the suggested-value behavior on huge transfers.

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 front-loaded with purpose, immediately follows with the critical handshake warning, and then covers usage and timeout behavior. Every sentence contributes important operational context with no redundant filler.

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?

Given no annotations, no output schema, and six parameters, this is an unusually complete description. It covers prerequisites, failure modes, handshake risks, usage guidance, blocking behavior, stderr logging, and timeout semantics, leaving very little for the agent to infer or discover by mistake.

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

Parameters3/5

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

Schema coverage is 100% and every parameter already has a rich description, so the baseline is satisfied. The main description reinforces recvcmd and the timeouts and adds the working-directory-change example, but it does not meaningfully extend understanding of local_path, remote_name, or session_id beyond what the schema already states.

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 opens with a specific action and resource: 'Upload a binary file to the device over ZMODEM via an existing serial session.' This makes the purpose unambiguous and distinguishes it from low-level sibling operations like serial_write or serial_exec.

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

Usage Guidelines5/5

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

It provides explicit preconditions (lrzsz must be installed), explicit exclusions (do NOT manually run rz beforehand), and clear usage examples for recv_cmd, including directory changes like 'cd /home && rz'. It also warns against using serial_exec/write to start rz, making the when-not guidance specific.

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