# J-Link MCP [Health: Active]

**Category:** 📟 Embedded System  
**Repository:** https://github.com/Klievan/jlink-mcp  
**GitHub Stars:** 39  
**npm Downloads (last month):** 191  
**Views:** 0  
**Installs:** 0  
**Upvotes:** 0  
**Directory Page:** https://allmcps.com/mcp/j-link-mcp

## Description
Debug embedded firmware on real hardware: J-Link probes, Cortex-M faults, RTT logs, GDB.

## Tools
Capabilities this server exposes over MCP:

- **list_devices** — Scan for connected PROBES — the debuggers plugged into this machine, not target chips. Despite the name it does not list target devices; use search_devices for those. Shows probe serial numbers and whether one is reachable.
- **check_setup** — Check that everything needed to debug is in place: the probe software, a connected probe, a target device name, and the optional files that make output readable. Run this first when anything fails, or when starting on a machine for the first time.
- **set_svd_path** — Point the server at a CMSIS-SVD file for the target at runtime, so peripheral reads come back with named fields and decoded values instead of raw hex. Mirrors set_device — you do not have to restart with SVD_PATH set.
- **set_rtt_address** — Tell the server where the firmware's RTT control block is (its _SEGGER_RTT symbol), at runtime. Without it RTT cannot be recovered after a reset or flash, and a stopped stream is indistinguishable from a quiet device. Mirrors set_device.
- **search_devices** — Search the device names this J-Link installation accepts, by part number, manufacturer, or core. Use this before set_device instead of guessing a part number — the name must match exactly, and a wrong one fails in a way that looks like broken hardware.
- **set_device** — Set the target device name at runtime. Required before any debugging commands will work. The name must match J-Link's exactly — use search_devices to find it rather than guessing a part number. Examples: 'nRF52840_XXAA', 'nRF5340_xxAA_APP', 'STM32F407VG', 'STM32L476RG'.
- **start_debug_session** — One-call setup: starts GDB server via SEGGER J-Link, connects RTT (if supported), waits for initial output. This is the recommended first tool to call. If no device is configured, use list_devices and set_device first.
- **snapshot** — Capture complete device state: CPU registers (compact), fault status, recent RTT output, and stack dump.
- **diagnose_crash** — Auto-read and decode ARM Cortex-M fault registers (CFSR, HFSR, MMFAR, BFAR), exception stack frame, and recent errors.
- **device_info** — Halt the target and read its registers via SEGGER J-Link. Returns the probe name and a compact register summary. Leaves the target HALTED — call resume when you are done.
- **halt** — Halt the target CPU
- **resume** — Resume the target CPU
- **reset** — Reset the target device. Halting leaves the core stopped at the reset vector, which is where you want it before flashing, or to watch startup run.
- **step** — Step one CPU instruction
- **read_memory** — Read memory from the target. Returns clean hex dump.
- **write_memory** — Write a 32-bit value to memory
- **read_registers** — Read all CPU registers (compact format, FP only if non-zero).
- **read_register** — Read a specific CPU register by name
- **flash** — Flash firmware to the target device
- **erase** — Erase target flash memory
- **list_peripherals** — List the target's peripherals and base addresses, from its CMSIS-SVD description. Requires an SVD file to be configured.
- **read_peripheral** — Read every register of a peripheral from the target and decode each one's bit fields by name. This is read_memory plus the meaning of what was read.
- **decode_register** — Decode a value into named bit fields using the target's SVD. Reads from the device unless a value is supplied — useful for interpreting a number you already have.
- **set_breakpoint** — Set a hardware breakpoint
- **clear_breakpoints** — Clear all breakpoints, including any left armed in the debug hardware by an earlier session
- **gdb_server_start** — Start SEGGER J-Link GDB server
- **gdb_server_stop** — Stop SEGGER J-Link GDB server and disconnect RTT
- **gdb_server_status** — Get GDB server, RTT, and telnet proxy status
- **gdb_connect** — Connect a GDB client to the running GDB server. Enables source-level debugging: backtraces, variable inspection, conditional breakpoints, stepping by source line. Optionally load an ELF file for symbol info.
- **gdb_command** — Send any GDB command and get the response. For execution commands (continue, step, next, finish, until), blocks until the target stops or times out. If the target doesn't stop, use gdb_wait to poll. Examples: 'bt' (backtrace), 'info threads', 'print myVar', 'break main', 'continue', 'next', 'step', 'finish', 'info registers', 'x/10xw 0x20000000'
- **gdb_wait** — Poll for target stop after a continue/step that timed out. Returns the stop reason (breakpoint hit, signal, finished stepping, etc.) when the target halts.
- **gdb_load** — Load an ELF file into GDB. By default loads symbols only (for source-level debugging: backtraces with file:line, variable names). Set flash=true to also program it onto the target.
- **gdb_backtrace** — Get a stack backtrace. With debug symbols loaded, shows function names, file paths, and line numbers.
- **gdb_disconnect** — Disconnect the GDB client (does not stop the GDB server)
- **rtt_connect** — Connect to RTT
- **rtt_disconnect** — Disconnect from RTT
- **rtt_read** — Read RTT log lines (clean, parsed Zephyr format). Non-destructive — reading does not consume the buffer. Returns the NEWEST lines by default; oldest:true returns the start of the buffer. Note the buffer spans reflashes: its oldest lines may be from firmware you have since replaced. rtt_clear drops them.
- **rtt_search** — Search/filter RTT logs by level, module, or regex
- **rtt_send** — Send data to device via RTT down-channel
- **rtt_status** — Read SEGGER's RTT control block on the target: is it initialised, how much has the firmware written, and how much has the probe collected. Use this when RTT is silent — it separates a quiet device from a probe that stopped collecting, which look identical from rtt_read.
- **rtt_clear** — Clear RTT buffer
- **telnet_proxy_start** — Start a TCP relay that re-serves the RTT stream on another port, so an external decoder (Trice, Pigweed, or your own) can consume it alongside this server. It relays bytes; it does not decode them.
- **telnet_proxy_stop** — Stop telnet proxy
- **telnet_proxy_status** — Get telnet proxy status
- **telnet_proxy_read** — Read raw data from telnet proxy buffer
- **probe_command** — Execute raw SEGGER J-Link commands
- **get_config** — Get current probe and server configuration

