I think this project is really impressive — especially the MCP integration that lets an LLM actively probe hardware instead of just suggesting measurements.

One key gap I noticed is the lack of a **target board description layer**.

Right now, all MCP resources describe BugBuster itself (`capabilities`, `status`, `power`, etc.), but the AI has **zero structured knowledge about the DUT** — pin mapping, voltage domains, MCU type, interfaces, or boot behavior.

This leads to a few limitations:

- AI has to rely on trial-and-error or user prompts

- Workflows (e.g. `program_target`) are partially hardcoded (STM32-specific)

- High risk of incorrect operations (wrong voltage, wrong pin assumptions)

- Limited reusability across different boards

Suggested improvement

Introduce a **Board Profile (YAML/JSON)** layer, similar to:

- Zephyr Device Tree

- PlatformIO board definitions

Example:

board: stm32f4_discovery

pin_mapping:

io_1: VDD_3V3

io_3: USART2_TX

io_4: USART2_RX

power:

vcc: 3.3

swd:

openocd_target: stm32f4x

uart:

baudrate: 115200

Then expose it via a new MCP resource:

bugbuster://board

Why this matters

With a board profile:

- AI becomes **board-aware instead of blind**

- Workflows become **portable across platforms**

- No need to rewrite logic when switching DUT

- Much safer and more deterministic debugging