stm32-stlink-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_probesA | Lists connected ST-LINK probes via STM32_Programmer_CLI. Returns an empty list (not an error) if none are attached. |
| debug_connectA | Starts a debug session: spawns ST-LINK_gdbserver and arm-none-eabi-gdb (MI2), loads ELF symbols, and connects via |
| debug_disconnectA | Cleanly tears down a debug session's gdb and ST-LINK_gdbserver child processes. |
| debug_session_statusA | Reports the status of one debug session (by id), or lists all active sessions if id is omitted. |
| flash_standaloneA | One-shot flash via STM32_Programmer_CLI — no debug session required. Fails with DEVICE_BUSY if a debug session is already open on the same probe (it holds exclusive USB access); disconnect first, or use flash_load_in_session instead. |
| flash_load_in_sessionA | Reflashes the currently loaded ELF via gdb's |
| debug_runA | Resumes (continues) the target and waits for it to stop again (e.g. a breakpoint), up to a timeout. |
| debug_haltB | Interrupts the running target. |
| debug_resetA | Resets the target via ST-LINK_gdbserver's |
| debug_stepB | Steps the target: 'over' (next line, step over calls), 'into' (step into calls), or 'out' (finish the current function). |
| breakpoint_setB | Sets a breakpoint by file:line (e.g. main.c:42), symbol name (e.g. main), or address (e.g. *0x08000200). |
| breakpoint_clearA | Deletes a previously set breakpoint by its number. |
| breakpoint_listA | Lists breakpoints currently tracked on a session (those set via breakpoint_set). |
| memory_readA | Reads raw bytes from target memory at an address or symbol-address expression (e.g. '&my_global'). |
| memory_writeA | Writes raw bytes to target RAM/registers at an address. Blocked for addresses inside the flash window (use flash_standalone / flash_load_in_session for flash) unless STMCP_ALLOW_FLASH_ADDRESS_WRITE is set. |
| register_readA | Reads named core registers (default: all general-purpose + sp/lr/pc/xpsr) via gdb MI. |
| register_writeB | Writes a value to a named core register via gdb's |
| read_fault_registersA | One-call dump of Cortex-M SCB fault registers (CFSR/HFSR/MMFAR/BFAR/SHCSR/CPUID/ICSR) plus PC/SP/LR, with CFSR/HFSR bits decoded to flag names. Raw evidence only — no root-cause interpretation. |
| evaluate_expressionB | Symbol-aware expression evaluation in the current frame via gdb's -data-evaluate-expression — reads globals/locals by name, struct/array member access, pointer dereference, arithmetic, etc. |
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 19 tools
Each tool targets a distinct action: session lifecycle, run control, breakpoints, register/memory access, and flashing are clearly separated. The only similar pair, flash_standalone and flash_load_in_session, is explicitly differentiated by requiring or not requiring an active debug session.
All tool names are lowercase snake_case and mostly follow a predictable domain-prefixed verb pattern such as breakpoint_set, memory_read, and debug_run. Minor exceptions like debug_session_status and flash_standalone break the strict verb_noun pattern but remain easy to anticipate.
19 tools is on the heavier side, but the embedded debug workflow legitimately spans session management, execution control, breakpoints, register/memory inspection, fault diagnosis, and flashing. Each tool has a justifiable role, so the count feels slightly over ideal rather than bloated.
The toolset covers the full core debug loop: connect/disconnect, run/halt/reset/step, breakpoint management, register and memory access, expression evaluation, fault register dumps, and both standalone and in-session flashing. Missing conveniences like stack backtraces or watchpoints are minor gaps, not workflow-breaking omissions.