Datadog Pup: a CLI companion for AI agents that talk to Datadog

What Pup is for, and who should care

Pup is a command line client for Datadog's APIs, written in Rust and published by Datadog under Apache-2.0. The README frames it as an AI-agent-ready CLI: the pitch is that agents are becoming the interface for infrastructure management, and an agent needs a discoverable, parseable command surface rather than a pile of REST endpoints. The repository supports that framing with .agents/, .claude-plugin/, .codex-plugin/ and .cursor-plugin/ directories, plus AGENTS.md and SKILL.md at the top level. Those are not decorations; they are the packaging that lets an agent framework pick up Pup as a tool.

The audience splits in two. The first is an engineer wiring a coding or operations agent into a Datadog org and wanting the agent to call something with a stable shape instead of hand-rolled HTTP. The second is a human who wants a single binary for monitors, logs, metrics, RUM, security findings and the rest, without switching between the Datadog UI and curl. The README says humans are welcome, and the example commands are ordinary CLI calls. If you only ever look at one dashboard, Pup is more surface area than you need.

Self-discoverable commands and structured output

Two design choices carry most of the weight. The first is discoverability: the README describes the commands as self-discoverable, so an agent can walk the command tree instead of being handed a fixed prompt. The second is output format. Pup returns structured JSON or YAML, which is the difference between an agent parsing a stable field and an agent scraping a table meant for a terminal. The README also points at docs/COMMANDS.md as the canonical reference and at pup agent schema for machine-readable output. That schema command is the interesting one, because it means the command list can be read as data rather than by running --help and parsing prose.

Authentication is the third piece. Pup uses OAuth2 with PKCE for scoped access, which the README contrasts with long-lived keys. For an agent that runs unattended, the practical difference is that the credential is a scoped session rather than an org-wide key sitting in an environment variable. The README does not describe token refresh behaviour, token lifetime, or what happens when the session expires mid-run, so treat those as things to observe rather than assume. The Cargo.toml shows the native feature set pulls in keyring and dirs, which suggests credentials are stored locally through the OS keyring rather than a plaintext config file, but the README does not document that storage path.

Installing Pup and running your first query

The README does not give a package-manager install line. It shows the binary being invoked directly, and the repository carries .goreleaser.yaml along with .goreleaser-linux.yaml and .goreleaser-macos.yaml, which indicates release artifacts are produced for Linux and macOS. Check the releases page for the current v1.19.1 artifacts rather than assuming a Homebrew or cargo install path that the documentation never states.

Once you have the binary on your PATH, the first step is authentication. The README gives this as the house-training command:

pup auth login

That opens an OAuth2 + PKCE flow. After it completes, you are authenticated for subsequent calls. The next step is confirming what your build actually exposes, since the command list is generated at build time:

pup --help
pup agent schema

The first prints the human-readable tree; the second emits the machine-readable command list, which is what you would feed to an agent. A first real query against monitors, filtered by tag, looks like this:

pup monitors list --tags="team:api-platform"

You should get back a structured list of monitors carrying that tag. From there the README's other examples are log search and metrics query:

pup logs search --query="status:error" --from="1h"
pup metrics query --query="avg:system.cpu.user{*}"

If you are building for the browser or a WASI target, Cargo.toml defines browser and wasi feature sets alongside the default native one. Those are library builds (the lib target is named pup_wasm), not the CLI, so do not expect the same command surface there.

Where the coverage stops: profiling, Powerpacks and the MCP handoff

The command matrix in the README is unusually honest about gaps, which is worth reading before you commit. Profiling is marked as not supported in Pup yet, and the README directs you to the Datadog MCP server with a specific toolset query string for it. Powerpacks are marked not implemented with no command listed. Those are real boundaries: if your workflow is continuous profiling analysis, Pup is the wrong tool today, and the README says so rather than leaving you to discover it.

There is a second boundary that matters more for agents. Several domains are marked supported but with a narrower verb set than you might expect. Dashboards get list, get, delete and url, but the README does not list a create or update. Notebooks get list, get and delete. Downtimes get list, get and cancel. Monitors are described as full CRUD. So the coverage is uneven per domain, and an agent that assumes symmetry across products will fail on the first write call it tries against dashboards. Read docs/COMMANDS.md per domain instead of extrapolating from the monitors example.

The third limitation is structural. Pup is a client, so its ceiling is the Datadog API surface and the scopes your OAuth session was granted. A command that exists can still return a permission error. The README does not document error output shapes, exit codes, or rate-limit behaviour, so an agent relying on Pup needs its own handling for those cases.

Pup compared with the Datadog MCP server

The README itself points at the Datadog MCP server, so the honest comparison starts there. MCP is a protocol: an agent connects to a server that advertises tools, and the tool schemas arrive over that connection. Pup is a binary: the agent shells out, and the command surface is whatever the installed build exposes. The practical difference shows up in deployment. An MCP server is a network endpoint the agent points at, configured with a toolset parameter, as the profiling note demonstrates. Pup is something you install and authenticate on the machine that runs the agent.

That makes Pup a better fit when the agent already has shell access and you would rather not add a network dependency, or when a human wants to run the same commands by hand. MCP is a better fit when the agent framework speaks MCP natively and you want tool discovery handled by the protocol rather than by parsing pup agent schema yourself. They are not mutually exclusive: the README's profiling entry shows Datadog expects you to use MCP for the surfaces Pup does not cover. For log search and monitor listing, Pup's own commands are the direct path.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-10, the same day v1.19.1 was released. The release history shows v1.19.0 and v1.18.3 on 2026-09-09, so the project is shipping frequently and version numbers move in small increments. For a CLI that wraps a large API surface, that cadence cuts both ways: fixes arrive quickly, and pinned versions can lag the API.

Upgrade cost is mostly about the pinned toolchain. Cargo.toml sets rust-version to 1.93.1 and the repository includes rust-toolchain.toml, so building from source requires a recent Rust. The package is marked publish = false, meaning it is not distributed through crates.io as a library you depend on; you install the binary or build it yourself. The native feature set is large (keyring, russh, tokio-tungstenite, yamux, zip, tar), which is a lot of dependency surface for a build.

Licensing is Apache-2.0, with a NOTICE file and a LICENSE-3rdparty.csv in the repository, so third-party licence obligations are tracked explicitly. Apache-2.0 includes a patent grant and requires attribution and notice retention. That is a summary of the identifier, not legal advice; if you redistribute Pup inside a product, have counsel read the NOTICE and the third-party CSV.

Editorial conclusion

Adopt Pup if your agents or scripts need to read Datadog state across many product surfaces from one binary, and you want OAuth2 + PKCE scoped access instead of long-lived API keys. Skip it if your work is profiling, Powerpacks, or anything outside the command list in docs/COMMANDS.md, because those calls are not implemented. Before rolling it out to an agent, verify three things: that pup auth login works against your org, that the JSON output shape of the specific subcommand you plan to call is stable enough to parse, and that your Rust toolchain matches the rust-version pinned in Cargo.toml. The fastest check is to run pup agent schema and diff the command list against what your agent actually needs.

Frequently asked questions

Official sources

1. DataDog/pup on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases