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 온도가 얼마나 되나요?", "VRAM이 얼마나 남았나요?", "어떤 프로세스가 카드를 사용 중인가요?" 와 같은 질문에 답할 수 있게 해줍니다. 이 모든 작업은 프로세스 종료, 클럭 변경 또는 실행 중인 워크로드에 영향을 주는 기능 없이 수행됩니다.

이 도구는 rocm-smi(및 선택적으로 amdgpu_top)를 호출하여 5가지의 엄격한 읽기 전용 도구를 제공합니다. 프로세스 종료, 클럭/전력 오버라이드, 팬 제어 기능은 없습니다. 그러한 기능이 필요하다면 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에서 **설정 → 확장 프로그램(Extensions)**을 엽니다.

  3. 하단의 **확장 프로그램 개발자(Extension Developer)**로 스크롤하여 **확장 프로그램 설치(Install Extension)**를 클릭하고 .mcpb 파일을 선택합니다.

  4. 확장 프로그램을 활성화합니다. Claude의 도구 선택기에서 rocm-gpu-monitor: 접두사가 붙은 도구들이 나타납니다.

도구

도구

기능

gpu_status

요약 정보: 이름, 사용률 %, VRAM 사용량/전체, 온도(엣지/정션/메모리), 전력 평균/최대, 팬 %/RPM.

gpu_metrics

전체 rocm-smi -a --json 덤프 — 클럭, 전압, PCIe 링크, 펌웨어 버전, 엔진별 활동.

gpu_processes

VRAM 사용량 및 카드 인덱스를 포함한 GPU 사용 컴퓨팅 프로세스(KFD PID).

gpu_processes

고정된 간격으로 N개의 샘플을 가져와 원시 프레임과 카드별 최소/최대/평균 통계를 반환합니다.

rocm_info

설치된 ROCm/HIP 패키지, 드라이버 버전, amdgpu 모듈 로드 상태, amdgpu_top 가용성.

모든 도구는 MCP readOnlyHint: true / destructiveHint: false / openWorldHint: false 주석을 포함합니다.

예시 프롬프트

"학습 실행이 안정적인가요? 20초 동안 GPU를 모니터링해줘."

"현재 PyTorch 프로세스가 VRAM을 얼마나 사용하고 있나요?"

"GPU가 열 스로틀링 중인가요? 정션 온도가 어떻게 되나요?"

"어떤 ROCm 버전이 설치되어 있고 드라이버가 로드되었나요?"

개인정보 보호정책

이 확장 프로그램은 전적으로 로컬 머신에서 실행되며, 항상 읽기 전용으로 다음 프로그램만 호출합니다:

  • rocm-smi — 장치 메트릭을 위해 AMD 커널 드라이버를 쿼리합니다.

  • amdgpu_top (설치된 경우) — 더 풍부한 메트릭을 제공합니다.

  • dpkg -l — 이름/버전별로 설치된 ROCm 관련 패키지를 나열합니다.

  • lsmod — amdgpu 커널 모듈이 로드되었는지 확인합니다.

  • which — 시작 시 위 바이너리들의 위치를 찾습니다.

데이터는 머신 밖으로 나가지 않습니다. 이 확장 프로그램은 네트워크 I/O를 수행하지 않고, 소켓을 열지 않으며, 표준 프로세스 stdout/stderr(Claude Desktop 로그 디렉토리에 캡처됨) 외에 파일을 쓰지 않습니다. GPU 상태(클럭, 전력, 팬)를 수정하거나, 프로세스를 종료하거나, 실행 중인 워크로드에 영향을 줄 수 없습니다. 모든 도구는 엄격하게 읽기 전용입니다.

Claude가 볼 수 있는 정보에는 GPU 모델 및 펌웨어 버전, 현재 VRAM 사용량, 온도/클럭/전력 수치, GPU를 사용하는 실행 중인 프로세스 PID 및 VRAM 사용량, 설치된 ROCm 관련 패키지 목록이 포함됩니다. 이러한 정보 중 민감한 내용(예: 공유 머신에서 실행 중인 프로세스 PID 목록)이 있다고 판단되면 이 확장 프로그램을 활성화하지 마십시오.

문제 해결

"rocm-smi is not installed" — 설치하세요 (sudo apt install rocm-smi). Debian 계열이 아닌 배포판을 사용하는 경우 AMD의 ROCm 설치 지침을 따르세요.

새 GPU에서 많은 필드가 null로 반환됨 — 일부 메트릭(클럭, 전력, 온도)은 rocm-smi를 통해 노출되는 펌웨어 지원에 따라 다릅니다. 매우 새로운 카드(예: RDNA4/R9700)의 경우, -a --json은 데이터를 반환하더라도 개별 rocm-smi --showclocks/--showpower는 "No JSON data to report"라고 보고할 수 있습니다. 이 확장 프로그램은 커버리지를 극대화하기 위해 -a --json을 기본 소스로 사용합니다. 특정 필드가 카드에서 지원되지 않는 경우 오류 대신 null이 반환됩니다.

권한 오류 — rocm-smi는 일반적으로 루트 권한 없이 실행됩니다. 권한 오류가 발생하면 Claude Desktop을 실행하는 사용자가 render 및 video 그룹에 속해 있는지 확인하세요:

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

개발

이 서버는 npm 의존성이 없는 약 300줄의 Node.js 스크립트입니다. .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
    -