Skip to main content
Glama
gghammer

MCP J-Link Server

by gghammer

Related Servers

Alternatives to MCP J-Link Server

No user-submitted related servers found.

    Related Servers

    • A
      license
      B
      quality
      C
      maintenance
      Enables AI assistants to debug embedded devices via SEGGER J-Link probes, including reading memory, flashing firmware, streaming RTT logs, and diagnosing crashes.
      47
      111 npm
      32
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      Enables AI assistants like Claude to directly debug microcontrollers via JLink, supporting breakpoints, single-step, memory/register access, variable inspection, RTT logging, and firmware flashing.
      25
      6
      MIT
    • A
      license
      A
      quality
      D
      maintenance
      Enables AI assistants to interact with STM32 development boards via J-Link debugger using RTT communication, supporting connection, logging, memory operations, and firmware flashing through natural language.
      12
      1
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables AI agents to program, debug, and diagnose STM32H7S3 microcontrollers through SEGGER J-Link, with stateful debug sessions, memory/flash operations, GDB integration, RTT logging, and safety controls.
      MIT
    • A
      license
      A
      quality
      C
      maintenance
      Stateful MCP server for driving debug probes (J-Link) to flash, debug, and inspect embedded targets. Enables AI agents to perform flash, memory, breakpoint, and ELF/SVD-aware operations conversationally.
      41
      25 PyPI
      10
      MIT

    TDQS

    A3.8/5.0

    Scored across 21 tools

    Disambiguation5/5

    Every tool has a clearly distinct purpose with no ambiguity. Tools are well-organized into categories: core J-Link operations (connect, open, close, reset, go, halt, step), memory operations (read/write), register operations (read/write), flash operations (erase, flash), emulator management (list), status queries (get_status), and RTT operations (start, stop, read, write, get_status). Even similar-sounding tools like jlink_memory_read and jlink_register_read target different resources (memory vs CPU registers).

    Naming Consistency5/5

    Perfectly consistent snake_case naming throughout. All tools follow a clear prefix pattern: 'jlink_' for core debugger operations and 'rtt_' for RTT-specific operations, followed by descriptive verb_noun combinations (e.g., jlink_connect, jlink_memory_write, rtt_start). This creates a predictable and readable naming convention across all 21 tools.

    Tool Count4/5

    21 tools is slightly high but reasonable for a comprehensive embedded debugging server. The server covers multiple aspects: probe management, target control, memory/register access, flashing, and RTT communication. While some consolidation might be possible (e.g., register read/write could be one tool with a mode parameter), each tool earns its place by providing distinct functionality needed for embedded development workflows.

    Completeness5/5

    The tool surface provides complete coverage for J-Link debugging operations. It includes all essential CRUD/lifecycle operations: connection management (open/close/connect), target control (reset/halt/go/step), memory access (read/write), register access (read/write), flash programming (erase/flash), status monitoring, and RTT communication (start/stop/read/write). No obvious gaps exist for typical embedded debugging scenarios.

    Maintenance

    ActivityInactive
    ResponsivenessNo issues