Investigate Kubernetes health and processes with the Datadog MCP Server

Datadog, which sells monitoring software for servers and applications, has added Kubernetes and process tools to its MCP server, the connector that lets AI assistants such as Claude Code, Cursor and Codex query a customer's Datadog data. The announcement is mostly about saving an agent work it would otherwise get wrong. Without help, Datadog says, an agent investigating a problem has to search the metric catalog and write its own queries, which takes time and can leave it with incomplete information. The new tools decide in advance which metrics answer a common question, return them in one call, and label what the results do and do not show.

The first set covers the Kubernetes control plane, the components that run a cluster rather than the applications on it: the API server that handles requests, the scheduler that places pods on machines, the controller manager, and etcd, the cluster's database. There is one tool for each, and each returns a fixed bundle of health metrics for a named cluster, by default over the last 10 minutes and for up to 4 hours. If pods have been stuck waiting for a machine for 20 minutes, an agent can call the scheduler tool and see scheduling attempts and how long they take. Every metric comes back with a plain-language description, the exact query used so an engineer can reuse it in a dashboard or monitor, and a status of OK, no data or error. That status lets the agent tell a missing measurement apart from a successful query, and one missing metric does not fail the whole call.

The second addition searches Live Processes, Datadog's record of individual processes on monitored machines: command line, process ID and parent, owner, host, start time, last time seen, and tags. Comparing start times answers questions like whether Postgres restarted on a given database host. Records are kept for 36 hours and one query covers up to an hour. Because a single process in a Kubernetes environment can carry more than a hundred tags, the tool caps responses at 10,000 tokens by default, says when it has truncated a result, and can drop tags entirely for counting questions, so the data does not fill the agent's working memory. Datadog also strips secrets from command lines before the agent sees them. In Datadog's internal test on live production data, 10 questions asked three times each, the agent's answers were correct in 10% of runs without the tool and 96.7% with it.

A third piece, a processes skill, is guidance rather than data: it tells the agent which of three sources fits a question. Hourly discovery snapshots answer where something such as Redis runs across a fleet, Live Processes answers whether a specific process restarted, and per-process CPU and memory metrics answer whether usage is climbing. The skill also warns against tempting misreadings, for example that an empty discovery result can mean Datadog lacks coverage there rather than that the process is absent.

Everything here is read-only. The tools query data Datadog has already collected, follow the calling user's permissions, and do not run commands inside clusters or change them; the skill's setup guidance says any remote configuration change through Datadog's Fleet Automation needs explicit user approval. Customers need Live Processes enabled and control plane metrics already collected, and the available metrics vary by Kubernetes distribution. The only measured result is the small process-search test, run by Datadog itself; the post gives no comparable figure for the control plane tools.