A
licenseNot graded
qualityD
maintenanceProvides Claude with real-time system monitoring capabilities, including CPU, memory, disk, network, battery, and internet speed metrics.
MIT
claude-rocm-mcp
by LukeLamb
Provides read-only monitoring of AMD GPUs, including metrics like utilization, VRAM, temperature, power, and running processes.
Claude ROCm GPU Monitor
Read-only AMD GPU monitoring for Claude Desktop on Linux. Lets Claude answer questions like "is my training run healthy?", "how hot is the GPU?", "how much VRAM is left?", and "which process is using the card?" — all without the ability to kill processes, change clocks, or otherwise perturb a running workload.
It shells out to rocm-smi (and optionally amdgpu_top) and exposes five strictly read-only tools. No process killing, no clock/power overrides, no fan control. For those, use a tool like gpu-kill.
Requirements
Linux with an AMD GPU (RDNA2/3/4 consumer cards — RX 6000/7000/9000, R9700 — and CDNA data-center cards).
amdgpukernel module loaded (standard on modern Ubuntu/Debian/Fedora).rocm-smiinstalled:sudo apt install rocm-smi # minimal # or a full ROCm stack: # https://rocm.docs.amd.com/projects/install-on-linux/
Some metrics (clocks, power, detailed temperatures) require newer ROCm releases. If a metric isn't supported by your card/driver, the tool returns it as null rather than failing.
Related MCP server: System Monitor MCP Server
Install (Claude Desktop)
Download the latest
ROCm.mcpbfrom the Releases page.In Claude Desktop, open Settings → Extensions.
Scroll to Extension Developer at the bottom, click Install Extension, and pick the
.mcpbfile.Enable the extension. The tools appear prefixed with
rocm-gpu-monitor:in Claude's tool picker.
Tools
Tool | What it does |
| One-shot summary: name, utilization %, VRAM used/total, temps (edge/junction/memory), power avg/max, fan %/RPM. |
| Full |
| Compute processes using the GPU (KFD PIDs) with VRAM usage and card index. |
| Take N samples at a fixed interval and return raw frames plus per-card min/max/avg stats. |
| Installed ROCm/HIP packages, driver version, |
All tools carry the MCP readOnlyHint: true / destructiveHint: false / openWorldHint: false annotations.
Example prompts
"Is my training run stable? Watch the GPU for 20 seconds."
"How much VRAM is my current PyTorch process using?"
"Is the GPU thermal-throttling? What's the junction temperature?"
"What ROCm version is installed and is the driver loaded?"
Privacy policy
This extension runs entirely on your local machine and shells out only to the following programs, always read-only:
rocm-smi— queries the AMD kernel driver for device metrics.amdgpu_top(if installed) — optional richer metrics.dpkg -l— enumerates installed ROCm-related packages by name/version.lsmod— checks whether theamdgpukernel module is loaded.which— locates the above binaries at startup.
No data leaves your machine. This extension performs no network I/O, opens no sockets, and writes no files outside of standard process stdout/stderr (captured by Claude Desktop's log directory). It cannot modify GPU state (clocks, power, fan), kill processes, or otherwise perturb a running workload — every tool is strictly read-only.
The information visible to Claude includes GPU model and firmware versions, current VRAM usage, temperature/clock/power readings, running GPU-using process PIDs and their VRAM usage, and a list of installed ROCm-related packages. If you consider any of that sensitive (for example the list of running process PIDs on a shared machine), do not enable this extension.
Troubleshooting
"rocm-smi is not installed" — install it (sudo apt install rocm-smi). If you're using a non-Debian distro, follow AMD's ROCm install instructions.
Many fields come back as null on a new GPU — some metrics (clocks, power, temperature) depend on firmware support exposed through rocm-smi. On very new cards (e.g. RDNA4/R9700), individual rocm-smi --showclocks/--showpower may report "No JSON data to report" even though -a --json returns the data. This extension uses -a --json as the primary source to maximize coverage. If a specific field is unsupported on your card, it'll be null rather than an error.
Permission errors — rocm-smi normally runs without root. If you see permission errors, check that the user running Claude Desktop is in the render and video groups:
sudo usermod -aG render,video $USER
# log out and back inDevelopment
The server is a single ~300-line Node.js script with zero npm dependencies. To rebuild the .mcpb:
cd bundle-source
zip -j ../ROCm.mcpb manifest.json package.json server.js README.md LICENSE icon.pngLicense
MIT. See LICENSE.
Related
claude-terminal-mcp — shell, filesystem, and background jobs.
claude-linux-mcp — X11 desktop control (screenshot, mouse, keyboard, windows, clipboard).
Available Tools
5 toolsgpu_metricsARead-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
| Name | Required | Description | Default |
|---|---|---|---|
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_processesARead-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
| Name | Required | Description | Default |
|---|---|---|---|
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_statusARead-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
| Name | Required | Description | Default |
|---|---|---|---|
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_watchARead-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
| Name | Required | Description | Default |
|---|---|---|---|
| samples | No | Number of samples to take (2–60). Default: 5. | |
| interval_ms | No | Milliseconds 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_infoARead-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
| Name | Required | Description | Default |
|---|---|---|---|
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. Dates show when Glama detected each change.
5 tool updates
v0.1.0- First observed
gpu_metrics - First observed
gpu_processes - First observed
gpu_status - First observed
gpu_watch - First observed
rocm_info
TDQS
A4.3/5.0
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
ActivityInactive
ResponsivenessSyncing
Resources
Unclaimed servers have limited discoverability.
Looking for Admin?
If you are the server author, to access and configure the admin panel.
Related MCP Connectors
WHOOP recovery, strain, sleep and workouts in Claude via official WHOOP OAuth. Free, open source.
Garmin data in Claude: 135 tools — activities, sleep, HRV, training, workouts. Free, open source.
Real-time Claude & Anthropic news from your own Claude — free, no API key.
- sentinelOAuthio.rootstuff
Uptime, SSL, DNS and domain monitoring you can talk to from Claude or any MCP client.
Related MCP Servers
- FlicenseNot gradedqualityDmaintenanceProvides system monitoring and management capabilities for Claude CLI, allowing users to view system information, track resource usage, and manage processes through natural language commands.-
- AlicenseAqualityDmaintenanceGive Claude Desktop terminal, filesystem, and background-job access on your local Linux machine. Zero-dependency MCP extension, MIT-licensed.83MIT
- AlicenseNot gradedqualityCmaintenanceRead-only systemd inspection for Claude on Linux — list units, status, journal, failed units, unit files.MIT
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/LukeLamb/claude-rocm-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server