Embedded Debugger MCP: depure placas embarcadas por uma sonda

Para quem

Se você quer deixar a depuração de uma placa embarcada a um agente em vez de primeiro configurar um depurador gráfico completo, este serviço combina. É um servidor MCP em Rust que pode fazer descoberta de sondas, controle de alvo, leitura de memória, breakpoints, gravação, RTT e diagnóstico de crash orientado a agentes, via probe-rs ou o GDB Remote Serial Protocol do OpenOCD. Também traz uma linha de comando pequena e um fluxo de empacotamento usáveis antes de ligar um cliente MCP. Não é um manual de chip e não solda fios.

Notas oficiais:

https://github.com/adancurusul/embedded-debugger-mcp

O pré-requisito mais importante: trabalho de hardware precisa de uma sonda compatível, ou um openocd já em execução que exponha uma porta GDB, mais fiação SWD/JTAG utilizável. O texto oficial nomeia ST-Link, J-Link, DAPLink, Black Magic Probe ou uma sonda FTDI suportada; ESP32 pode usar openocd-esp32. Sem sonda, não comece a gravar.

Primeira tentativa em 3 minutos

Siga só o caminho oficial: clonar o repositório e depois um build Cargo de release.

Pré-requisitos: Rust / cargo instalados. Trabalho de hardware também precisa da sonda ou OpenOCD acima. A primeira tentativa é só descoberta — não programe flash.

Clone primeiro:

https://github.com/adancurusul/embedded-debugger-mcp.git

Comando de instalação:

cargo build --release

O binário fica em target/release/embedded-debugger-mcp.

Onde configurar: o cliente MCP define o comando como embedded-debugger-mcp serve. Por compatibilidade, executar o binário sem subcomando também serve MCP em stdio. A evidência não diz qual cliente é obrigatório; não acrescente uma relação de nomes.

Primeira chamada de baixo risco: só descoberta de sondas. Isso enumera sondas locais; não é halt nem gravação. Se for tocar o alvo, confirme primeiro a fiação. As ferramentas diagnose_fault e unwind_exception leem o sítio da exceção e ainda podem afetar firmware em execução — não as use na primeira tentativa.

Sinal de sucesso: o build de release termina, o cliente consegue subir serve e a descoberta devolve um inventário de sondas ou um conjunto claramente vazio. Se só o Cargo falhar, pare no build; não mude para flash.

Casos de uso

Caso 1: fazer descoberta de sondas e confirmar se um ST-Link, J-Link ou outro compatível é visto. O texto oficial coloca probe discovery primeiro no conjunto de ferramentas. Você pode conferir se o inventário mostra a sonda que você encaixou. A evidência não escreve o nome exato da função nem os parâmetros; não invente o que falta.

Caso 2: com o alvo já conectado, usar diagnose_fault ou unwind_exception para um crash. O texto oficial escreve isso como crash diagnosis. Combina quando a placa já parou numa exceção e você precisa que o agente leia o contexto de falha. Acesso à memória e RTT estão no mesmo conjunto, mas esta página não detalha larguras de leitura/escrita nem formatos de buffer. Até aqui só se confirma que os nomes de diagnóstico existem. flash programming e breakpoints são escritas com efeitos colaterais — não as use como primeiro exemplo.

Limites de uso

Sem sonda ou sem fiação SWD/JTAG, o trabalho de hardware não dá. O caminho OpenOCD precisa de um processo já em execução expondo uma porta GDB, por exemplo ESP32 com openocd-esp32. Gravação, breakpoints e halt mudam o estado do alvo. Não é risco zero, nem «sem tocar hardware», nem «sem ler memória».

O texto oficial também menciona Cortex-M, RISC-V e Xtensa, mas esta página não tem inventário de chips nem passos de desfazer. Este guia cobre só o build Cargo de release, stdio serve, descobrir primeiro e diagnosticar se precisar. Se outro fluxo não estiver escrito na mesma página, não extrapole.