## Claude Desktop Quick Installation
Install path detected from listing signals. Uses `npx` (confidence: high):

```json
"mcpServers": {
  "j-link-mcp": {
    "command": "npx",
    "args": ["-y","jlink-mcp"],
    "env": {
      "JLINK_DEVICE": "",
      "SVD_PATH": ""
    }
  }
}
```

**Requires environment variables:** `JLINK_DEVICE`, `SVD_PATH` — the values above are empty placeholders; fill in real credentials before running (see the repository for what each one is for).

## Documentation

## What J-Link MCP does

J-Link MCP exposes embedded debugging operations through the Model Context Protocol. It connects an MCP client to an ARM Cortex-M target using a SEGGER J-Link probe and provides operations for setup, firmware deployment, CPU control, memory inspection, register access, RTT output, and GDB-based debugging.

The workflow is suitable for boards connected to the host machine. It can identify attached probes, search the J-Link installation's supported target names, select an exact device name, and run a setup check before debugging. The server can also switch the selected target at runtime without restarting.

## How it works

A typical session begins with `check_setup` or `start_debug_session`. The setup check reports whether the J-Link software, probe, target selection, and optional readability files are available. `start_debug_session` starts the J-Link GDB server, connects RTT when supported, and waits for initial output.

Once connected, the agent can halt, resume, reset, or single-step the CPU. It can read all registers or a named register, inspect memory, write a 32-bit value, set hardware breakpoints, clear breakpoints, flash firmware, and erase target flash. `device_info` leaves the target halted, so the agent should call `resume` when continued execution is intended.

The GDB tools provide a second debugging path. `gdb_connect` attaches a GDB client to the running server and can load an ELF file for symbols. `gdb_command` accepts arbitrary GDB commands, including backtraces, variable inspection, source-level stepping, register inspection, and execution commands. Long-running execution commands can be followed with `gdb_wait` when needed.

## Setup and configuration

Install the SEGGER J-Link software, connect a J-Link probe to an ARM Cortex-M target, and use Node.js 18 or newer. The npm package can be launched without a build step:

```bash
npx -y jlink-mcp
```

Set `JLINK_DEVICE` to the target's exact J-Link device name when configuring the server manually. If the part name is unknown, call `search_devices` by part number, manufacturer, or core before calling `set_device`.

A CMSIS-SVD file can be supplied through `SVD_PATH` or selected later with `set_svd_path`. The RTT control-block address can likewise be configured at runtime with `set_rtt_address`. VS Code provides an extension that registers the server for MCP-aware chat clients, and Claude Code provides a plugin installation path.

## Tools and capabilities

- Capture combined CPU, fault, stack, and recent RTT state with `snapshot`.
- Decode Cortex-M fault registers and exception frames with `diagnose_crash`.
- List SVD-defined peripherals and read registers with named bit fields.
- Start, stop, and inspect the J-Link GDB server and RTT connection.
- Read and write target memory, flash firmware, erase flash, and control breakpoints.

## Limitations and notes

The target name must match the J-Link installation exactly; guessing a part number can produce an error that resembles a hardware failure. `list_devices` reports connected probes, not target chips. Peripheral names and decoded fields require a configured CMSIS-SVD file. RTT recovery after reset or flashing requires the RTT control-block address; without it, a stopped stream can look like a quiet device. The server operates on real connected hardware, so commands such as erase, flash, reset, halt, and memory writes affect the target.

_Full upstream README: https://allmcps.com/mcp/j-link-mcp/readme_