esp-runtime-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ESPBAUD | No | The serial baud rate; defaults follow $ESPBAUD. | |
| ESPPORT | No | The serial port to use; defaults follow $ESPPORT (e.g. /dev/ttyUSB0). Can also be a serial_for_url URL such as rfc2217://host:port. | |
| IDF_TOOLS_PATH | No | ESP-IDF tools path; used when looking up the target addr2line tool (xtensa-esp-elf-addr2line / riscv32-esp-elf-addr2line). | |
| ESP_RUNTIME_PROJECT_DIR | No | Path to the ESP-IDF project directory. Used to locate the ELF file via build/project_description.json for symbolisation/addr2line. |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_serial_portsA | List serial ports; |
| capture_logA | Read the device console until all Crashes found in the log are parsed and symbolised automatically. Check |
| analyze_logC | Find crashes (Guru Meditation, abort, assert, ESP_ERROR_CHECK, stack overflow, TWDT, heap corruption, brownout) and reset reasons in a log, and symbolise backtraces against the ELF. |
| decode_addressesB | Symbolise code addresses (function, file:line, inlining) with the toolchain's addr2line. For a 'Backtrace: PC:SP PC:SP' line only the PCs are decoded. |
| reset_deviceA | Hard-reset the chip via the RTS->EN auto-reset circuit (app boot, not download mode). |
| read_coredumpC | Run esp-coredump info_corefile and return the crashed task, its stack frames and the full report. |
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 target distinct actions: listing ports, capturing logs, analyzing logs, decoding addresses, resetting, reading coredumps. Slight overlap between capture_log (which also parses crashes) and analyze_log, but descriptions clarify the distinction.
All tools follow a consistent snake_case verb_noun pattern (list_serial_ports, capture_log, analyze_log, decode_addresses, reset_device, read_coredump). No mixing of conventions.
Six tools form a well-scoped set for ESP runtime debugging: port discovery, log capture, log analysis, address decoding, reset, and coredump reading. Each tool has a clear role without redundancy.
Core lifecycle for runtime debugging is covered: discovering ports, capturing/analyzing logs, decoding addresses, resetting, and reading coredumps. Minor gaps like device info query or serial write are not critical but could be useful.