MCP Server for Segger RTT via J-Link
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| JLINK_SPEED | No | SWD speed in kHz | 4000 |
| RTT_CHANNEL | No | Default RTT channel | 0 |
| JLINK_DEVICE | No | Target device name | HC32L19x |
| JLINK_SERIAL | No | J-Link serial number | |
| RTT_POLL_INTERVAL_MS | No | Poll interval in ms | 10 |
| RTT_RING_BUFFER_SIZE | No | Ring buffer entries | 100 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| jlink_connectA | Connect to J-Link debugger and start RTT monitoring. Must be called before reading or writing RTT data. |
| jlink_disconnectA | Disconnect from J-Link debugger and stop RTT monitoring. |
| rtt_readB | Read accumulated RTT data from the ring buffer. Data is continuously collected by the background monitor thread. Use this to get output from the target device. |
| rtt_read_logA | Read the tail of the complete RTT log file. This is an independent broadcast sink (not drained by other clients), so it returns the full RTT output even while another client (e.g. the VSCode extension) is streaming via rtt_read. Prefer this over rtt_read when another consumer is active. |
| rtt_read_rawA | Read new bytes from the broadcast log starting at a byte offset. Non-draining and multi-consumer safe: ideal for a continuous monitor that must coexist with other readers without stealing their data. Pass the returned next_offset as 'offset' on the next call; if the log rotated (next_offset > file size), pass offset=0. Returns JSON: {"data": "...", "next_offset": N}. |
| rtt_writeA | Write data to RTT down-buffer (host -> device). The target device must be running RTT with a down-buffer listener. |
| rtt_list_devicesA | List available J-Link debuggers connected to the host. |
| jlink_statusA | Get current J-Link connection status and RTT buffer information. |
| rtt_clearA | Clear the RTT ring buffer. This does not clear the actual RTT buffers on the device. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool serves a distinct purpose: connection management (connect, disconnect, status), device listing (list_devices), buffer clearing (clear), and three reading variants with clear differences in behavior (draining vs non-draining, offset-based). The write tool handles host-to-device communication. No overlaps.
All tools follow a consistent verb_noun pattern with clear prefixes: 'jlink_' for debugger operations and 'rtt_' for RTT buffer operations. All use snake_case, making patterns predictable.
9 tools is well-suited for an RTT monitoring server. The set covers essential operations (connect, disconnect, status, list, clear, read variants, write) without unnecessary bloat or missing core functionality.
The surface covers the main workflow: connect, read (three modes for different consumer scenarios), write, disconnect, and status. Minor gaps: no tool to configure RTT buffer parameters or query RTT control block details, but these are typically fixed or set externally.