J-Link MCP

[jlink-mcp logo]

jlink-mcp

Give AI hands to touch silicon.
An MCP server that lets LLMs debug embedded devices through SEGGER J-Link probes.

[MCP Server] [TypeScript] [J-Link] [ARM Cortex-M]

[GitHub Stars] [License] [npm] [npm downloads] [VS Code Marketplace] [Latest release] [MCP Compatible] [CI] [Hardware tested]

See it work

[A terminal session: the MCP server finds the probe, flashes firmware, opens a debug session, streams RTT logs, injects a fault, and decodes the resulting HardFault — naming the faulting instruction.]

Real MCP tool calls against a real nRF52840-DK. Reproduce it yourself: npm run demo

Your firmware just crashed. One tool call:

> diagnose_crash
## Crash Diagnosis
### CPU StateCore: PC=0x000000B8 SP=0x2003FFA8 R0=0x0000000A R1=0x000007FF R2=0x00000001 ...Status: XPSR=0x21000003 CONTROL=0x00000000 PRIMASK=0x00000000 ...Stack: MSP=0x2003FFA8 PSP=0x00000000
⚠ CPU is in exception handler (IPSR=0x00000003)
### Fault RegistersCFSR=0x01000000 HFSR=0x40000000 DFSR=0x00000000 MMFAR=0xe000edf8 BFAR=0xe000edf8
### Decoded Faults## UsageFault (UFSR):  - UNALIGNED: Unaligned memory access## HardFault (HFSR):  - FORCED: Forced HardFault (escalated from configurable fault)
### Exception Stack Frame  R0    = 0x0000000A     R1  = 0x000007FF  R12   = 0x00000000     LR  = 0x000001F5  PC    = 0x00000254     xPSR = 0x21000000
→ Faulting instruction at PC=0x00000254
### Recent Errors/Warnings from RTT  [WRN] sensor_drv: sample out of range, clamping seq=2

Fault decoded, exception frame unwound, faulting instruction named, and the device's own log correlated — from one call, without a human reading a datasheet to find out what bit 24 of CFSR means.

And it knows what the silicon is

Point it at your target's CMSIS-SVD file and peripheral registers stop being hex:

> read_peripheral FICR
FICR @ 0x10000000INFO.PART @ 0x10000100 = 0x00052840  (read-only)  [31:0]    PART             0x52840 → N52840INFO.RAM @ 0x1000010C = 0x00000100  (read-only)  [31:0]    RAM              0x100 → K256INFO.FLASH @ 0x10000110 = 0x00000400  (read-only)  [31:0]    FLASH            0x400 → K1024

0x400 means 1024 KB of flash — but only if you know that, and an LLM guessing at bit layouts is exactly the failure this avoids. The addresses come from the vendor's own description, and the meanings from its enumerations.

Both transcripts are verbatim output from an nRF52840-DK in this project's hardware test suite.

What is this?

jlink-mcp connects AI assistants (Claude, Copilot, etc.) to your embedded hardware via SEGGER J-Link debug probes using the Model Context Protocol.

Instead of manually typing J-Link commands, your AI assistant can:

• Read registers and memory to understand device state
• Flash firmware and reset devices
• Stream RTT logs and search them by level/module/regex
• Diagnose crashes by auto-decoding ARM Cortex-M fault registers
• Control execution — halt, step, resume, breakpoints
• Start GDB servers for full debugging sessions

Also supports OpenOCD (ST-Link, CMSIS-DAP, FTDI) and Black Magic Probe backends.

Installing

You need the SEGGER J-Link software — that is what this server drives — a probe connected to an ARM Cortex-M target, and Node 18+. For the other backends, OpenOCD or arm-none-eabi-gdb instead.

Claude Code — from the plugin marketplace. This brings the embedded-debugging skill along with the server, which is what stops an assistant guessing at your hardware:

/plugin marketplace add Klievan/jlink-mcp/plugin install jlink-mcp

Any other agent — point it at this repository and ask it to set itself up:

Install the MCP server at https://github.com/Klievan/jlink-mcp and configure it for my board.

