pup · Datadog

Datadog Pup CLI for AI Agents

Query Datadog observability data through an agent-aware CLI with JSON output and a read-only mode.

Official toolOperational risk: R0–R3docs-verified

Install for an Agent Report broken data

Agent readiness

84/100

Evidence confidence

docs-verified

Documentation checked

2026-07-10

Independently tested version

Not independently tested

Install for an Agent

Choose an official installation path that matches the runtime. Pin a version for team or CI use, then record the version before the first task.

HomebrewRecommended

macos · linux

$ shell

brew tap datadog-labs/pack && brew install datadog-labs/pack/pup

Authentication and Minimum Permissions

Grant only the permissions the task needs. Pass credentials through environment variables or a platform secret store, never through prompts, repositories, or logs.

Authentication requiredHeadless authentication supported

Prefer OAuth scopes or --read-only; never set DD_AUTO_APPROVE for an unattended write-capable session.

Methods: OAuth2 PKCE, access token, API and application keys
Secret environment variables: DD_ACCESS_TOKEN, DD_API_KEY, DD_APP_KEY, DD_SITE
Credential storage: For headless runs, inject DD_ACCESS_TOKEN, DD_API_KEY, DD_APP_KEY, DD_SITE from the CI or platform secret manager at process start. For local interactive use, prefer the CLI or operating-system credential store when the official client supports one. Never save values in repository files.

Agent and Environment Compatibility

Confirm shell access first, then check the platform, network boundary, and credential path.

claude-codecodexgemini-clicopilot-cli

Environments: local, ci, container, headless, remote
Platforms: macos, linux, windows

Structured Output for Reliable Automation

Prefer a machine-readable format. Treat stdout as the result channel and stderr as diagnostics so the agent can parse failures separately.

json · yaml · table

Use --output json or --agent or --read-only where supported and keep diagnostic logs on stderr.

--output json--agent--read-only

No independently captured output sample

Structured-output support currently comes from official documentation. CLI Finder does not show a guessed example or invented schema before a bounded, non-destructive execution captures stdout.

R0–R3 Command Risk Guide

Risk is assigned per command. R0 is local or remote read-only, R1 is reversible local write, R2 changes remote state, and R3 can be irreversible or production-impacting.

Read-only does not mean public

R0 only means the command does not change local or remote state. A read-only command may still return secrets, identity data, configuration, or production data. Expose only the minimum needed for the task, and never place it in logs, prompts, or commits.

R0Inspect the agent schema

Emits the machine-readable command surface.

$ shell

pup agent schema

Idempotent

R0List monitors read-only

Reads monitor data while blocking write operations.

$ shell

pup --read-only --output json monitors list --tags="team:api-platform"

IdempotentSensitive output

R3Delete a dashboard

Deletes a remote dashboard; --yes suppresses the prompt.

$ shell

pup dashboards delete DASHBOARD_ID --yes

Confirmation requiredMay repeat a change

How the Agent Readiness Score Is Built

Readiness describes how reliably an agent can operate the tool. It does not make every command safe and it does not replace an independent execution test.

Documentation indicates an agent-readiness score of 84/100. No local execution test has been recorded.

Structured output

Use --output json or --agent or --read-only where supported and keep diagnostic logs on stderr.

18/20

Headless operation

Official documentation describes a non-interactive authentication or execution path.

14/15

Safety controls

CLI Finder separates read commands from commands that require confirmation.

11/15

Determinism

Commands use explicit arguments and documented output controls where available.

8/10

Authentication

Prefer OAuth scopes or --read-only; never set DD_AUTO_APPROVE for an unattended write-capable session.

8/10

Documentation

This entry cites official documentation checked on 2026-07-10.

9/10

Installation

Official installation paths cover macOS, Linux, and Windows.

8/8

Maintenance

An official source repository is linked for release and maintenance review.

6/7

Agent artifacts

CLI Finder can generate registry-derived skills and policies; the tool itself was not credited with shipping them.

2/5

Generate a Skill or Agent Policy

Choose an agent and safety mode to generate a copyable artifact with installation, allowed commands, approval boundaries, and the evidence limitation.

Artifact typeTarget agentSafety mode

Generated artifact preview

SKILL.md

---
name: datadog-pup-agent-workflow
description: Use Datadog Pup CLI for Datadog monitors, logs, metrics with explicit command risk and evidence boundaries.
---

# Datadog Pup CLI agent workflow

Use this skill when the task needs Datadog monitors, logs, metrics, dashboards, read-only operations.

## Evidence boundary

- Registry confidence: `docs-verified`
- Documentation checked: `2026-07-10`
- Locally tested version: `not tested`
- Do not describe this CLI as locally verified until its commands have actually been executed in an isolated environment.

## Executed smoke checks

- No local execution record is available.

## Installation

- Homebrew (macos, linux): `brew tap datadog-labs/pack && brew install datadog-labs/pack/pup`

## Authentication

- Methods: OAuth2 PKCE, access token, API and application keys
- Secret environment variables: `DD_ACCESS_TOKEN`, `DD_API_KEY`, `DD_APP_KEY`, `DD_SITE`
- Minimum permissions: Prefer OAuth scopes or --read-only; never set DD_AUTO_APPROVE for an unattended write-capable session.
- Credential storage: For headless runs, inject DD_ACCESS_TOKEN, DD_API_KEY, DD_APP_KEY, DD_SITE from the CI or platform secret manager at process start. For local interactive use, prefer the CLI or operating-system credential store when the official client supports one. Never save values in repository files.
- Never print, persist, or commit credential values.

## Allowed commands (read-only)

- `pup agent schema` — R0: Emits the machine-readable command surface.
- `pup --read-only --output json monitors list --tags="team:api-platform"` — R0: Reads monitor data while blocking write operations.

## Commands requiring explicit approval (read-only)

- None recorded.

## Forbidden commands (read-only)

- R3 `pup dashboards delete DASHBOARD_ID --yes` — Deletes a remote dashboard; --yes suppresses the prompt.

## Execution rules

1. Mode boundary: R0 exact commands may be used; R1, R2, and R3 commands are forbidden.
2. Confirm the selected account, project, context, database, namespace, or environment before any command.
3. Prefer structured output using `--output json`, `--agent`, `--read-only`.
4. Capture the exact command, exit code, stdout, and stderr separately.
5. A generated prefix policy must prompt unless that exact prefix is explicitly marked suffix-safe; do not infer safety from the executable name.
6. Never broaden credentials or disable safety controls to make a command succeed.

## Official sources

- [Datadog Pup CLI documentation](https://docs.datadoghq.com/cli/)
- [Datadog Pup CLI documentation source repository](https://github.com/DataDog/pup)

CLI vs MCP vs API for This Task

CLI

Use the CLI on a developer machine, in CI, or in a container when the task should reuse existing shell state, credentials, and scripts and remain directly observable.

MCP

Consider MCP when the agent benefits from controlled tool definitions, delegated identity, or centrally governed server-side access.

API

Use the direct API for persistent application integrations, high-volume requests, or event-driven work where starting a process adds unnecessary overhead.

Read the full CLI vs MCP guide

Verification History and Official Evidence

CLI Finder records documentation review separately from real execution. Installation, help, exit codes, and output cannot be called Verified until they were run.

Current evidence boundary

Official documentation was reviewed, but installation, help output, exit codes, headless behavior, and structured output were not executed locally.