Skip to main content
Glama
deenesjakoruzh
LukeLamb

claude-rocm-mcp

by LukeLamb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Claude ROCm GPU 监控器

适用于 Linux 上 Claude Desktop 的只读 AMD GPU 监控工具。让 Claude 能够回答诸如 “我的训练任务运行正常吗？”、“GPU 温度是多少？”、“还剩多少显存？” 以及 “哪个进程正在使用显卡？” 等问题，且完全不具备终止进程、更改时钟频率或干扰正在运行的工作负载的能力。

它通过调用 rocm-smi（以及可选的 amdgpu_top）来提供五个严格只读的工具。它不提供终止进程、覆盖时钟/功耗设置或风扇控制功能。如需这些功能，请使用 gpu-kill 等工具。

要求

  • Linux 系统，配备 AMD GPU（RDNA2/3/4 消费级显卡 — RX 6000/7000/9000, R9700 — 以及 CDNA 数据中心显卡）。

  • 已加载 amdgpu 内核模块（现代 Ubuntu/Debian/Fedora 系统标配）。

  • 已安装 rocm-smi：

    sudo apt install rocm-smi            # minimal
# or a full ROCm stack:
# https://rocm.docs.amd.com/projects/install-on-linux/

某些指标（时钟频率、功耗、详细温度）需要较新的 ROCm 版本。如果您的显卡/驱动程序不支持某项指标，该工具将返回 null 而不是报错。

Related MCP server: System Monitor MCP Server

安装 (Claude Desktop)

  1. 从 Releases 页面下载最新的 ROCm.mcpb。

  2. 在 Claude Desktop 中，打开 Settings → Extensions。

  3. 滚动到底部的 Extension Developer，点击 Install Extension，然后选择 .mcpb 文件。

  4. 启用该扩展。工具将出现在 Claude 的工具选择器中，并带有 rocm-gpu-monitor: 前缀。

工具

工具

功能

gpu_status

一次性摘要：名称、利用率 %、已用/总显存、温度（边缘/结温/显存）、平均/最大功耗、风扇 %/转速。

gpu_metrics

完整的 rocm-smi -a --json 转储 — 时钟频率、电压、PCIe 链路、固件版本、各引擎活动。

gpu_processes

使用 GPU 的计算进程（KFD PID），包含显存使用量和显卡索引。

gpu_watch

以固定间隔采集 N 个样本，并返回原始帧数据以及每张显卡的最小/最大/平均统计信息。

rocm_info

已安装的 ROCm/HIP 软件包、驱动程序版本、amdgpu 模块加载状态、amdgpu_top 可用性。

所有工具均带有 MCP readOnlyHint: true / destructiveHint: false / openWorldHint: false 注解。

示例提示词

“我的训练任务稳定吗？监控 GPU 20 秒。”

“我当前的 PyTorch 进程占用了多少显存？”

“GPU 是否在进行热节流？结温是多少？”

“安装了什么版本的 ROCm，驱动程序加载了吗？”

隐私政策

此扩展完全在您的本地机器上运行，仅调用以下程序，且始终为只读模式：

  • rocm-smi — 查询 AMD 内核驱动程序以获取设备指标。

  • amdgpu_top（如果已安装）— 可选的更丰富指标。

  • dpkg -l — 按名称/版本枚举已安装的 ROCm 相关软件包。

  • lsmod — 检查 amdgpu 内核模块是否已加载。

  • which — 在启动时定位上述二进制文件。

没有任何数据会离开您的机器。 此扩展不执行任何网络 I/O，不打开任何套接字，除了标准进程 stdout/stderr（由 Claude Desktop 的日志目录捕获）外，不写入任何文件。它无法修改 GPU 状态（时钟、功耗、风扇）、终止进程或以其他方式干扰正在运行的工作负载 — 每个工具都是严格只读的。

Claude 可见的信息包括 GPU 型号和固件版本、当前显存使用量、温度/时钟/功耗读数、正在使用 GPU 的进程 PID 及其显存使用量，以及已安装的 ROCm 相关软件包列表。如果您认为其中任何信息属于敏感信息（例如共享机器上正在运行的进程 PID 列表），请勿启用此扩展。

故障排除

“rocm-smi is not installed” — 请安装它 (sudo apt install rocm-smi)。如果您使用的是非 Debian 发行版，请遵循 AMD 的 ROCm 安装说明。

在新显卡上许多字段返回 null — 某些指标（时钟、功耗、温度）取决于 rocm-smi 暴露的固件支持。在非常新的显卡（例如 RDNA4/R9700）上，即使 -a --json 返回数据，单独的 rocm-smi --showclocks/--showpower 也可能报告“No JSON data to report”。此扩展使用 -a --json 作为主要来源以最大化覆盖范围。如果您的显卡不支持特定字段，它将返回 null 而不是错误。

权限错误 — rocm-smi 通常无需 root 权限即可运行。如果您看到权限错误，请检查运行 Claude Desktop 的用户是否在 render 和 video 组中：

sudo usermod -aG render,video $USER
# log out and back in

开发

该服务器是一个约 300 行的 Node.js 脚本，没有任何 npm 依赖。要重新构建 .mcpb：

cd bundle-source
zip -j ../ROCm.mcpb manifest.json package.json server.js README.md LICENSE icon.png

许可证

MIT。请参阅 LICENSE。

相关

Available Tools

5 tools
gpu_metricsA
Read-only

