Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/klievan/jlink-mcp/embedded-debuggingnpx skills add Klievan/jlink-mcp --skill embedded-debugginggit clone --depth 1 https://github.com/Klievan/jlink-mcpWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00077 | $0.02164 |
| Opus 5 | $0.00039 | $0.01082 |
| Sonnet 5 | $0.00015 | $0.00433 |
| Haiku 4.5 | $0.00008 | $0.00216 |
Grade A, and why
embedded-debugging scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 182 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Embedded debugging over a debug probe
You are talking to a physical microcontroller through a debug probe. It is slower, more stateful, and far less forgiving than a process on your machine.
The single rule that matters: the device is the source of truth, and it is cheap to ask it. Nearly every wrong answer in this domain comes from reasoning about what the hardware "should" be doing instead of reading it.
Before you debug anything: two files that change everything
Most sessions are needlessly blind because these were never supplied. Check
get_config at the start and ask for whichever is missing.
The ELF gives you names
Without it you do not merely lose names — you lose the stack. Measured on an
nRF52840, the same halted target, one gdb_load apart:
# no symbols
#0 0x00000048 in ?? ()
# after gdb_load
#0 0x00000048 in rtt_puts (s=s@entry=0x520 "] <") at src/fixture.c:124
#1 0x000001c2 in log_line (level=0x59b "inf", module=0x54a "hil_fixture",
msg=0x58d "fixture ready") at src/fixture.c:158
#2 0x000002fa in main () at src/fixture.c:282
One anonymous frame becomes three named ones with arguments and line numbers. GDB cannot unwind past the top frame without the debug info, so "the caller" is not a question you can even ask until the ELF is loaded.
gdb_load { elfFile: "build/zephyr/zephyr.elf" } # symbols only, does not touch flash
This does not reprogram the device — it loads symbols into GDB. Pass
flash: true only when you actually intend to program it. The server halts
the target briefly to run it and puts it back, so you do not have to. Load the ELF that
matches the firmware currently on the target; a stale ELF gives confidently
wrong function names, which is worse than ??.
Once loaded: gdb_backtrace, and gdb_command for info locals,
print myStruct, x/16xw &buffer, and turning a faulting address into a line:
info line *0x2a4
Line 91 of "src/fixture.c" starts at address 0x2a4 <main> and ends at 0x2a8 <main+4>.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 182 lines · 77 tokens per session scan A bb2de185df67
embedded-debugging is a skill published in the GitHub repository Klievan/jlink-mcp (26 stars, last pushed 5d ago), licensed MIT. It adds 77 tokens to every session and 2,164 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
ek-omniprobe-ai
通过 EK-OmniProbe 本机 TCP/NDJSON 桥接读取串口文本与标准样本、分析日志和波形，并安全调节设备参数。用户要求观察串口数据、分析诊断输出、传感器或控制波形、评估调参效果、建议 PID 等参数、自动或半自动调参时使用。.
embedded-review
Expert code review for embedded/firmware projects with dual-model cross-review (Claude + Codex via ACP). Detects memory safety, interrupt hazards, RTOS pitfalls, hardware interface bugs, and C/C++ anti-patterns. Trigger when user asks to review embedded/firmware/MCU code changes, diffs, or PRs. Examples: 'review…
embedded-engineer
(oh-my-embedded) Senior embedded systems engineer. ESP32/STM32, FreeRTOS, RF design, power management, peripheral interfaces. Use for any embedded/firmware/electronics/hardware question.
firmware-debugger
(oh-my-embedded) Firmware debugging via GDB and serial monitor. Breakpoints, memory inspection, stack traces, JTAG/SWD. Requires debug probe.
component-sourcer
(oh-my-embedded) Electronic component search, BOM optimization, alternative parts finder. Searches JLCPCB/LCSC, Nexar/Octopart catalogs.
embedded-review
(oh-my-embedded) Embedded firmware code review. Memory safety, ISR correctness, RTOS pitfalls, peripheral interfaces, C/C++ UB traps. Severity P0-P3.