MCP.Market

J-Link MCP server

by Klievan·io.github.Klievan/jlink-mcp·v0.8.0·40 stars
No reviews yet

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

A85/100grade A
Write a reviewInstall
What users say
No reviews yet
Be the first
Safety scan
A85/100

full report

Adoption
Established

40 stars403 downloads/wk

Reviews

Write one

Nobody has reviewed J-Link MCP yet.

If you have run it, two minutes of your experience saves the next person an afternoon.

J-Link MCP tools (48, 4 write)

write = sends, deletes, buys or posts

Read from the package source without running it. The installed server may list more.

  • check_setup

    Check that everything needed to debug is in place: the probe software, a connected probe, a target

  • clear_breakpoints

    Clear all breakpoints, including any left armed in the debug hardware by an earlier session

  • 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.

  • device_info

    Halt the target and read its registers via …. Returns the probe name and a compact register summary. Leaves the target HALTED — call resume when you are done.

  • diagnose_crash

    Auto-read and decode ARM Cortex-M fault registers (CFSR, HFSR, MMFAR, BFAR), exception stack frame, and recent errors.

  • erase

    Erase target flash memory

  • flash

    Flash firmware to the target device

  • gdb_backtrace

    Get a stack backtrace. With debug symbols loaded, shows function names, file paths, and line numbers.

  • gdb_commandwrite action

    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_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_disconnect

    Disconnect the GDB client (does not stop the GDB server)

  • 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_server_start

    Start … GDB server

  • gdb_server_status

    Get GDB server, RTT, and telnet proxy status

  • gdb_server_stop

    Stop … GDB server and disconnect RTT

  • 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.

  • get_config

    Get current probe and server configuration

  • halt

    Halt the target CPU

  • 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.

  • list_peripherals

    List the target's peripherals and base addresses, from its CMSIS-SVD description. Requires an SVD file to be configured.

  • probe_commandwrite action

    Execute raw … commands

  • read_memory

    Read memory from the target. Returns clean hex dump.

  • 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.

  • read_register

    Read a specific CPU register by name

  • read_registers

    Read all CPU registers (compact format, FP only if non-zero).

  • reset

    Reset the target device. Halting leaves the core stopped at the reset vector,

  • resume

    Resume the target CPU

  • rtt_clear

    Clear RTT buffer

  • 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

  • rtt_search

    Search/filter RTT logs by level, module, or regex

  • rtt_sendwrite action

    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

  • search_devices

    Search the device names this J-Link installation accepts, by part number, manufacturer, or core.

  • set_breakpoint

    Set a hardware breakpoint

  • set_device

    Set the target device name at runtime. Required before any debugging commands will work.

  • set_rtt_address

    Tell the server where the firmware's RTT control block is (its _SEGGER_RTT symbol), at runtime.

  • set_serial_number

    Set the debug probe serial number at runtime. Required when multiple probes are connected to select which one to communicate with. Run list_devices to see connected serial numbers.

  • set_svd_path

    Point the server at a CMSIS-SVD file for the target at runtime, so peripheral reads come back

  • snapshot

    Capture complete device state: CPU registers (compact), fault status, recent RTT output, and stack dump.

  • start_debug_session

    One-call setup: starts GDB server via …, 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.

  • step

    Step one CPU instruction

  • telnet_proxy_read

    Read raw data from telnet proxy 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_status

    Get telnet proxy status

  • telnet_proxy_stop

    Stop telnet proxy

  • write_memorywrite action

    Write a 32-bit value to memory

Public scan report

scanner v0.1.10 · 2026-10-30 · same rubric, same numbers if you re-run it

1 medium
  • Code scan45 source files scanned20/25
  • –Live reliabilityno gateway calls yet and no remote to proben/a
  • –Tool poisoningtools not inspected (local package is not executed); not countedn/a
  • Auth qualitylocal package, no credentials required12/15
  • Maintenancelast push 4 days ago15/15
  • Maintainer identityregistry namespace matches repository owner; GitHub account older than a year8/10

Findings (1)

  • mediumeval / new Function usedexec.eval
    out/mcp/standalone.js: …ode, sch); const makeValidate = new Function(`${names_1.default.self}`, `${names_1.de…
Overall 85/100. Components that don't apply are left out of the denominator. Any critical finding is an F.RubricAppeal a findingJSON

How J-Link MCP compares

Against every graded MCP server, from our own scans and uptime checks. Updated after each scan run.

Safety score
85/100
higher than 70% of 48,255 servers
Tools
48
the typical server has 7
Tools that change things
8%
typical: 0%. Fewer write tools means less an agent can break
GitHub stars
40
more than 93% of 28,688 servers
Downloads a week
403
more than 85% of 12,191 servers with a package

What its tools let an agent do: 38 read · 1 create · 8 change · 1 run or deploy

Release history: 2 versions in the registry since 2026-08-28, latest 2026-10-26, typically one every 59 days.

Install J-Link MCP in Claude Code, Cursor or VS Code

Runs npx -y jlink-mcp on your machine. Read the scan report first; the gateway never runs local packages.

claude mcp add jlink-mcp -- npx -y jlink-mcp
Add to Cursor

What the publisher says

From the J-Link MCP repository's README, as published. We do not edit it. Read it on GitHub

jlink-mcp

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

See it work

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 State
Core: 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 Registers
CFSR=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:

Shortened. The full README is on GitHub.

Nothing above is checked by us. What we check is on the safety report.

J-Link MCP: common questions

Is J-Link MCP server safe?
Yes, by our scan: it is graded A (85/100). Read the J-Link MCP safety report
How do I install J-Link MCP?
It runs on your machine. Copy the Claude Code, Cursor, VS Code or Claude Desktop config from the install section.
Does J-Link MCP need an API key?
No secret keys are declared. It reads 4 settings from the environment.
Is J-Link MCP maintained?
The last commit was 9 days ago (2026-10-26). The latest release is v0.8.0.
How does J-Link MCP compare with other MCP servers?
safety score 85/100 (higher than 70% of 48,255 servers); tools 48 (the typical server has 7); tools that change things 8% (typical: 0%. Fewer write tools means less an agent can break). Full comparison.