Datadog MCP
server monitoringInvestigate Datadog telemetry, incidents, dashboards, and service health.
Available tools
370Aap get activation options
Check whether Datadog App and API Protection (AAP) can be enabled for a service via Remote Configuration (RC), with no code changes. Use when the user asks to install, set up, enable, or onboard AAP for a service and environment. Returns a verdict with a recommended navigation action: the Service Inventory side-panel when RC is available, or the AAP setup page otherwise.
Aap onboarding
Step-by-step instructions for enabling Datadog App and API Protection (AAP) to monitor and secure your application. AAP detects security threats, vulnerabilities, and attacks in real time by using Datadog tracing libraries for application deployments, the Datadog security processor for Envoy deployments, the Datadog SPOA for HAProxy deployments, or the Datadog nginx module for nginx deployments. You MUST first review the user's project and fill out as many arguments as possible before calling this tool. You MUST NOT call this tool without first examining the project's codebase to determine the correct argument values.
Add llmobs annotation queue interactions
Queue traces, sessions, or spans for human review in an annotation queue. This is how findings become review work: use **search_llmobs_spans** or **find_llmobs_error_spans** to identify the traces worth grading, then queue them here. Returns `interactions` — each with the `id` that **upsert_llmobs_annotations** writes labels against — and an `errors` array for the items that did not land. Re-adding content the queue already holds is not an error: the existing interaction comes back with `already_existed: true`. Queueing content does not annotate it. Grade it with **upsert_llmobs_annotations**.
Add llmobs dataset records
Create records in a dataset. **Two-step**: PREVIEW (`confirmed=false`) → INSERT (`confirmed=true`). - `confirmed=false`: does NOT insert. Validates that the (project_id, dataset_id) pair exists, then returns `AddDatasetRecordsPreview` with the resolved IDs, planned record count, tag union, first-record content, and a `confirmation_prompt` string. If the dataset does not exist, returns `DatasetRecordToolError(reason="unknown_dataset")` — re-resolve by NAME via get_llmobs_project + list_llmobs_datasets and retry rather than telling the user the dataset was deleted. Show the preview to the user, ask for explicit approval, then re-call with `confirmed=true`. - `confirmed=true`: validates UUIDs, issues the API call. Author is recorded automatically as the human user from the forwarded JWT — do not pass an author ID. `create_new_version=true` (default) bumps the dataset version on insert (the typical "save as a new versioned snapshot" — what experimentation needs). Set false only for in-place batched edits where the user explicitly asked to keep the current version. On failure returns `DatasetRecordToolError` with `reason`, `recovery_hint`, and the offending value. Reasons: `invalid_project_id`, `invalid_dataset_id`, `unknown_dataset`, `forbidden_action_dataset`, `record_size_exceeded`, `invalid_request`, `transport_error`. Once `confirmed=true` succeeds, do NOT retry the call (the work is committed). If a network error makes the result ambiguous, call **get_llmobs_dataset_records** to verify before retrying. When the user wants to append records, sample existing records via **get_llmobs_dataset_records** first, read the `schema_summary`, and construct matching new records before this tool. Always preview (`confirmed=false`) and confirm with the user before writing.
Aggregate datadog ci pipeline events
Aggregate and analyze CI pipeline events to produce statistics, metrics, and grouped analytics. Use it for questions such as average pipeline duration or failed builds per pipeline. For individual event details or error messages, use search_datadog_ci_pipeline_events instead. aggregation is required and must be one of count, cardinality, avg, sum, min, max, pc50, pc75, pc90, pc95, or pc99. Use cardinality with metric set to a facet (such as @ci.pipeline.id) to count distinct values. If no data is available, try a wider time range. Results are ordered by aggregation value descending; use search_datadog_ci_pipeline_events for sorted individual event listings. If unsure whether a facet exists or needs an @ prefix, read the datadog://mcp/ci-pipeline-facets resource.
Aggregate datadog test events
Aggregate Datadog test events for reliability, performance, and execution trends. Use search_datadog_test_events for individual event details. aggregation is required and must be one of count, cardinality, avg, sum, min, max, pc50, pc75, pc90, pc95, or pc99. Use cardinality with metric set to a facet (such as @test.name) to count distinct values. Use at most two or three group_by facets and add filters to stay within the 10,000-group limit. If unsure whether a facet exists or needs an @ prefix, read the datadog://mcp/ci-test-facets resource.
Aggregate dora events
Aggregate DORA events into scalar values or timeseries using composable queries and formulas. Each query selects a DORA index, optional metric, aggregation, filter, and group_by facets. Use get_dora_fields to discover valid indexes, measures, facets, cardinality fields, and aggregations.
Aggregate events
Aggregate Datadog events to compute counts, sums, averages, min, max, cardinality, and percentiles (P50, P75, P90, P95, P98, P99), with optional grouping by fields or time intervals. Use this for aggregated analysis such as event counts by source, event frequency over time, or grouped summaries across tags. For raw event inspection, titles/messages, or tag exploration, use search_datadog_events.
Aggregate rum events
Aggregate Datadog RUM events to compute counts, sums, averages, min, max, cardinality, and percentiles (P50, P75, P90, P95, P98, P99), with optional grouping by fields or time intervals. Use this for aggregated analysis of RUM data such as session counts over time, error counts by page, or p95 loading times by browser or URL path. For raw event inspection or attribute discovery, use search_datadog_rum_events.
Aggregate spans
Aggregate Datadog APM spans to compute counts, sums, averages, min, max, cardinality, and percentiles (P50, P75, P90, P95, P98, P99), with optional grouping by fields or time intervals. Use this for aggregated analysis such as request counts over time, p95 duration by service or resource, or error counts grouped by endpoint or status code. For raw span inspection or to discover fields to group by or aggregate on, first use search_datadog_spans and optionally request custom_attributes.
Analyse datadog k8s rollout
Assemble a Kubernetes Deployment rollout in one call: status, progress, timing (ETA while in progress, duration once finished), the new/previous/old ReplicaSet split by revision, and before/after impact series (RED, resource utilization, log counts). Prefer this over stitching together search_datadog_k8s_resources and describe_datadog_k8s_resource for rollout questions. Values are already computed; do not re-derive them. Only reports on Deployments whose kube_rollout_status is inprogress, recentlycompleted or recentlyfailed. Any other Deployment returns its own fields plus a warning, because a rollout that finished long ago has nothing to analyse. Load the datadog/analyze-kubernetes-rollout skill to turn this output into an answer. It carries the summary format to present, how to read the impact series, pacing and maxSurge/maxUnavailable advice, and how to name the blocker when a rollout is stuck — none of which is derivable from this payload. Do not hand back the raw JSON. IMPORTANT: Either uid OR resource_identifiers MUST be provided. If both are provided, uid takes precedence and resource_identifiers is ignored. - Use resource_identifiers when you know the Deployment details (cluster, namespace, name) - DO NOT search first - Use uid ONLY if you obtained it from a previous search
Analyze cloud network monitoring
Queries Cloud Network Monitoring (CNM) data to view network/transport level information. Use to investigate netork latency, packet loss, TCP failed connections, dial timeouts, or spikes in TCP throughput. Each query accepts a 'scope' field to select which slice of CNM data to query: - 'tcp' (default): service-to-service L4/TCP flows. Use for investigating connection errors between workloads. - 'tcp-eudm': endpoint/device-centric L4 flows. Use for investigating networking issues originating from end-user devices rather than between services. Scenario 1: clearsky is encountering "failed to connect" errors. Find the unhealthy pods: ```json { "from": "now-1h", "queries": [ {"client_tags": ["service:clearsky"], "client_group_by": "pod_name", "order_by": "retransmits"}, {"client_tags": ["service:clearsky"], "client_group_by": "pod_name", "order_by": "tcp_failed_conns"} ] } ``` Scenario 2: Cloud storage is rate-limiting clients with HTTP 429. View which services are pulling too much data: ```json { "from": "now-1h", "group_limit": 100, "time_buckets": 1, "queries": [ {"server_tags": ["service:aws.s3"], "client_group_by": "service", "order_by": "bytes_server_to_client"}, {"server_tags": ["service:gcp.storage"], "client_group_by": "service", "order_by": "bytes_server_to_client"} ] } ``` Scenario 3: An end-user device reports slow/failing connections. Investigate the destinations it is reaching using EUDM data: ```json { "from": "now-1h", "queries": [ {"scope": "tcp-eudm", "client_tags": "host:i-abc123", "server_group_by": "service", "order_by": "tcp_failed_conns"}, {"scope": "tcp-eudm", "client_tags": "host:i-abc123", "server_group_by": "service", "order_by": "retransmits"} ] } ``` Each result's 'query' includes 'analytics_url', a deep link to the Network Analytics view for that query's filter, group-by, order-by, and time window. Always present this link to the user alongside the answer.
Analyze datadog error tracking errors
Analyze Datadog Error Tracking error samples with SQL — aggregations, breakdowns by tag/service/version, or raw sample inspection. Runs against a virtual 'errors' table of individual error events (not Issues, which are groups of errors). Column names: no @ = root/tag attribute (e.g. usr.id, service), @ = custom attribute (e.g. @my.field). For ranked Issues by priority/volume use search_datadog_error_tracking_issues — do not GROUP BY issue.id as a substitute. Over wide time ranges, add LIMIT or a narrow GROUP BY; shorten the range if it times out.
Analyze datadog logs
Analyze Datadog logs using SQL. Runs against a virtual 'logs' table filtered by your search query. Good for aggregations, counts, group-bys, or peeking at recent logs with LIMIT. To discover custom attributes for extra_columns, first call search_datadog_logs with extra_fields. If a query times out, try a shorter time range. MUST load the datadog/ddsql skill before calling this tool.
Analyze datadog security findings
Primary tool for analyzing security findings. Use this for all security findings analysis tasks. REQUIRED: Call get_datadog_security_findings_schema FIRST to get available fields and their types before writing SQL. Queries live data from the last 24 hours using flexible SQL aggregations, filtering, and grouping. IMPORTANT: When users ask 'what should I fix?' or 'what are my top vulnerabilities?', prioritize by RISK ATTRIBUTES (@risk.*) not just severity. DEEP LINKS: Always link to findings when you have the id — format: <deep_link_base_url>/security/finding/<finding_id>. The correct base URL is in every response as 'deep_link_base_url'. Read the sql_query parameter description carefully — it explains risk-based prioritization, deep link generation, function syntax, common pitfalls, and includes examples. Only fall back to search_datadog_security_findings if you need full finding details or this tool fails. To create a case, Jira issue, or ServiceNow ticket for findings, use create_datadog_security_findings_ticket.
Analyze datadog security signals
Count, group, or trend security signals using DDSQL — for any aggregate question: 'how many', 'top N', 'by severity', 'over time', or breakdown. Do NOT use for listing, retrieving, or checking existence of specific signals — use search_datadog_security_signals instead. IMPORTANT: When constructing the SQL query, ALWAYS use the table-valued function syntax — FROM dd.security_signals(columns => ARRAY[...], filter => '...'). IMPORTANT: If the user has NOT specified a signal product (Cloud SIEM / Log Detection, App & API Protection / Application Security, or Workload Protection / Workload Security), ASK them if they want to specify the product or rule type before calling this tool. Workflow: ALWAYS call get_datadog_security_signals_schema first to discover available fields, then use this tool with SQL.
Analyze security findings
Primary tool for analyzing security findings. (Also available as analyze_datadog_security_findings.) Use this for all security findings analysis tasks. REQUIRED: Call security_findings_schema FIRST to get available fields and their types before writing SQL.
Append new rum retention filter
Create a new RUM retention filter, appended at the end of the evaluation order. Retention filters control which RUM events are indexed and retained. **This changes data-retention configuration and directly affects billing.** Adding a filter or enabling cross-product sampling increases indexed volume and cost. **Always confirm the exact change with the user before calling. Never create a filter speculatively.** name, event_type, and sample_rate are required. event_type: one of session, view, action, error, resource, long_task, vital, operation. sample_rate: 0.1 to 100 (percent of matching events retained). cross_product_sampling: optional extra retention for session replays and APM traces of matching sessions; session_replay_sample_rate and trace_sample_rate are both required within it. The new filter is appended at the end of the evaluation order. Filters are evaluated top-down, so a broad catch-all already at the end may capture matching events before this filter applies; reorder afterwards with reorder_rum_retention_filters to place specific filters above broad ones. Creates are idempotent: a retried create that matches an existing filter exactly is not duplicated. To change an existing filter use update_rum_retention_filter; to remove one use delete_rum_retention_filter. Find existing filters with search_rum_retention_filters.
Append reference table rows
Append (add) new rows to an existing reference table. Prefer upsert_reference_table_rows when you may need to update existing rows — it handles both inserts and updates. Use this tool only when you are certain all rows are new. Each row must include all required fields from the table's schema, including the primary key field. Use list_reference_tables to discover table IDs and schemas first. Example: rows: [{"user_id": "user001", "name": "Alice", "age": 25}, {"user_id": "user002", "name": "Bob", "age": 30}]
Archive-feature-flag
Archive a single feature flag by ID or key; pair with list-stale-feature-flags to discover candidates. Provide featureFlagID or featureFlagKey (if both are given, featureFlagID wins).