It will find what it needs here. If you would rather do it by hand, the server is on npm and needs no build step: npx -y jlink-mcp, with JLINK_DEVICE set to your target. mcp-config.json is a config you can paste.

VS Code — install the extension. It registers the server for Copilot Chat, Claude, and any MCP-aware client, so there is nothing to configure.

Nix / NixOS — run directly from the flake without installing:

# Run standalone MCP servernix run github:Klievan/jlink-mcp
# Or in an MCP client configuration (e.g. Claude Desktop / Claude Code)# "command": "nix", "args": ["run", "github:Klievan/jlink-mcp", "--"]

Or add jlink-mcp and jlink-mcp-skills to your system configuration or flake:

# flake.nix inputsinputs.jlink-mcp.url = "github:Klievan/jlink-mcp";
# In your packages:inputs.jlink-mcp.packages.''${system}.jlink-mcpinputs.jlink-mcp.packages.''${system}.jlink-mcp-skills

Note for NixOS users: Add your preferred probe tools (segger-jlink / segger-jlink-headless, openocd, or gdb) to environment.systemPackages or your devShell. segger-jlink requires nixpkgs.config.allowUnfree = true; and services.udev.packages = [ pkgs.segger-jlink ]; for probe USB permissions.

Then check it

Ask for check_setup. One call, and it says what is missing and what to do:

Not ready to debug yet.
OK    probe software — J-Link software found at /Applications/SEGGER/JLinkBLOCK probe — none detected (Connecting to J-Link via USB...FAILED). Check the USB cable.BLOCK target device — not set. Find the exact name with search_devices, then set_device.note  SVD — not loaded, so peripheral reads stay raw hex. Set SVD_PATH to a CMSIS-SVD file.

You do not need your device's exact part number up front. search_devices searches all 9800 that J-Link supports, by part number, manufacturer, or core.

Tools (48)

Workflow Tools (start here)

Device Setup

Device Control

Peripherals (CMSIS-SVD)

Set jlinkMcp.svdPath to your target's SVD — the same file Cortex-Debug takes as svdFile. Vendors publish one per part.

Memory & Registers

Flash

Breakpoints

GDB Server

Source-Level Debugging

Attach a real GDB client for symbol-aware work — backtraces, variable inspection, and stepping by source line rather than by instruction.

RTT (Real-Time Transfer)

Telnet Proxy (Trice / Pigweed)

Advanced

The status bar knows who has the probe

A J-Link serves one client at a time, so a GDB server left running blocks everything else — and the usual way that happens is an assistant starting one through MCP and nobody noticing. The extension cannot detect that by remembering what it did: the MCP server runs in a separate process, so an LLM-started server is invisible to it.

So it watches the GDB port instead, which is true whoever is responsible. When something is listening the status bar turns amber and reads J-Link · MCP · 47m — who started it, and how long ago. Those are the two facts that turn "something has the probe" into "the assistant has had it since before lunch". Clicking offers to stop it.

The tooltip carries the rest: device, ports, whether RTT is up, and why it matters. And it never claims an uptime it did not watch — a server that was already running when the window opened is reported as known about for that long, not up for it.

It will not kill a process it cannot identify as a J-Link GDB server. A listening port proves something is there, not that it is ours.

The skill

The tools tell a model what it can do. They do not tell it what is worth doing, and two things go wrong constantly without that: models never think to load the ELF, so every backtrace is bare addresses; and they reason about what the hardware should be doing instead of spending one call asking it.

skills/embedded-debugging/SKILL.md is a Claude Code skill that covers both — the two files that change everything (ELF for names, SVD for meanings), the halt/read/resume rule, workflows for crashes, hangs, peripherals and silent devices, and a table of beliefs paired with the tool call that actually checks each one.

Claude Code picks it up if you install this repo as a plugin (.claude-plugin/plugin.json), or you can copy the directory into .claude/skills/ in your firmware project. MCP itself has no notion of skills — its portable equivalent is prompts, and this server ships four.

