Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP Server for Segger RTT via J-Link read the RTT data from the target device"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP server that provides access to Segger RTT (Real Time Transfer) through a J-Link debugger. This allows an LLM (like Claude) to interact with embedded devices by reading and writing RTT data.
Shared single-owner daemon — one long-lived SSE process owns the J-Link; Claude Code and the VSCode extension connect as clients, so they never fight over the single physical probe
Standalone fallback — a Claude-only session with no daemon running opens the J-Link directly (auto-detected; no config change needed)
RTT Read/Write — read up-buffer output, write commands to the down-buffer
Multi-consumer reads — a draining ring buffer (rtt_read) plus a non-draining broadcast log (rtt_read_log / rtt_read_raw), so a continuous monitor never steals bytes from an on-demand read
Real-time display — RTT data is continuously printed to terminal + a rotating log file while monitoring
Optional auth — opt-in bearer token (RTT_AUTH_TOKEN) gates /sse, /messages/ and /shutdown
Graceful shutdown — POST /shutdown releases the J-Link and stops the daemon cleanly (works around Windows TerminateProcess stranding the probe)
Related MCP server: Serial MCP Server
Python 3.10+
SEGGER J-Link Software installed (provides JLinkARM.dll/libjlinkarm.so)
A J-Link compatible debugger
Target device running SEGGER RTT
本工具装一次、全局可用——不绑死任何单片机工程，不依赖具体 VSCode 工作区。
Python 3.10+（在 PATH 上）
SEGGER J-Link 软件（提供 JLinkARM.dll；pylink 在连接 J-Link 时才加载它，安装期不强制）——连硬件前装好
可选：VS Code + code CLI（用配套扩展时需要）
# Windows（在 mcp-rtt-server 目录下）
powershell -ExecutionPolicy Bypass -File install.ps1# macOS / Linux
./install.sh脚本完成：非 editable pip install（生成 rtt-mcp-server / rtt-mcp-daemon / rtt-mcp-bridge 三个控制台脚本）→ 可选装 VSCode 扩展 → 在 Claude Code 用户级注册 rtt（绝对路径、无 cwd，任意工作区可用）→ 烟测。
cd mcp-rtt-server
pip install . # 部署用（非 editable）；开发用 pip install -e .注册到 Claude Code（用户级——任意工作区可用；用绝对 .exe，因 Claude 经 spawn 启动，Windows 下不搜 PATHEXT）：
# 取脚本目录
SCRIPTS=$(python -c "import sysconfig;print(sysconfig.get_path('scripts'))")
claude mcp remove --scope user rtt 2>/dev/null
claude mcp add --scope user rtt "$SCRIPTS/rtt-mcp-server.exe" # Windows
# claude mcp add --scope user rtt "$SCRIPTS/rtt-mcp-server" # macOS/Linuxrtt-mcp-daemon --help # 正常打印 usage 说明 import + console script OK守护进程是"单一 J-Link 拥有者"。VSCode 扩展会自动启动它；手动调试/独立使用时也可以自己起：
rtt-mcp-daemon --host 127.0.0.1 --port 8765不启动也没关系：Claude Code（
server.py）会探测守护进程，可达则经它代理，不可达则直接开 J-Link（独立会话模式）。
终端 A — 启动 MCP 服务器：
npx @modelcontextprotocol/inspector python -m mcp_rtt_server.server启动后会输出一个本地网址（如 http://localhost:6274/?...），在浏览器打开。
终端 B — 实时查看 RTT 数据：
# PowerShell
Get-Content .\rtt_output.log -Wait# Git Bash / WSL
tail -f ./rtt_output.log在浏览器 Inspector 中按顺序调用：
jlink_connect — 连接 J-Link 和目标设备，启动 RTT 监控
rtt_read — 读取环形缓冲区累积的 RTT 数据（读后清空）
rtt_read_log / rtt_read_raw — 读取广播日志（多消费者安全，不互相偷数据）
rtt_write — 向设备发送数据（需固件支持接收）
jlink_status — 查看连接状态和缓冲区信息
jlink_disconnect — 断开连接
一键脚本已自动注册（用户级，任意工作区可用）。手动注册：
# 用 install.ps1 / install.sh，或：
SCRIPTS=$(python -c "import sysconfig;print(sysconfig.get_path('scripts'))")
claude mcp add --scope user rtt "$SCRIPTS/rtt-mcp-server.exe" # Windows
# claude mcp add --scope user rtt "$SCRIPTS/rtt-mcp-server" # macOS/Linux用户级（user scope）= 与工程无关：注册一次后，任意 Claude Code 会话（无论打开哪个工作区）都能用
rtt工具。不要在项目.claude/settings.json里重复写mcpServers.rtt——那会用绝对路径覆盖用户级配置。
指定芯片：默认设备
Cortex-M0+（泛用）。针对某工程固定芯片，按工程覆盖环境变量：claude mcp remove --scope user rtt claude mcp add --scope user rtt "$SCRIPTS/rtt-mcp-server.exe" -e JLINK_DEVICE=HC32L19x或调用
jlink_connect时直接传device参数（优先级最高）。
单拥有者行为：
server.py启动时探测守护进程（http://127.0.0.1:8765/sse）——可达则经 SSE 代理所有工具调用（不开第二个 J-Link），与 VSCode 扩展共享同一连接，零争用；守护进程未运行则自动回退为直接开 J-Link（Claude-only 会话）。无需手动选择模式。
重启 Claude Code 会话后，可直接用自然语言与设备交互，例如：
"连接 RTT 读取设备数据"
"查看设备状态"
编辑 %APPDATA%\Claude\claude_desktop_config.json：
{
"mcpServers": {
"rtt": {
"command": "python",
"args": ["-m", "mcp_rtt_server.server"],
"cwd": "."
}
}
}注意：
cwd需要改为本项目的实际绝对路径，因为 Claude Desktop 不会自动定位到项目目录。
Tool | Description |
| Connect to J-Link and start RTT monitoring |
| Disconnect from J-Link |
| Get connection status and buffer info |
| List available J-Link devices |
| Read accumulated RTT data from the draining ring buffer (read-once) |
| Read the tail of the broadcast log (non-draining; full output even while another client streams) |
| Read new log bytes from a byte offset (non-draining, multi-consumer safe; returns |
| Write data to RTT down-buffer |
| Clear the RTT ring buffer |
读哪个？ 单消费者随手读用
rtt_read；持续监视器、或与其它客户端（如 VSCode 扩展）同时读时，用rtt_read_log/rtt_read_raw，互不偷数据。
> jlink_connect(device="HC32L19x")
Connected to J-Link device 'HC32L19x' (serial: 12345678, speed: 4000 kHz)
RTT monitoring started on channel 0
> rtt_read()
[OSAL] HC32L19x OSAL starting...
[RTT] SEGGER RTT initialized
[OSAL] Registering tasks...
[OSAL] Starting scheduler...
> rtt_write(channel=0, data="status\r\n")
Wrote 7 bytes to RTT channel 0单一 J-Link 拥有者模型：守护进程 http_server.py 是唯一 pylink.open() 的进程。Claude Code 与 VSCode 扩展都作为客户端连到它，永不开第二个 J-Link，因此不会争抢探针、也不会互相偷走 RTT 数据。
┌──────────────┐ ┌────────────────────┐
│ Claude Code │ stdio │ server.py │
│ │────────│ 探测 daemon: │
└──────────────┘ │ 可达→SSE 代理 │
│ 不可达→直接开 J-Link│
└─────────┬──────────┘
│ (可达时)
┌──────────────┐ ┌─────────▼──────────┐ ┌──────────────┐
│ VSCode 扩展 │ stdio │ bridge.py │ SSE │ http_server │
│ (RttProvider)│────────│ (stdio↔SSE 桥) │─────│ (DAEMON) │
└──────────────┘ └────────────────────┘ │ 单一拥有者 │
└──────┬───────┘
│ pylink
▼
┌──────────────┐
│ JLinkARM.dll │
└──────┬───────┘
│ USB
▼
┌──────────────┐
│ J-Link Probe │── SWD ──▶ Target (任意 MCU, SEGGER RTT)
└──────────────┘模块职责
模块 | 角色 |
| 守护进程，SSE 传输，唯一持有 J-Link； |
| stdio↔SSE 桥（VSCode 扩展用）；提供 |
| Claude Code 入口；daemon 可达则代理，不可达则回退为直接拥有者 |
| pylink 封装：后台监视线程、环形缓冲、广播日志、轮转 |
| 9 个 MCP 工具；所有阻塞 pylink 调用经 |
POST /shutdown（可选 Authorization: Bearer <token>）→ rtt.disconnect()（rtt_stop + close）→ uvicorn 干净退出。VSCode 扩展停掉守护进程时先调它，再回退到 kill() —— 这避免了 Windows TerminateProcess 硬杀导致 J-Link 卡在 RTT-started 状态。atexit 钩子作为 Ctrl-C / 正常退出的兜底。
Variable | Default | Description |
| (none) | J-Link serial number |
|
| Target device name（泛用默认；按工程覆盖，如 |
|
| SWD speed in kHz |
|
| RAM 起始地址（扫描 RTT 控制块用，按 MCU 调整） |
|
| RAM 扫描窗口大小（字节，按 MCU 调整） |
|
| Default RTT channel |
|
| Ring buffer entries |
|
| Poll interval in ms |
| 可移植默认 | RTT 输出日志路径（留空= |
|
| 守护进程 SSE 地址（ |
| (none) | 可选：设此值后 |
Make sure J-Link software is installed
Check that J-Link is connected via USB
Try running as administrator/root
J-Link 被锁住（卡在 RTT-started）：上一次进程被 Windows TerminateProcess 硬杀，没释放。用 POST http://127.0.0.1:8765/shutdown 优雅释放，或拔插 J-Link USB。
这是预期行为：扩展在用环形缓冲（rtt_read 会清空）。改用 rtt_read_log 或 rtt_read_raw，它们读广播日志，不被任何消费者清空。
Check if the device name is correct
Try using rtt_list_devices to see available probes
Verify the target is connected and powered
Make sure the target firmware calls SEGGER_RTT_Init()
Check that RTT buffers are configured in SEGGER_RTT_Conf.h
MIT
Connect to J-Link debugger and start RTT monitoring. Must be called before reading or writing RTT data.
| Name | Required | Description | Default |
|---|---|---|---|
| speed | No | JTAG/SWD speed in kHz (default: 4000). | |
| device | No | Target device name (default: Cortex-M0+). Examples: HC32L19x, STM32F103, Cortex-M0+, etc. | Cortex-M0+ |
| serial | No | J-Link serial number (optional). If not provided, connects to first available J-Link. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses the main behavior (connect and start RTT monitoring) but does not detail side effects, connection management, or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no wasted words, and the critical prerequisite is front-loaded. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (3 params, no output schema), the description adequately covers the tool's purpose and usage order. Could mention return value or state, but not required.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds no extra parameter meaning beyond the schema, which already includes defaults and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the verb 'Connect' and resource 'J-Link debugger and start RTT monitoring'. Distinguishes from siblings like jlink_disconnect by specifying it is a prerequisite for RTT operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states it must be called before reading/writing RTT data, providing clear when-to-use context. Does not mention alternatives or when not to use, but the sibling tools imply the usage sequence.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Disconnect from J-Link debugger and stop RTT monitoring.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It states the basic effect (disconnect and stop RTT), but does not disclose side effects, error handling, or behavior when called without an active connection.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the action. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that there are no annotations or output schema, the description is minimal but covers the core action. However, it would benefit from additional context such as when it's appropriate to call (e.g., only when connected) to be fully complete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema description coverage is 100%. The description adds no additional parameter information, which is acceptable for a parameterless tool. Baseline is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action: disconnecting from J-Link debugger and stopping RTT monitoring. The verb 'Disconnect' and specific resource distinguish it from sibling tools like jlink_connect and rtt_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. While it's implied that it should be called after a connection, there is no explicit context, prerequisites, or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current J-Link connection status and RTT buffer information.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the tool retrieves status and RTT buffer info, but does not disclose behavioral traits like read-only nature, required connection state, or error handling. This is minimal but not misleading.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It is concise and efficient, though slightly more detail could be added without bloat.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is the sole source. It covers the tool's purpose but lacks details on return format or behavior under various conditions (e.g., when not connected). Adequate but could be more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters (schema coverage 100%), so the description adds value by specifying what information is retrieved (status and RTT buffer). No parameter explanation needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a clear verb 'Get' and specifies the resource 'current J-Link connection status and RTT buffer information', effectively distinguishing it from sibling tools like jlink_connect or rtt_read.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, such as when to check status vs. connecting or reading RTT data. Implicitly it is for status queries, but lacks context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the RTT ring buffer. This does not clear the actual RTT buffers on the device.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It reveals the non-destructive nature (does not clear device buffers) but omits any side effects, permissions, or return behavior, leaving the agent with incomplete behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two terse sentences convey the essential information without redundancy or unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, simple action, the description covers the core behavior and clarifies what it does not affect. Minor gap: lacks any usage cues or prerequisites.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema coverage is 100%, so the description need not add parameter info. Baseline 4 is appropriate; no deduction needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Clear the RTT ring buffer') and explicitly distinguishes it from not clearing the actual device buffers, which differentiates it from sibling tools like rtt_write or rtt_read that operate on device buffers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool (e.g., after certain operations) or when to prefer alternatives. It only states what it does, lacking context for the agent to decide appropriateness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available J-Link debuggers connected to the host.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description is the sole source. It states 'List' which implies read-only, but no details on potential exceptions (e.g., no devices), performance, or security. Barely adequate for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with no redundant words. Every word adds value, and the structure is optimal for quick parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is mostly complete. It could mention the expected return format (e.g., list of device names) or behavior when none found, but for a simple list, this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema description coverage is 100%. The description adds context beyond the schema by specifying the scope ('J-Link debuggers connected to the host'), which helps the agent understand what is being listed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List available J-Link debuggers connected to the host.' The verb 'List' and resource 'J-Link debuggers' are specific. Sibling tools like jlink_connect or rtt_read confirm this is a distinct listing operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. While it's implied to run before connecting, the description does not mention prerequisites, conditions, or disclaimers. Sibling tools exist but are not referenced.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| channel | No | RTT channel to read from (default: 0). | |
| max_bytes | No | Maximum bytes to return (default: 512). Note: This reads from the accumulated buffer. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions reading from an accumulated buffer but does not clarify whether data is consumed or cleared, what happens on multiple reads, or if there are any destructive side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loading the action and resource immediately. Every sentence adds value with no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given low complexity (2 parameters, no output schema), the description covers the basic purpose and parameter context. However, missing behavioral details (e.g., whether reading is destructive, thread safety) make it slightly incomplete. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds a note 'This reads from the accumulated buffer' which adds context beyond the schema, but does not provide additional parameter-level detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Read' and the resource 'accumulated RTT data from the ring buffer'. It also provides context about the background monitor thread. However, it does not explicitly differentiate from sibling tools like rtt_read_log or rtt_read_raw, leaving slight ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description includes 'Use this to get output from the target device' as a general guidance, but lacks explicit when-to-use or when-not-to-use instructions. No alternatives are mentioned, despite siblings like rtt_read_raw or rtt_read_log existing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| max_bytes | No | Maximum bytes to return from the end of the log (default: 8192). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description discloses key behavior: independent broadcast sink, not drained by other clients, returns full output while others stream. Does not cover error conditions or side effects, but adequate for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words, front-loaded with purpose, then adds behavioral context and usage advice. Highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given tool simplicity (one optional param, no output schema), description covers key differentiator and usage context. Slight lack of return format detail, but not essential.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with clear descriptions. Tool description adds no further semantic meaning beyond schema, baseline of 3 appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'Read the tail of the complete RTT log file' and specifies it as an 'independent broadcast sink', distinguishing it from sibling rtt_read by noting it returns full output even with another consumer active.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance to prefer this over rtt_read when another consumer is active. However, lacks comprehensive when-not-to-use advice for all sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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}.
| Name | Required | Description | Default |
|---|---|---|---|
| offset | No | Byte offset to read from (default: 0). | |
| max_bytes | No | Maximum bytes to return (default: 8192). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses key behaviors: non-draining, multi-consumer safe, offset handling for rotation, and return format. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, no fluff. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely covers usage pattern, behavior, and return structure for a tool with simple parameters and no output schema. No gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%; description adds critical context beyond schema: explains the relationship between offset and next_offset, rotation handling, and the purpose of max_bytes implicitly through the return format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly specifies the action ('Read new bytes from the broadcast log starting at a byte offset') and distinguishes from siblings by highlighting 'non-draining and multi-consumer safe' behavior, contrasting with other RTT read tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use this tool ('ideal for a continuous monitor that must coexist with other readers without stealing their data') and includes usage instructions for handling offset and rotation. Lacks explicit 'when not to use' but the sibling list implies alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write data to RTT down-buffer (host -> device). The target device must be running RTT with a down-buffer listener.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | String data to send to the target device. | |
| channel | No | RTT channel to write to (default: 0). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses that the tool writes data (a destructive/mutating operation) and requires a specific condition. However, it lacks details on error handling, return values, or blocking behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the action, no unnecessary words or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 2 parameters (all documented), no output schema, and no annotations. The description covers the basic purpose and precondition but does not specify return values or behavior on failure, leaving some gaps for complex use cases.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description does not add additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('write data'), direction ('host -> device'), and target ('RTT down-buffer'), distinguishing it from sibling tools like rtt_read (reads data) or rtt_clear (clears buffer).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states a prerequisite: the target device must be running RTT with a down-buffer listener. This gives clear guidance on when the tool can be used, though it does not mention alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0jlink_connectjlink_disconnectjlink_statusrtt_clearrtt_list_devicesrtt_readrtt_read_logrtt_read_rawrtt_writeEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
Give your agent live data from Twitter, Reddit, the web and GitHub. No API keys, no scraping stack.
Develop, manage, and debug Railway projects, services, and deployments from within agents.
Talk to your public-facing AI from any MCP client — Claude, ChatGPT, Cursor, Cline, Windsurf.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ForeverJin/rtt_mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