Full rocm-smi -a --json output for every GPU (clocks, voltages, PCIe link width/speed, firmware versions, per-engine activity, throttle status, energy counters). Use when gpu_status is not enough. The shape is rocm-smi’s native JSON, unmodified.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.7/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark readOnlyHint=true and destructiveHint=false. The description adds context about the tool being a full dump (clocks, voltages, PCIe, firmware, etc.) and that the output is unmodified, which is helpful beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loading the core purpose and details. Every sentence adds value: first defines tool, second provides usage guidance. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and no output schema, the description sufficiently explains what the tool returns (full rocm-smi -a --json output) and when to use it. Annotations complement the read-only nature. Complete for a simple metrics tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has no parameters, and schema coverage is 100%. With zero params, the description does not need to add parameter info. Baseline of 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns full rocm-smi -a --json output for every GPU with specific fields listed. It distinguishes from sibling tools by indicating when to use it (when gpu_status is not enough).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states 'Use when gpu_status is not enough', providing clear guidance on when to prefer this tool over alternatives. Also notes the output shape is unmodified rocm-smi JSON.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gpu_processesA
Read-only

List compute processes using the GPU (KFD PIDs) with their VRAM usage and card index. Returns an empty list when no compute workloads are running.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Description adds behavioral context beyond annotations (e.g., returns empty list when no workloads) and confirms read-only nature. 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.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two succinct sentences covering purpose and behavior, front-loaded with the action, no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Without output schema, the description outlines return content (compute processes, VRAM, card index) and edge case. Could specify field details, but adequate for such a simple tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline 4 applies. Description need not add parameter info.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses specific verb 'List' and resource 'compute processes using the GPU (KFD PIDs)', clearly distinguishing it from siblings like gpu_metrics or gpu_status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs alternatives (e.g., gpu_watch, rocm_info), and no exclusions or prerequisites mentioned.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gpu_statusA
Read-only

One-shot summary of all AMD GPUs: product name, GPU utilization %, VRAM used/total bytes and %, edge/junction/memory temperatures, average and max power, fan speed % and RPM. Returns one entry per card. Fields that the card does not support are returned as null (not omitted).

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.1/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that unsupported fields return null, which is useful but not extensive. No contradiction.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single concise sentence listing all fields. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, description explains return structure (one entry per card, null for unsupported fields). Complete for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters, schema coverage 100% trivially. Description doesn't add parameter meaning, but none needed. Baseline 4 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states it provides a 'one-shot summary of all AMD GPUs' and lists specific fields, distinguishing it from siblings like gpu_metrics which likely provide more detailed historical data.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or alternatives mentioned. The description implies it is for a quick overview, but does not guide against using other tools for specific needs.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

gpu_watchA
Read-only

Take N snapshots of gpu_status at a fixed interval and return both the raw frames and per-card min/max/avg statistics for utilization, temperature, power, and VRAM usage. Useful for answering “is this training run stable?”. Default: 5 samples at 1000ms intervals.

ParametersJSON Schema
NameRequiredDescriptionDefault
samplesNoNumber of samples to take (2–60). Default: 5.
interval_msNoMilliseconds between samples (100–10000). Default: 1000.

TDQS

A4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, so no contradiction. Description adds that it returns raw and aggregated data, but omits that the tool blocks for the total sampling duration, which is important for agent planning.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences with no fluff: purpose, use case, and defaults are front-loaded efficiently.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given 2 params with full schema coverage, no output schema, and sibling tools, the description adequately explains input, output (raw and stats), and use case. Lacks return structure details but acceptable.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear parameter descriptions including defaults. The tool description does not add meaning beyond what the schema already provides, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it takes N snapshots of gpu_status at intervals and returns raw frames plus per-card statistics, distinguishing it from siblings like gpu_status (single snapshot) and gpu_metrics (single metrics).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides a specific use case ('is this training run stable?') and default parameters, implying when to use it. However, it does not explicitly mention alternatives or when not to use.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

rocm_infoA
Read-only

Report the rocm-smi version, kernel driver version, whether the amdgpu module is loaded, installed ROCm/HIP/HSA packages (from dpkg), and whether amdgpu_top is available. Useful for checking ROCm install health before running workloads.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds detail on exactly what is reported (versions, packages, etc.), providing behavioral context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence efficiently lists all reported information and includes a usage note. Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple info tool with no output schema, the description adequately covers purpose and content. Could optionally mention return format, but not necessary.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Tool has zero parameters, so schema covers all. Description adds no parameter info, but this is acceptable given no params. Baseline 4 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Report' and lists concrete items (rocm-smi version, kernel driver, etc.), clearly distinguishing this from sibling tools that focus on metrics, processes, or status.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

States explicit use case: 'checking ROCm install health before running workloads.' This guides the agent on when to invoke. While it doesn't explicitly mention alternatives, the context is clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 5 tool updatesv0.1.0
    • First observedgpu_metrics
    • First observedgpu_processes
    • First observedgpu_status
    • First observedgpu_watch
    • First observedrocm_info
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

A4.3/5.0

Scored across 5 tools

Disambiguation5/5

Each tool serves a distinct purpose: raw metrics, summary status, process listing, time-series snapshots, and install health check. No overlap in functionality.

Naming Consistency5/5

All tool names follow a consistent snake_case pattern with a clear noun-based prefix (gpu_ or rocm_), making them predictable and easy to distinguish.

Tool Count5/5

Five tools is appropriate for a monitoring-focused server, covering essential needs without being excessive or insufficient.

Completeness4/5

The tool set covers core monitoring, process insight, and installation health, but lacks a way to reset or configure GPU parameters, though that may be out of scope.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • System Monitor MCP Server

    PraveerT
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides system monitoring and management capabilities for Claude CLI, allowing users to view system information, track resource usage, and manage processes through natural language commands.
    -

  • mcp-system-monitor

    VZilvinskus
    F
    license
    A
    quality
    D
    maintenance
    Enables Claude to monitor CPU, memory, disk, processes, network connections, Docker containers, and system logs for system diagnostics and troubleshooting.
    5
    -