Its claims are tested. test/hil/s04-symbols.test.ts proves on real silicon that a backtrace without symbols has no function names, that loading the ELF gives them, and that a symbols-only load does not reprogram the device.

Multi-Probe Support

jlink-mcp supports multiple debug probe backends through a common ProbeBackend abstraction:

Selecting a Backend

# J-Link (default)PROBE_TYPE=jlink JLINK_DEVICE=nRF52840_XXAA node out/mcp/standalone.js
# OpenOCD with ST-LinkPROBE_TYPE=openocd \  OPENOCD_INTERFACE=interface/stlink.cfg \  OPENOCD_TARGET=target/stm32f4x.cfg \  node out/mcp/standalone.js
# Black Magic ProbePROBE_TYPE=blackmagic \  BMP_SERIAL_PORT=/dev/ttyACM0 \  node out/mcp/standalone.js

Architecture

┌─────────────────────────────────────────────────────┐│                    MCP Client                        ││          (Claude, Copilot, any MCP client)           │└──────────────────────┬──────────────────────────────┘                       │ JSON-RPC over stdio┌──────────────────────▼──────────────────────────────┐│                  jlink-mcp                           ││                                                      ││  ┌──────────┐  ┌──────────┐  ┌───────────────────┐  ││  │ 31 Tools │  │4 Resources│  │    4 Prompts      │  ││  └────┬─────┘  └────┬─────┘  └───────┬───────────┘  ││       │              │                │              ││  ┌────▼──────────────▼────────────────▼───────────┐  ││  │              ProbeBackend                       │  ││  │  ┌─────────┐ ┌─────────┐ ┌──────────────────┐  │  ││  │  │ J-Link  │ │ OpenOCD │ │ Black Magic Probe│  │  ││  │  └────┬────┘ └────┬────┘ └────────┬─────────┘  │  ││  └───────┼───────────┼───────────────┼─────────────┘  ││          │           │               │              ││  ┌───────▼───┐ ┌─────▼────┐ ┌───────▼──────────┐  ││  │ RTTClient │ │TelnetProxy│ │  ProcessManager  │  ││  └───────────┘ └──────────┘ └──────────────────┘  │└─────────────────────────────────────────────────────┘                       │          ┌────────────▼────────────┐          │    Debug Probe (USB)    │          │  → Target MCU (SWD/JTAG)│          └─────────────────────────┘

Source Layout

src/├── probe/│   ├── backend.ts      # ProbeBackend abstract class + shared utilities│   ├── jlink.ts        # SEGGER J-Link implementation│   ├── openocd.ts      # OpenOCD implementation│   ├── blackmagic.ts   # Black Magic Probe implementation│   └── factory.ts      # Probe creation from config├── mcp/│   ├── server.ts       # MCP server (45 tools, 4 resources, 4 prompts)│   └── standalone.ts   # Standalone entry (stdio transport)├── rtt/│   └── rtt-client.ts   # RTT client with ANSI stripping + Zephyr log parsing├── telnet/│   └── telnet-proxy.ts # TCP proxy for Trice/Pigweed detokenizer├── utils/│   ├── config.ts       # VSCode settings / env var config│   ├── logger.ts       # Logging│   └── process-manager.ts # Child process lifecycle└── extension.ts        # VSCode extension + MCP provider registration

Design Decisions (LLM-Optimized)

This server was built by having an AI use it against real hardware, then fixing every friction point.

What read_registers would give you

Raw JLinkExe output for halt; regs — 77 lines, of which about six carry information. Every token here costs context, and the register values are buried in the middle:

SEGGER J-Link Commander V9.70 (Compiled Aug 19 2026 12:16:13)DLL version V9.70, compiled Aug 19 2026 12:15:25Connecting to J-Link ...O.K.Firmware: J-Link OB-nRF5340-NordicSemi compiled Jun 11 2026 13:12:28Hardware version: V1.00J-Link uptime (since boot): 0d 00h 34m 29sS/N: 1050298247License(s): RDI, FlashBP, FlashDL, JFlash, GDB...30 more lines of connect banner...PC = 00000044, CycleCnt = 00EB67E5R0 = 20000000, R1 = 9D56C547, R2 = 00000000, R3 = 00000000...FPS0 = 00000000, FPS1 = 00000000, FPS2 = 00000000, FPS3 = 00000000...28 more lines of zeroed FP registers...

