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 | Read buffered serial output without sending anything (session drain; prefer history for lossless capture). |
| serial_port_statusA | Get the current status of the serial port and connected clients. |
| 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. |
| serial_wait_forA | Wait for a regex in serial output without sending. Works for observers. Ends early on critical anomaly (ABORTED). |
| serial_output_historyA | Non-destructive history. With since_seq: JSON cursor page. Without: prose by time/bytes. serial_read is drain-only. |
| serial_get_incidentsB | Get detected anomalies/crashes from the broker. |
| serial_monitorB | Monitor serial output for a duration, returning output and anomalies. |
| serial_generate_reportB | Generate a status report for the serial device. |
| serial_list_portsB | List serial ports with by-id and USB VID/PID when available. 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
Most tools target distinct capabilities (read/drain, history, monitor, wait_for, incidents, boot, status, list, report), and descriptions explicitly differentiate read vs history vs monitor. However serial_read, serial_output_history, and serial_monitor all surface serial output and could still be confused, and serial_port_status vs serial_list_ports overlap somewhat.
All tools share the predictable serial_ prefix, which makes the namespace cohesive. The suffix style varies (read, port_status, boot_status, wait_for, get_incidents, output_history, monitor, generate_report, list_ports), mixing noun_status and verb_noun forms, but it remains readable.
Nine tools is well within the ideal 3-15 range and each maps to a distinct observation/reporting concern for a serial device debugger. No obvious filler or redundancy in count.
The observation side is thorough (read, history, monitor, wait, incidents, boot, status, report), but repeated phrasing 'without sending anything' strongly implies a serial write/send capability that is absent, leaving an obvious gap for interactive control. No config/session-management operations beyond status either.