ae-hw-bridge
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| HW_PUPPET_UART_PORT | No | Serial port path for the hw-puppet UART bridge interface (CDC 1: Transparent target console). By default, ae-hw-bridge automatically detects ports in the following priority order: 1. Environment variables HW_PUPPET_CONTROL_PORT / HW_PUPPET_UART_PORT, 2. Standard HW Puppet udev symlinks: /dev/hw-puppet-control / /dev/hw-puppet-uart, 3. Standard Linux CDC fallbacks: /dev/ttyACM0 and /dev/ttyACM1. | |
| HW_PUPPET_CONTROL_PORT | No | Serial port path for the hw-puppet control interface (CDC 0: MicroPython Raw REPL RPC). By default, ae-hw-bridge automatically detects ports in the following priority order: 1. Environment variables HW_PUPPET_CONTROL_PORT / HW_PUPPET_UART_PORT, 2. Standard HW Puppet udev symlinks: /dev/hw-puppet-control / /dev/hw-puppet-uart, 3. Standard Linux CDC fallbacks: /dev/ttyACM0 and /dev/ttyACM1. |
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 | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| clear_target_consoleA | Clear the target UART console circular buffer. Recommended before triggering a reset or running a test scenario to isolate fresh output. |
| get_bridge_infoA | Get bridge software version, connected hardware puppet firmware info, and active ports. Returns metadata including ae-hw-bridge package version, ESP32-S3 hw-puppet firmware build details (version, platform, git hash), and serial port paths. |
| read_target_consoleA | Read lines from the target board UART console buffer (CDC1). NOTE: This reads the passive UART reception ring buffer (e.g. bootloader or kernel output).
To read system logs from an already running Linux target, use Args: tail_lines: Number of most recent lines from the end of the buffer (default: 50 if head_lines not specified). head_lines: Number of earliest lines from the start of the buffer (e.g. first N lines of bootloader after reset). grep: Optional case-insensitive regex pattern to filter lines (e.g. 'panic|error|SafeRTOS'). |
| run_custom_codeA | Execute arbitrary MicroPython code directly in ESP32 RAM via CDC0 Raw REPL. Args: code: MicroPython source code string to execute. timeout: Maximum execution time in seconds before aborting (default: 10.0s). |
| send_target_commandA | Send an interactive command string to the target console and collect ONLY new response lines. Args: command: Shell command string to transmit to target UART (e.g. 'uname -a' or 'nvidia'). wait_timeout: Maximum seconds to wait before returning response (default: 5.0s hard ceiling). idle_threshold: Seconds of UART silence before considering output complete (default: 0.3s). |
| wait_for_console_patternA | Wait for a line matching regex pattern in target UART console stream. First checks recent buffer history (unless check_history=False). If not found, blocks until matching line appears or timeout expires. Ideal for waiting for bootloader, kernel messages, login prompts or errors after reset. Args: pattern: Regular expression to match (e.g. 'login:', r'(?:[$#]\s*$|\w+@\w+:.[$#]\s)', or 'kernel panic'). timeout: Maximum seconds to wait (default: 30.0s). check_history: If True, inspect recent buffered lines first before waiting for new lines (default: True). |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 6 tools
Tools mostly target distinct actions: clearing buffer, reading buffer, sending commands, waiting for patterns, executing MicroPython, and fetching bridge info. The three console-related tools (read, send, wait) have some inherent overlap but descriptions clarify when to use each, preventing most misselection.
All tool names use consistent snake_case with a verb_object pattern (clear_target_console, get_bridge_info, read_target_console, run_custom_code, send_target_command, wait_for_console_pattern). No deviations in style.
Six tools is well-scoped for a hardware bridge server; each tool covers a necessary operation (buffer management, info retrieval, console I/O, code execution, pattern waiting) without redundancy.
The surface covers core interactions: buffer clear/read, command send, pattern wait, code execution, and bridge info. An explicit reset tool is absent despite being mentioned in clear_target_console's description, but resets may be achievable via send_target_command or run_custom_code, leaving only a minor gap.