NVIDIA DCGM MCP server: there isn't one
GPU telemetry that most teams already scrape into Prometheus, which is why the missing server matters less than it first appears.
Last verified 1 September 2026 · from The NVIDIA GitHub organization, GitHub search and the official MCP registry
This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.
Summary
NVIDIA publishes no MCP server for DCGM, its Data Center GPU Manager. A search of the NVIDIA organization for MCP-named repositories returns two, and neither touches DCGM.
A global search for repositories naming both DCGM and MCP returns exactly one: 01p5/gpu-watch, a personal project with 0 stars that monitors GPU health over SSH and through dcgm-exporter.
The gap is smaller than it looks. DCGM's normal deployment already publishes metrics through dcgm-exporter into Prometheus, and Prometheus has a first-party MCP server.
What is the NVIDIA DCGM MCP server, and is it usable?
DCGM is NVIDIA's Data Center GPU Manager. It collects GPU health, utilization, temperature, memory and error data from the hardware.
In a Kubernetes or cluster deployment it is almost always paired with dcgm-exporter, which turns that data into Prometheus metrics. That is the standard pattern NVIDIA documents.
This matters for the missing server. Unlike a product whose data is locked in a vendor database, DCGM's output is normally already sitting in a metrics store that an agent can query.
Every one of the 90 vendors in this directory gets the same four checks. NVIDIA DCGM passes 0 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Fail | No DCGM MCP server. A search of the NVIDIA GitHub organization for MCP-named repositories returns two on 1 September 2026, and neither exposes DCGM. |
| Maintained | Fail | There is nothing to maintain. NVIDIA has published no DCGM server. |
| Distributed | Fail | No package, and no DCGM entry in the official MCP registry. |
| Usable | Fail | A global search for repositories naming both DCGM and MCP returns a single result, 01p5/gpu-watch, a personal project with 0 stars. |
DCGM monitors data-center GPU health, but NVIDIA publishes no MCP server for that telemetry. The only search result is a personal project with 0 stars. It is not a DCGM integration.
| Part of the work | What NVIDIA DCGM has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | None | No code product, and no server |
| CI & release | None | No pipeline product, and no server |
| Production observability | GPU utilization, health, temperature, memory, errors | Not directly. The data reaches an agent through Prometheus scraping dcgm-exporter, not through a DCGM server |
| Agent observability & evals | GPU utilization behind model serving | No. GPU metrics describe the hardware under an inference workload, and nothing exposes them as MCP tools |
| AI cost management | GPU utilization as a cost signal | No. Utilization informs GPU cost, and DCGM exposes no spend data and no server |
GPU telemetry is reachable, just not from NVIDIA. An agent asking whether a training job is GPU-bound gets its answer from Prometheus. The missing DCGM server costs almost nothing in practice.
What can an AI agent do with NVIDIA DCGM?
One thing to watch, because a single search result can look like a maintained option.
The only DCGM MCP search result is a personal project with no adoption.
A global GitHub search for repositories naming both DCGM and MCP returns one result: 01p5/gpu-watch, which has 0 stars and was pushed on 1 June 2026. It describes itself as GPU health monitoring over direct SSH and dcgm-exporter, with a dashboard and MCP.
It is not NVIDIA's, and the NVIDIA organization has no MCP-named repository of its own.
Guard: Treat it as one person's tool rather than a DCGM connector, and prefer the metrics path that is already running in most clusters.
Do you need the MCP server at all?
No, and DCGM is the clearest case for that answer. Prometheus is the working route, and for most clusters it needs no new work. dcgm-exporter is the standard way DCGM data is published, so the metrics are usually already being scraped.
Prometheus's own MCP server is first-party, in the prometheus GitHub organization, and registers 28 tools for about 2,349 tokens, the leanest cost measured in this guide. This page names none of those 28 tools. An agent can write PromQL, the Prometheus query language, against DCGM_FI_DEV_GPU_UTIL and the other exporter series.
For dashboards and alerting over the same data, Grafana reaches Prometheus as one datasource among several and adds alert and dashboard tools that Prometheus does not have.
If the GPUs are in Kubernetes, a Kubernetes connector adds the scheduling context: which pod holds which device, and whether a node has been marked unschedulable. That pairs naturally with the utilization numbers.
Query dcgm-exporter's metrics through Prometheus. There is nothing a DCGM server would add that the exporter does not already publish.
NVIDIA DCGM MCP server setup
Nothing here installs a DCGM server, because NVIDIA publishes none. This is the working route, and it needs no new component: DCGM already publishes its metrics through dcgm-exporter.
NVIDIA/dcgm-exporter carries 1,856 stars and was pushed on 2 September 2026. If you run DCGM on Kubernetes you almost certainly run it already.
Prometheus scrapes the exporter, and Prometheus has a first-party MCP server. The agent asks Prometheus, and the GPU telemetry is already there.
Point Claude Code at Prometheus
This is the whole integration. The server takes the URL of the Prometheus that scrapes dcgm-exporter, and the DCGM metric names are queryable like any others.
No credentials appear in the block. Where your Prometheus sits behind authentication, the URL points at whatever proxy fronts it.
claude mcp add-json "prometheus" '{"command":
"prometheus-mcp-server",
"args":["--mcp.tools=core",
"--prometheus.url=http://prometheus:9090"]}'Confirm the exporter is being scraped
Before connecting anything, check that DCGM series are actually present. If the exporter is not scraped, the agent will find nothing and the connector is not the cause.
This query runs against Prometheus directly and carries no credentials of its own.
curl -s "http://prometheus:9090/api/v1/label/__name__/values" \ | grep -o '"DCGM_[^"]*"' | head
Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Why there is nothing else to install
A DCGM MCP server would sit between the agent and the same exporter data. The exporter already publishes it in a format Prometheus stores and the Prometheus server already exposes.
The one third-party project found, 01p5/gpu-watch, monitors GPU health over SSH and through dcgm-exporter. It has 0 stars and is unaffiliated with NVIDIA. It adds a step in the path, not a new capability.
The path below is data flow, not configuration, so it carries no credentials at any step.
DCGM -> dcgm-exporter -> Prometheus -> agent
Read-only access, permissions and security
No new credential is introduced
The route reuses the Prometheus your cluster already runs, so there is no GPU-specific token to issue or rotate.
Prometheus exposes everything it holds
It has no per-metric access control, so an agent connected for GPU questions can also read every other series in that instance.
Scope by instance, not by metric
If GPU telemetry should be the only thing visible, point the server at a Prometheus that scrapes only dcgm-exporter.
--mcp.tools=coreleaves the administrative group outNine tools cover querying, metadata and documentation, which is the whole requirement here.
GPU telemetry is operational, not personal
Utilization, temperature and memory carry no user data, which makes this one of the lower-risk reads in this directory.
The unaffiliated project needs judging separately
01p5/gpu-watchreaches hosts over SSH, and SSH access is a materially wider grant than a Prometheus read.
Troubleshooting
- You cannot find an NVIDIA DCGM MCP server
- There is not one. A search of the
NVIDIAorganization on 1 September 2026 returned two MCP-named repositories, and neither exposes DCGM. - A search turns up `01p5/gpu-watch`
- That is the only repository naming both DCGM and MCP. It is a personal project with 0 stars, last pushed on 1 June 2026, monitoring GPU health over SSH and through dcgm-exporter.
- It is unaffiliated with NVIDIA.
- You want GPU health readable by an agent
- The gap is smaller than it looks. DCGM's normal deployment already publishes metrics through dcgm-exporter into Prometheus, and Prometheus has a first-party MCP server.
- Connect Prometheus and query the DCGM metric names directly.
- You expected NVIDIA to have covered this
- NVIDIA publishes no MCP-named repositories at all in that organization, so DCGM is not a single omission from a wider set.
NVIDIA DCGM MCP server: Reference
| Item | Value |
|---|---|
| Server published | None |
MCP-named repositories in NVIDIA | 0 |
| Repositories naming DCGM and MCP | 1 |
| That repository | 01p5/gpu-watch, unaffiliated |
| Its stars | 0 |
| Its last push | 1 June 2026 |
| What it does | Monitors GPU health over SSH and through dcgm-exporter |
| Official MCP registry results for DCGM | None |
| Working route | dcgm-exporter into Prometheus, which has a first-party server |
| Checked | 1 September 2026 |
What engineers report
The searches are the evidence, and one of them returns a result worth naming precisely.
| What was checked | What it shows |
|---|---|
MCP-named repositories in NVIDIA | 0 |
| Repositories naming DCGM and MCP | 1 |
| That repository | 01p5/gpu-watch, 0 stars, pushed 1 June 2026 |
| Official MCP registry results for DCGM | None |
The NVIDIA GitHub organization was searched for MCP-named repositories on 1 September 2026 and returned two, neither for DCGM. SkillSpector scans agent skills for security risks, and elements is a design system. A global search for repositories naming both DCGM and MCP returned one, 01p5/gpu-watch. The official MCP registry has no DCGM entry.
Should you connect an agent to NVIDIA DCGM?
No. There is nothing to connect. Best for prometheus over dcgm-exporter, with a Kubernetes connector for scheduling context.
- Strongest fit
- Teams running GPUs who already scrape dcgm-exporter into Prometheus.
- Main advantage
- dcgm-exporter already publishes into Prometheus, which has a first-party server, so nothing new needs installing.
- Main weakness
- There is no GPU-specific tooling, so the agent works with raw metric series.
- Operational risk
01p5/gpu-watchreaches hosts over SSH, which is a far wider grant than the Prometheus read it replaces.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface, from $10 per million spans.
See agent observabilityFrequently asked questions
Does NVIDIA publish a DCGM MCP server?
No. The NVIDIA GitHub organization has two MCP-named repositories and neither touches DCGM. The official registry has no DCGM entry, as of 1 September 2026.
What is the one search result?
01p5/gpu-watch, a personal project with 0 stars that monitors GPU health over SSH and dcgm-exporter. It is not NVIDIA's.
How can an agent read GPU metrics?
Through Prometheus. dcgm-exporter publishes DCGM data as Prometheus metrics, and Prometheus has a first-party MCP server with 28 tools.
Is anything lost without a DCGM server?
Little in practice. The exporter already publishes the same telemetry, so the data is reachable through a connector that exists and is maintained.