What it actually gives you

Three lines. Same information, grouped by what you would ask for:

Core: PC=0x00000046 SP=0x20010000 R0=0x20000000 R1=0x01D43416 R2=0x00000000 ...Status: XPSR=0x01000000 CONTROL=0x00000000 PRIMASK=0x00000000 BASEPRI=0x00000000Stack: MSP=0x20010000 PSP=0x00000000

Both captured from the same board. The rest of the design follows the same rule — return what was asked for, and nothing else:

• Output parsing strips the connection banner. Only data comes back.
• Registers are compact and grouped (core / status / stack).
• FP registers only shown if non-zero (they're usually all zeros).
• RTT output has ANSI escape codes stripped and Zephyr log format parsed into structured fields.
• Composite tools (start_debug_session, snapshot, diagnose_crash) replace multi-step workflows with single calls.
• Fault decoding is automatic — reads CFSR/HFSR/MMFAR/BFAR and explains each bit.
• rtt_search lets you find errors without reading the entire log.
• Peripheral registers decode through the vendor's own CMSIS-SVD, so the model reads RAM = K256 rather than guessing what 0x100 means in that field of that register.
• Failures say what to do. "Target is running; use halt" beats "could not read memory", and a fault-register read that did not happen reports itself rather than decoding zeroes into "no faults detected".

Verified on real hardware

Most of what can go wrong between an LLM and a debug probe fails quietly: a tool returns success with an empty payload, a parser drops half a line, a session dies and the next command reports something plausible instead. None of that is visible from reading the code, and a test suite that asserts "the call did not error" passes on all of it.

So this project runs a hardware tier: 58 tests against a real nRF52840-DK on a self-hosted runner, driving the actual MCP server over stdio exactly as a client would. It covers probe discovery, flash and verify, halt/step/resume under a live GDB session, memory and peripheral reads, RTT streaming and filtering, and crash diagnosis against faults injected on demand.

It has caught bugs that had been shipping green, including:

• diagnose_crash reporting "No faults detected" during real crashes — the memory-dump parser was dropping half of every line
• every GDB-routed tool returning empty output while the server reported itself healthy
• sessions leaving the target unbootable, with breakpoint comparators still armed that no reset clears
• reset reporting success while doing nothing at all — the GDB server is a synchronous remote and refuses commands while the target runs, so every command of the reset sequence was rejected in turn and the failure discarded
• the session teardown that disarms debug hardware being refused in its entirety for the same reason, and reporting "debug hardware disarmed" regardless — the fix above is what made this one visible
• a GDB server reported running when it had already exited, because startup returned on the spawn without waiting to see whether it got the probe
• RTT going silent after a reset or a flash — the target was still logging and the probe had stopped collecting, which reads exactly like a quiet device. Caught by reading the control block from both ends: 490 bytes written by the firmware, none collected
• an assignment that was silently discarded, taking RTT out for the rest of the session — the flag guarding it asked whether a state enum read GDB_RUNNING, when the question it meant to ask was whether the GDB server was running

Every one of those reported success. That is the point of the hardware tier, and the reason the suites assert on parsed content rather than on the call having returned without error — a suite that checked for errors would have passed on all of them.

Raw probe output captured during those runs is committed as golden transcripts, so a fast unit tier replays real device bytes in seconds on any machine — no probe required to catch a format regression.

npm test          # ~257 tests, seconds, no hardwarenpm run test:hil  # hardware tier; needs HIL=1 and a probe

Environment Variables

J-Link

OpenOCD

Black Magic Probe

Contributing

Adding a new probe backend:

1. Create src/probe/yourprobe.ts implementing ProbeBackend
2. Add a case to src/probe/factory.ts
3. That's it — all 31 MCP tools work automatically

License

MIT - see LICENSE

Built by The Sprk Factory