smolmux
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
| prompts | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| serial_readA | Drain the output this MCP session buffered since the last read, without sending. Quick look after your own command; lossy across turns. Lossless capture: serial_output_history with since_seq. Waiting for known text: serial_wait_for. |
| serial_port_statusA | Check the link before sending, or when output looks wrong: port, baud, connected/suspended, by-id identity strength, pins, who holds write control, and connected clients. Boot progress: serial_boot_status. Crashes: serial_get_incidents. |
| serial_boot_statusA | Report cold-boot progress: which boot stages the device has reached, the furthest stage, and whether the boot has stalled. Requires the device profile to declare boot_stages; otherwise reports none. Use after a reset or power cycle; if stalled, check serial_get_incidents. |
| serial_wait_forA | Wait for a regex in serial output without sending. Use when you know the text to expect (a prompt, login:, a log line). Works for observers. Ends early on a critical anomaly ([ABORTED anomaly:...]). Open-ended listening: serial_monitor. Output that already arrived: serial_output_history. |
| serial_output_historyA | Read past output from the broker's shared history without consuming it. For anything you must not miss, page with since_seq (start at 0; pass the returned cursor back; check dropped and has_more). Without since_seq: text by seconds or last_bytes. serial_read is drain-only. |
| serial_get_incidentsA | List anomalies the broker detected in output (kernel panic, oops, hard fault, assert, watchdog, brownout, ESP resets, plus profile patterns) with the match and pre-context. Use when a boot stalls, a wait aborts, or output looks like a crash; pair with serial_output_history for the surrounding log. |
| serial_monitorA | Listen for a fixed time (default 30 s, max 300 s) and return what the device printed plus anomalies in that window. Use when you do not know what to expect; when you do, serial_wait_for returns as soon as it matches. |
| serial_generate_reportA | Markdown summary of device profile, port status and incidents. Use to open a debugging session or hand a human a snapshot; for one fact, call the single-purpose tool. |
| serial_list_portsA | List serial ports on this host with by-id paths and USB VID/PID (works without a broker). Use to pick a port before starting a broker, or when output is garbage (wrong port). Bridge chips name the adapter, not the MCU. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| bringup | Bring up a board on the smolmux serial broker: status, boot stages, and proof of life. |
| debug_serial | Capture serial output and diagnose crashes, stalls, or noise. |
| flash_safe | Release the port for an external flasher, then resume and verify boot. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
The four output-reading tools (serial_read, serial_output_history, serial_wait_for, serial_monitor) occupy adjacent territory, but their descriptions explicitly cross-reference each other and draw sharp boundaries (drain vs. lossless capture, known text vs. open-ended listen). The remaining tools target distinct concerns (ports, status, boot, incidents, report), so an agent can reliably pick apart.
All nine tools share the serial_ prefix, giving a strong predictable namespace. Most are verb_noun (serial_read, serial_wait_for, serial_list_ports, serial_get_incidents), though a few are noun_status forms (serial_port_status, serial_boot_status) — a minor deviation, not a genuine inconsistency.
Nine tools is well-scoped for a serial-debugging broker: each covers a distinct facet (port discovery, status, read/history, waiting/listening, boot, incidents, report). No tool appears redundant or padded.
Observational coverage is thorough — discovery, liveness, historical and live capture, waiting, anomaly detection, boot tracking, and reporting. The notable gap is that the surface is entirely read-only (no send/write tool), though the descriptions frame the server as an observer/broker, so this may be scoped intent rather than a true gap.