DataDog/pup: A Rust CLI That Exposes Datadog's API Surface to AI Agents
Give your AI agent a Pup — a CLI companion with 200+ commands across 33+ Datadog products.
At a glance
- What is it?
- Pup is an Apache-2.0 Rust command-line client that wraps Datadog product APIs behind self-discoverable commands and structured output. It is built for agent-driven workflows, and its coverage map is as informative as its command list.
- Who is it for?
- Adopt Pup if your agents or scripts need read-heavy access to Datadog monitors, logs, metrics, RUM, security findings or workflows, and you want structured JSON output with OAuth2 PKCE instead of long-lived API keys. Do not adopt it if you need Profiling data, Powerpacks, or a stable command surface you are unwilling to re-verify after upgrades.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap Pup fills between Datadog's REST API and an agent's tool loop
Datadog's platform spans dozens of product APIs, each with its own versioning, pagination and payload shape. An AI agent asked to check whether a monitor is noisy, pull error logs from the last hour, or score tag compliance has to know which endpoint to call and how to shape the request. Pup collapses that into a single binary: the README describes it as a CLI covering a wide range of Datadog product domains, and the repository's own summary counts 200+ commands across 33+ products. The target user is not a human typing ad hoc queries. It is an agent, or a script standing in for one, that needs a discoverable command tree and machine-parseable output. The README is explicit about this positioning, saying AI agents are the fastest-growing interface for infrastructure management. Whether or not you accept that framing, the practical consequence is real: the commands are designed to be listed, introspected and parsed rather than memorized.
Self-discovery and structured output are the two mechanisms that matter
Two design choices carry most of the weight. First, discoverability. The README claims self-discoverable commands, no need to chase documentation, and the repository backs that with two entry points: pup --help for humans and pup agent schema for machine-readable output. An agent that can call pup agent schema can enumerate its own toolset at runtime instead of relying on a prompt that drifts out of date. Second, output shape. The README lists structured JSON/YAML output for easy parsing as a core trait. That matters more than it sounds. A CLI that prints human tables forces an agent to scrape; a CLI that emits JSON lets the agent index directly into fields. The command examples in the README follow this pattern: pup monitors list --tags="team:api-platform", pup logs search --query="status:error" --from="1h", pup metrics query --query="avg:system.cpu.user{*}". Each takes filter arguments that mirror Datadog query syntax rather than inventing a new one. That is a sensible choice: agents already trained on Datadog's query language can reuse it.
OAuth2 with PKCE replaces the long-lived API key
Authentication is where Pup diverges from the typical curl-wrapper CLI. The README states it uses OAuth2 plus PKCE for scoped access, framed as a way to stop long-lived keys running wild. The login flow is a single command: pup auth login. That is the whole documented surface. What the README does not say is how token refresh is handled, where credentials are stored on disk, or what scopes are requested by default. Those are exactly the details a security reviewer will ask about before letting an agent run against production Datadog data. The direction is right. Scoped, short-lived credentials are a better default than an org-wide API key pasted into an environment variable. But the material here stops at the claim, and the claim is not the same as a verified storage model. Treat the auth story as promising and under-documented.
Coverage is broad, and the gaps are documented rather than hidden
The API coverage tables are the most useful part of the repository. Core observability is largely complete: metrics, logs, events, RUM, APM services, traces, database monitoring and session replay all carry checkmarks. Monitoring and alerting covers monitors, dashboards, SLOs, synthetics, downtimes, notebooks, status pages, workflow automation and local runbooks. Security and compliance covers security monitoring rules and signals, cloud security findings, application security, static analysis, audit logs, data governance and tag governance. The gaps are named. Profiling is marked as not supported in pup yet, with the README pointing users to the Datadog MCP server and a specific toolset URL. Powerpacks is marked not yet implemented with no alternative offered. That honesty is worth more than a longer feature list. A coverage table that admits two holes is easier to plan around than one that implies completeness. Note also the versioning notes: metrics and logs both list V1 and V2 API support, and SLOs mention a V2 status query alongside CRUD. Where Pup spans both API generations, the command names do not always make the distinction obvious, so check the per-command reference before assuming which version you are hitting.
Local runbooks are the feature that goes beyond API wrapping
Most of Pup is a thin, well-organized layer over Datadog endpoints. The runbooks commands are not. The README describes them as YAML-defined multi-step runbooks with pup, shell, http and workflow step types, variable interpolation and reusable templates, exposed through runbooks list, runbooks describe, runbooks run, runbooks import and runbooks validate. That is a small orchestration engine living inside the CLI. It also raises the risk profile. A runbook that can execute shell steps and call HTTP endpoints is a different kind of tool from one that only reads monitors. If you are evaluating Pup for an agent, decide deliberately whether the agent gets the runbooks subcommand at all. The validate and describe commands exist, which suggests the project expects runbooks to be reviewed before execution, but the README does not describe a sandbox or a dry-run mode for runbooks run. That absence is the single largest thing to probe before enabling this surface in an automated loop.
Where Pup is the wrong tool, and what to use instead
Pup is a poor fit if you need Profiling data. The README is direct about this: profiling is not supported yet, and the suggested path is the Datadog MCP server with the core and profiling toolsets enabled. The two approaches differ in kind. Pup is a local binary that an agent invokes as a subprocess; the MCP server is a remote endpoint that an agent connects to as a tool provider. That difference matters for deployment: a subprocess CLI works in a locked-down CI runner or an air-gapped shell environment where outbound MCP connections are not available, while the MCP route avoids shipping and updating a binary per host. If your workload is read-only and already lives inside an MCP-capable agent framework, reaching for Pup adds a dependency you may not need. If your workload needs to run in a shell pipeline, or you want the runbooks engine, MCP does not cover it. The honest split is: Pup for local, scriptable, broad-surface access; MCP for the domains Pup has not implemented, and for agents that already speak the protocol.
Maintenance cost and the Apache-2.0 licence
The release cadence visible in the repository is fast. Three releases landed between September 9 and September 10, 2026: v1.18.3, v1.19.0 and v1.19.1. A patch release the same day as a minor release suggests active bug-fixing, which is good for correctness and awkward for pinning. If you install Pup into an agent's toolchain, expect to re-run pup agent schema after upgrades, because the command list is generated from the build rather than frozen in a document. The README points to docs/COMMANDS.md as the canonical reference and to pup --help as the live list, and those two can diverge between releases. Budget for that verification step. On licensing: the repository is Apache-2.0, which permits commercial use, modification and redistribution with the usual notice and patent-grant terms. This is not legal advice. If you plan to bundle Pup into a product or a managed service, have counsel read the LICENSE file in the repository rather than relying on the badge.
Editorial conclusion
Adopt Pup if your agents or scripts need read-heavy access to Datadog monitors, logs, metrics, RUM, security findings or workflows, and you want structured JSON output with OAuth2 PKCE instead of long-lived API keys. Do not adopt it if you need Profiling data, Powerpacks, or a stable command surface you are unwilling to re-verify after upgrades. Before committing, run pup auth login, then pup agent schema to capture the exact command list your build exposes, and check docs/COMMANDS.md for the domains you depend on.
Community notes