smolmux
Related Servers
Alternatives to smolmux
No user-submitted related servers found.
Related Servers
- AlicenseAqualityCmaintenanceStateful MCP server for driving debug probes (J-Link) to flash, debug, and inspect embedded targets. Enables AI agents to perform flash, memory, breakpoint, and ELF/SVD-aware operations conversationally.4125 PyPI10MIT
- AlicenseNot gradedqualityBmaintenanceMCP server for embedded board debugging, providing structured serial capture, crash decoding, and flash-safe port arbitration via bounded CLI and MCP tools.2MIT
- AlicenseNot gradedqualityAmaintenanceMCP server for Agentic Hardware-in-the-Loop testing, enabling AI agents to probe, flash, reset, and validate embedded firmware on real hardware via bounded MCP tools.1,560 PyPI17Apache 2.0
- FlicenseBqualityCmaintenanceMCP server for running shell commands on a Linux development board via UART serial.1-
- AlicenseNot gradedqualityCmaintenanceAn MCP server that lets AI coding agents drive the full STM32 development loop—code generation, build, flash, debug, serial monitoring, and fault diagnosis—end to end via CubeIDE, CubeMX, CubeProgrammer, OpenOCD, and GDB.1MIT
- AlicenseAqualityAmaintenanceMCP server that lets LLMs talk to serial devices: microcontrollers, routers, modems, embedded Linux, anything with a UART.2350 PyPI7MIT
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.