Datadog

Edits an existing notebook. Can edit cells, metadata (name, template_variables, tags), or both. Look up widget reference schemas before constructing graph cells. Cell modes: (1) Full-replace (default) — replaces all cells; destroys existing comment marks. (2) Append (append_only=true) — adds cells to the end; preserves comment marks. To edit only metadata, omit the cells parameter and provide at least one of name/template_variables/tags. Metadata edits are done on a best effort basis and can be combined with either cell mode.

edit_datadog_notebook

Execute JavaScript in a sandbox with access to Datadog through the official TypeScript-SDK-shaped API and explicitly enabled code-exec extensions. Quick start: ```javascript import { client, v1 } from "@datadog/datadog-api-client"; const monitors = new v1.MonitorsApi(client.createConfiguration()); return await monitors.listMonitors({ page: 0, pageSize: 1 }); ``` The `dd` global only exposes `dd.time.*`. Product APIs are not mounted under `dd`; import official APIs from `@datadog/datadog-api-client` and construct the appropriate `v1` or `v2` API class as shown above. Reviewed APIs that are not in the official SDK are exposed separately through the sandbox-only `@datadog/code-exec` package when enabled for the current session. Datadog APIs are available through both the official TypeScript SDK and enabled code-exec extensions. Code-exec's value is that you can compose API calls in one script, join data across products, and return a compact result — not that you need a separate MCP helper for each Datadog query. **SDK discovery requirement:** Do not rely on model memory for Datadog SDK method names, request fields, enum values, or response shapes. Before calling `execute_code`, call the separate `search_datadog_sdk` MCP tool unless the exact operation and complete request shape are already present in a known-good example below or were returned by an earlier SDK search in this conversation. If `execute_code` returns `invalid_request`, an unknown method or member error, or a request-shape error, call `search_datadog_sdk` before retrying. Do not repair these errors by guessing fields. Its metadata-only catalog only returns official SDK methods and code-exec extensions available in the current `execute_code` session. In one JavaScript program, select the operation and return its `usageNotes` plus a bounded closure of its `typeRefs` from `catalog.types`. For official SDK operations, use the declared version, API, method, and TypeScript types. For extensions, use the declared module, export, method, and TypeScript types. Do not guess fields from an HTTP path or summary. For non-trivial investigations where you need a multi-query script, API aggregation, cross-source joins, or compact ranked output, load the `datadog/code-exec` skill before writing the script. Skip it for trivial one-liners or when the exact request shape is already clear. Code-exec guidance lives in `datadog/code-exec` and its bundled references; don't guess product-specific skill names like `datadog/traces` or `datadog/metrics` from the task topic. ## Execution discipline - `dd.time.*` returns RFC3339 strings. Logs and spans accept those strings directly. Metrics scalar and timeseries requests require Unix milliseconds; use `Date.parse(dd.time.hoursAgo(...))` and `Date.parse(dd.time.now())`, and do not hand-calculate Unix timestamps. - After an `invalid_request`, re-check the operation signature, type declarations, and usage notes before retrying. Verify timestamp units, enum values, and exact camelCase property names. - Compose related queries in one script and return a compact result. Use `Promise.all` when every result is required. When independent calls can still provide useful evidence if a sibling fails, use `Promise.allSettled` and return the successful evidence alongside a compact failures array. When a script returns after mixed API-call outcomes, `execute_code` reports `outcome: "partial"` and `partial: true`; the returned `value` remains usable, and `diagnostics.api_calls` describes the failed calls. Treat partial evidence as incomplete and retry only the missing source when it is necessary for the answer. If every API call fails, the execution is still reported as a failure even if the script caught the rejections. ## Investigation rules - Use aggregate APIs for totals, top-Ns, rankings, ratios, and percentiles. Prefer aggregate operations where supported. Do not group returned samples and present them as global rankings. - For top-N aggregations, put the sort on the `groupBy` entry. A `limit` without `sort` does not guarantee the first bucket is the top bucket. - For log facet rankings, use `v2.LogsApi.aggregateLogs`. Group by facets such as `@error.kind`, `@http.status_code`, `@http.route`, or `@duration`. - For span rankings, use `v2.SpansApi.aggregateSpans`. Use `v2.SpansApi`, not `v2.TracesApi`, for span search and aggregation. - For metric totals, grouped metric rows, or APM metrics, use `v2.MetricsApi.queryScalarData`; use `queryTimeseriesData` when the answer needs points over time. Scalar responses are columnar under `result.data.attributes.columns`, not `attributes.series` or `attributes.values`. - When the user names a data source — metrics, logs, or spans/traces — use an operation for that source unless the task explicitly asks to compare sources. - If the user asks for operation name, group spans by `operation_name`. If the user asks for endpoint, resource, route, or path, group spans by `resource_name`. - For APM error spans, use `status:error` unless you've verified another facet. Do not assume `error:true` works. - For HTTP status code filters, use attributes: `@http.status_code:[400 TO 599]` or `@http.status_code:[500 TO 599]`, not `status:4xx` / `status:5xx`. - Span reserved fields don't use `@`: `service`, `status`, `resource_name`, `operation_name`, `trace_id`, `type`. Span duration is `@duration` in nanoseconds; p95 span aggregation uses `pc95` over `@duration`. ## Known-good SDK examples ### Find source repositories for a service When you need source code for a service found in telemetry, query its Service Catalog definition. Repository metadata may be represented as `repos`, repo-typed `links`, or the definition's GitHub source URL depending on the schema version. ```javascript import { client, v2 } from "@datadog/datadog-api-client"; const serviceName = "example-service"; const definitions = new v2.ServiceDefinitionApi(client.createConfiguration()); const result = await definitions.getServiceDefinition({ serviceName }); const attributes = result.data?.attributes; const schema = attributes?.schema; const repositories = [ ...(schema?.repos ?? []), ...(schema?.links ?? []).filter((link) => link.type === "repo"), ...(schema?.externalResources ?? []).filter((link) => link.type === "repo"), ].map((repository) => ({ name: repository.name, url: repository.url, })); return { serviceName: schema?.ddService ?? schema?.info?.ddService ?? serviceName, repositories, definitionSource: attributes?.meta?.githubHtmlUrl ?? null, }; ``` ### Investigate a Synthetics failure against a passing baseline Use the v2 result APIs to compare the initial failure with the most recent passing run from the same location and browser device. When a summary has no event ID, use v1 full-result retrieval: `getAPITestResult` for API tests (including multistep), or `getBrowserTestResult` for browser tests. A missing event ID does not mean the result is unavailable. ```javascript import { client, v1, v2 } from "@datadog/datadog-api-client"; const publicId = "abc-def-ghi"; const fromTs = Date.parse("2026-01-01T10:00:00Z"); const toTs = Date.parse("2026-01-01T10:15:00Z"); const synthetics = new v2.SyntheticsApi(client.createConfiguration()); const legacySynthetics = new v1.SyntheticsApi(client.createConfiguration()); // Prefer the initial failure over its fast retries. const failedRuns = await synthetics.listSyntheticsTestLatestResults({ publicId, fromTs, toTs, status: "failed", }); const failing = (failedRuns.data ?? []) .filter((result) => !result.attributes?.executionInfo?.isFastRetry) .sort( (a, b) => (a.attributes?.startedAt ?? 0) - (b.attributes?.startedAt ?? 0) )[0]; if (!failing?.id) { return { error: "No failing Synthetics run found" }; } const failingAttributes = failing.attributes; // Keep location and browser device constant when selecting the baseline. const passedRuns = await synthetics.listSyntheticsTestLatestResults({ publicId, fromTs: failingAttributes.startedAt - 24 * 60 * 60 * 1000, toTs: failingAttributes.startedAt - 1, status: "passed", probeDc: failingAttributes.location?.id ? [failingAttributes.location.id] : undefined, deviceId: failingAttributes.device?.id ? [failingAttributes.device.id] : undefined, }); const passing = (passedRuns.data ?? []).sort( (a, b) => (b.attributes?.startedAt ?? 0) - (a.attributes?.startedAt ?? 0) )[0]; async function getFullResult(summary) { if (!summary?.id) return null; const eventId = summary.attributes?.additionalProperties?.event_id; if (!eventId) { const request = { publicId, resultId: summary.id }; const response = summary.attributes?.testType === "browser" ? await legacySynthetics.getBrowserTestResult(request) : await legacySynthetics.getAPITestResult(request); const result = response.result; if (!result) return null; return { ...result.additionalProperties, ...result, steps: result.steps ?? result.additionalProperties?.steps ?? result.stepDetails ?? [], }; } const response = await synthetics.getSyntheticsTestResult({ publicId, resultId: summary.id, eventId, timestamp: Math.floor(summary.attributes.startedAt / 1000), }); return response.data?.attributes?.result; } const [failed, passed] = await Promise.all([ getFullResult(failing), getFullResult(passing), ]); const failedSteps = failed?.steps ?? []; const failedIndexes = failedSteps.flatMap((step, index) => step.status === "failed" || step.failure ? [index] : [] ); const compactStep = (step) => step && { type: step.type, failure: step.failure, assertionResult: step.assertionResult, assertionResults: step.assertionResults, assertions: step.assertions, request: step.request && { method: step.request.method, url: step.request.url, }, response: { statusCode: step.response?.statusCode ?? step.httpStatusCode, body: (step.response?.body ?? step.responseBody)?.slice(0, 1000), }, trace: step.trace, }; return { testType: failingAttributes.testType, location: failingAttributes.location, device: failingAttributes.device, failing: { id: failing.id, startedAt: failingAttributes.startedAt, version: failingAttributes.additionalProperties?.test_version, failure: failed?.failure, httpStatusCode: failed?.httpStatusCode, responseBody: failed?.responseBody?.slice(0, 1000), assertions: failed?.assertions, response: failed?.response && { statusCode: failed.response.statusCode, body: failed.response.body?.slice(0, 1000), }, trace: failed?.trace, }, passing: passing && { id: passing.id, startedAt: passing.attributes?.startedAt, version: passing.attributes?.additionalProperties?.test_version, }, versionChanged: failingAttributes.additionalProperties?.test_version !== passing?.attributes?.additionalProperties?.test_version, failedSteps: failedIndexes.map((index) => ({ index, failing: compactStep(failedSteps[index]), passing: compactStep(passed?.steps?.[index]), })), }; ``` If there isn't a passing run in the previous 24 hours, widen the baseline search to 7 days and then 60 days. If the result or failed step contains a trace ID, inspect it with `v2.APMTraceApi.getPrunedTraceByID` for a compact trace tree, or `getTraceByID` for the full span list. Discover the request and response types before calling either method. If the result version changed but the executed step evidence is inconclusive, use `getSyntheticsTestVersion` to compare retained configurations. ### Top log error kind ```javascript import { client, v2 } from "@datadog/datadog-api-client"; const logs = new v2.LogsApi(client.createConfiguration()); const result = await logs.aggregateLogs({ body: { filter: { query: "service:example-service status:error @error.kind:*", from: dd.time.hoursAgo(1), to: dd.time.now(), }, compute: [{ aggregation: "count" }], groupBy: [{ facet: "@error.kind", limit: 5, sort: { aggregation: "count", order: "desc", type: "measure" }, }], }, }); return (result.data?.buckets ?? []).map((bucket) => ({ errorKind: bucket.by?.["@error.kind"], count: bucket.computes?.c0, })); ``` For HTTP status breakdowns, keep the SDK shape and change the filter/facet: ```javascript const result = await logs.aggregateLogs({ body: { filter: { query: "service:example-service @http.status_code:[400 TO 599]", from: dd.time.hoursAgo(1), to: dd.time.now(), }, compute: [{ aggregation: "count" }], groupBy: [{ facet: "@http.status_code", limit: 10, sort: { aggregation: "count", order: "desc", type: "measure" }, }], }, }); return (result.data?.buckets ?? []).map((bucket) => ({ status: bucket.by?.["@http.status_code"], count: bucket.computes?.c0, })); ``` ### Top span operation or resource ```javascript import { client, v2 } from "@datadog/datadog-api-client"; const spans = new v2.SpansApi(client.createConfiguration()); const result = await spans.aggregateSpans({ body: { data: { type: "aggregate_request", attributes: { filter: { query: "service:example-service status:error", from: dd.time.hoursAgo(1), to: dd.time.now(), }, compute: [{ aggregation: "count", metric: "*" }], groupBy: [{ facet: "operation_name", // use resource_name for endpoint/resource/path questions limit: 5, sort: { aggregation: "count", metric: "*", order: "desc", type: "measure" }, }], }, }, }, }); return (result.data ?? []).map((bucket) => ({ operation: bucket.attributes?.by?.operation_name, count: bucket.attributes?.compute?.c0, })); ``` For p95 span latency, use `compute: [{ aggregation: "pc95", metric: "@duration" }]` and read `bucket.attributes.compute.c0`. ## JavaScript and imports Code-exec runs JavaScript, not TypeScript: type annotations like `const params: v2.LogsApiAggregateLogsRequest = ...` won't parse. Request objects, class names, method names, and imports follow the declarations returned by the API catalog, but the code itself should be plain JavaScript. The official Datadog SDK and enabled extension virtual packages are resolved inside the sandbox. Use the exact extension import returned by the API catalog rather than assuming a namespace: ```javascript import { client, v1, v2 } from "@datadog/datadog-api-client"; ``` There is no general npm/module access. Non-Datadog imports, filesystem access, and arbitrary network calls aren't available. API calls use the current user's Datadog permissions; credentials are not exposed to scripts. Return a value to send it back. Use `console.log/info/warn/error` for intermediate output. Keep returned values small: aggregate rows, counts, and selected fields rather than raw API envelopes or broad samples. For paginated search and list APIs, follow response cursors when completeness matters; otherwise return a bounded page and label it as partial. Top-level `await` is supported. Optional `timeout` is in seconds (1–180, default 60); raise it for slower aggregate queries. ## Sandbox utilities The only public `dd.*` utilities are time helpers: ```javascript const from = dd.time.hoursAgo(1); const to = dd.time.now(); ``` If you need examples or field discovery after choosing an aggregate path, use a tiny sample and label it as a sample. Do not turn sampled rows into authoritative rankings.

execute_code

Retrieve change events for an APM service over a time range. Use to correlate changes with performance issues, errors or incidents. Tracked Change types: deployment (code/version), feature_flag, traffic_anomaly, watchdog (Datadog anomaly detection), kubernetes (k8s deployment manifest updates), scale (manual k8s scale events), crashloopbackoff (k8s crashloops), database (DB schema or setting changes), schema (data stream schemas only; not DB/API schema), configuration (limited to specific tracked sources — absence does not imply no config changed)

get_change_stories

Retrieves a custom or integration Datadog dashboard by ID, returning its title, description, tags, widgets, and template variables. Use search_datadog_dashboards first to find dashboard IDs. Custom dashboards include an opaque revision_id; pass it as base_revision_id when updating with upsert_datadog_dashboard.

get_datadog_dashboard

Search and retrieve raw Datadog events (deployments, alerts, system activities, infrastructure changes, etc.). Do NOT use for counts, aggregations, or grouped analysis — use aggregate_events instead. Best for: inspecting individual events, reading event titles/messages/tags, and exploring event patterns before deciding how to aggregate them. Add a 'source' only when the question names a kind of event: deploys and other tracked changes: 'source:change_tracking', not 'source:kubernetes', which returns events but not deploys a deployed version Datadog detected as regressing: 'source:deployment_analysis' a monitor firing or recovering: 'source:alert' monitor, downtime and mute edits: 'source:monitor_audit_event' cloud resource changes: 'source:resource_changes' Audit Trail, DORA and Synthetics results are near-absent from the feed and have their own products; tell the user rather than searching events. To see which sources this org has, call aggregate_events with query '*' over 'now-7d', computes [{"field":"*","aggregation":"count","output":"n"}] and group_by {"fields":["source"]}.

search_datadog_events

Get detailed information about a specific Datadog incident by ID, including status, severity, timeline, associated users, and attachments.

get_datadog_incident

Get metadata (description, type, unit, integration), available tags/dimensions, and optionally related assets for a metric. Use this tool to explore a metric before you query it. Set use_cloud_cost=true for Cloud Cost Management metrics.

get_datadog_metric_context_b

Query metrics data from Datadog. Use response_format='timeseries' (default) to get time-indexed data points for graphs and trend analysis. Use response_format='scalar' to get a single aggregated value per group, useful for current state, summaries, and comparisons. For response_format='scalar', use structured query objects; the aggregator field controls how the time window collapses to a single value and defaults to avg if omitted. The query prefix, such as avg: or sum:, is not the scalar aggregator field. Supports multiple queries in one call plus formula expressions. Query syntax: grouping must come before modifiers, e.g. 'sum:trace.http.request.errors{env:prod} by {service}.as_count()', not '.as_count() by {service}'. Within {...}, do not mix comma-separated tag filters with boolean filters; if any top-level filter uses AND, OR, NOT, or IN, join top-level filters with explicit AND and parenthesize OR groups, e.g. '{(service:api OR service:worker) AND datacenter:us1.prod.dog}', not '{service:api OR service:worker,datacenter:us1.prod.dog}'.

get_datadog_metric

List and retrieve information about Datadog monitors. This tool helps discover monitors, their status, configuration, and alerts. Use this tool when you need to find monitors for investigation, management, or analysis purposes.

search_datadog_monitors

Retrieve information about a specific Datadog notebook by ID. This tool provides details including name, status, and associated author. The ID can also be extracted from a URL. The ID will be the last component, for example, <host>/notebook/<ID>.

get_datadog_notebook

Retrieve a trace by trace ID from Datadog APM. This tool fetches all spans within a specific trace by default, providing detailed information about the request flow, timing, and service interactions. For large traces or to retrieve a summarized trace, set only_service_entry_spans=true to get a hierarchical condensed view that shows service boundaries, collapsing internal operations. The summarized view will indicate expandable spans with hidden_child_spans_count. The response includes a trace_deep_link_url in metadata that links directly to the trace flamegraph in the Datadog UI.

get_datadog_trace

Retrieve and visualize Datadog metrics, traces, logs, and other data as interactive charts. Use this tool whenever users ask to see, show, graph, plot, visualize, or rank Datadog data — including ranking-style queries like 'which hosts/services/pods have the most/least X', 'top N by Y', or 'breakdown by Z'. Covers metrics timeseries, request counts, latency, error rates, toplists, and distributions. This tool renders the chart directly and does not require pre-fetched data — raw-data tools alone aren't sufficient for visualization requests. Input modes: Direct definition (write a new widget via widget_definition), By ID (existing widget via dashboard_id + widget_id), or By URL (Datadog widget_url). Supported interactive types: bar_chart, change, cohort, distribution, funnel, geomap, heatmap, list_stream, note, point_plot, query_table, query_value, retention_curve, sankey, scatterplot, slo_summary, sunburst, timeseries, toplist, treemap. Before constructing widget_definition, load the datadog/visualizations skill for schema patterns, response shape, and recovery.

get_widget

Get complete TypeScript schemas and building instructions for specific widget types. Note: "group" is a container for organizing related widgets — include both "group" and any intended child widget type/s in one call for deduplication.

get_widget_reference

List user-authored annotations on a Datadog dashboard or notebook for a given time range. Returns annotations ordered by start_time.

list_annotations

List and retrieve information about Datadog dashboards. This tool helps discover available dashboards, their IDs, titles, and underlying queries. Use this tool when you need to find specific dashboards, get an overview of all dashboards in your Datadog account, or find important logs+metrics queries in dashboards. To retrieve template variables or widget details for known dashboard IDs or URLs, extract each ID and call get_datadog_dashboard once per dashboard_id instead.

search_datadog_dashboards

List available Datadog skill guides. Skills document how to use Datadog's tools: the right attributes, query syntax, and common pitfalls. Call this before load_datadog_skill whenever you are not already certain of the exact skill name; skill names are not predictable from topic words. Use query for fuzzy search across name and description (results are ranked). Use include_header=true to see one-line summaries alongside names. Load skills proactively when starting work in a relevant Datadog domain, not after errors.

list_datadog_skills

Explore Datadog hosts inventory with SQL. Queries run against the virtual 'hosts' table backed by "dd.hosts" (Advanced Query API), which exposes hostname, hostname_aliases (text[]; use hostname_aliases[1]), tags (hstore map; use tags->'key'), cloud_provider, resource_type, instance_type, os, os_version, agent_version, memory_mib, cpu (hstore map; use cpu->'key'), kernel (hstore map; use kernel->'key'), sources (text[]; use sources[1]), modification_detected_at (timestamp). DDSQL notes: DDSQL (Datadog SQL) is a PostgreSQL subset: every non-aggregated SELECT column must appear in GROUP BY, SELECT aliases cannot be reused in WHERE/GROUP BY/HAVING (repeat the full expression instead, e.g., GROUP BY DATE_TRUNC('hour', timestamp) not GROUP BY hour), and only declared table columns may be referenced. Use the -> operator or json_extract_path_text (cast as needed) for JSON access. Avoid unsupported constructs like ANY(), ->>, QUALIFY, information_schema, and current_timestamp. Column names containing special characters like '@' must be quoted (e.g., SELECT "@foo" FROM logs).

search_datadog_hosts

Search Datadog incidents. Default sort: newest first. Supports filtering by state, severity, title, team, creation time, and more. Use `semantic_query` for natural-language search over AI-generated incident summaries. Prefer `query` first; only add `semantic_query` when query by keyword and metadata filters aren't sufficient to answer the question.

search_datadog_incidents

List feedback submitted about Datadog MCP server capabilities. This only includes feedback for this Datadog MCP server, not other MCP servers or plugins. You must specify either org_id or all_orgs (but not both).

list_mcp_feedback

List available metrics in Datadog with optional filtering by name and tags. Set use_cloud_cost=true to search Cloud Cost Management metrics.

search_datadog_metrics

Retrieve raw Datadog APM spans matching a query. Do NOT use for counts, aggregations, or grouped analysis — use aggregate_spans instead. Best for: inspecting individual spans, debugging request flows and failures, and discovering span fields/attributes, including via custom_attributes, that you may want to aggregate or group by with aggregate_spans. IMPORTANT: When the user asks for 'security traces', 'AppSec traces', 'AAP traces', 'security activity', or 'security signals on traces', the query MUST start from `@appsec.security_activity:*`. Do NOT substitute keyword-based guesses like `service:*security*`, `resource_name:*auth*`, `@http.status_code:401`, etc. — those do not identify security traces. Application & API Protection (AAP) spans carry these standard attributes (all strings): `@appsec.security_activity` (`<category>.<type>`, e.g. `attack_attempt.sql_injection`, `business_logic.users.login.failure`; multi-valued when multiple rules match); `@appsec.category` (top-level classification, e.g. `attack_attempt`, `business_logic`); `@appsec.type` (specific threat/event type, e.g. `sql_injection`, `xss`, `users.login.failure`); `@appsec.rule_id` (AAP rule that matched, e.g. `crs-942-100`; multi-valued); `@appsec.blocked` (`true`/`false`, whether AAP blocked the request). Use these attributes to narrow AppSec queries (e.g. `@appsec.category:attack_attempt`, `@appsec.type:sql_injection`, `@appsec.blocked:true`). The response includes a traces_explorer_url for the overall query. To link to an individual trace in the Datadog UI, use the pattern: <base_url>/apm/trace/<trace_id> (e.g. https://app.datadoghq.com/apm/trace/abc123). The base_url for the user's org is available in the response metadata.

search_datadog_spans

Load a Datadog skill guide before using related Datadog tools. Skills improve query quality by documenting the right attributes, syntax, and common pitfalls. Skill names depend on the visible toolsets; if you do not already know the exact skill name from a prior list_datadog_skills response, call list_datadog_skills first and do not guess names from topic keywords. Set header_only=true to preview a skill's summary, related skills, and bundled resources. Set resource_path to load a specific bundled reference.

load_datadog_skill

Recovers a soft-deleted Datadog notebook by ID. Only notebooks within the deleted-notebook retention window can be recovered.

recover_datadog_notebook

Search Datadog entities through the entity graph, including attributes and direct relationships. Prefer this tool over searching telemetry, monitors, dashboards, or other resources when the request is about service identity, catalog ownership, dependencies, or services owned by the current user's teams. Use entity_type=service directly for identity lookups and dependency questions fully covered by available guidance; kind: is added by the server. Search directly only when exact names are established by available guidance. Do not use validation errors to discover fields or relationships, and do not probe plausible names. Ref, type, and known type-specific identity fields are always returned, so omit fields for name-only discovery. Treat dependency requests and explicit requests for all, every, complete lists, or inventories as complete. Explicit all, every, complete-list, and inventory requests override this bounded-search rule. Treat owner- or team-filtered service searches as complete unless the user explicitly requests a sample, maximum count, or first page. For complete results, continue while METADATA.page_truncated is true, page_next_cursor remains, or a requested relationship is truncated or has next_cursor. Do not infer completion from a short page. Set owned_by_current_user_teams=true instead of inferring the user's teams from telemetry. For service ownership, request the owner field; do not invent an ownership relationship. Query supports boolean expressions such as name:chrono OR owner:idp. Use exact name:value when the user supplies a concrete internal service name; do not broaden it with wildcards. Use name:value* for prefix requests. For vague possible-match requests that do not require complete results, make one search with page.limit at most 25 using name:*value*. Present an incomplete, non-ranked candidate sample and ask the user to narrow the request; do not paginate. For a dependency question with no direction, request both upstream_services and downstream_services and keep the directions separate. Filters and relationship names are validated by the entity graph. Requested fields may be omitted, so do not treat an absent field as empty. Use owned_by_current_user_teams only when guidance for the selected entity type says it is supported.

search_datadog_entities

Discover the exact operations and types needed for `execute_code`. Write JavaScript against the official SDK and code-exec extension catalog available to the current user and sandbox policy. Its data stays inside the sandbox; only the value you return enters the conversation. This tool reads metadata, not live Datadog data. **Select the operation and collect its request/response types in the same script.** Start from the operation's `typeRefs`, then follow each type's `refs` to expand nested definitions. Returning only the immediate types often leaves request fields undefined and requires another search. Follow those references rather than guessing related type names. Quick start: select an operation and expand its referenced types before returning. The helper below is ordinary JavaScript defined in this example, not a built-in catalog method. Adapt the predicate to the task; you don't need to know nested type IDs in advance. ```javascript const operation = catalog.operations.find( (op) => op.version === "v2" && op.api === "MetricsApi" && op.method === "queryScalarData" ); if (!operation) return { operation: null }; function collectTypes(rootIds, maxTypes = 24, maxChars = 12000) { const definitions = []; const omittedTypeIds = []; const pending = [...rootIds]; const seen = new Set(); let chars = 0; while (pending.length > 0) { const id = pending.shift(); if (seen.has(id)) continue; seen.add(id); const definition = catalog.types[id]; if (!definition) continue; if ( definitions.length >= maxTypes || chars + definition.declaration.length > maxChars ) { omittedTypeIds.push(id); continue; } definitions.push(definition); chars += definition.declaration.length; pending.push(...definition.refs); } return { definitions, omittedTypeIds }; } return { operation, types: collectTypes(operation.typeRefs), }; ``` Return the selected operation, including its signature and `usageNotes`, together with bounded type definitions and any omitted type IDs. If expansion omits a definition needed to construct the request or interpret the response, retrieve that definition before executing. Otherwise, proceed to `execute_code`; a separate type-lookup call isn't required. For broad matches, return a small operation shortlist. For an operation you intend to execute, include its referenced types. Narrow the operation selection before reducing the type-expansion budget. Don't return the complete operations or types collections. There is no `search(...)` helper. `catalog.operations` is an array; `catalog.types` is a record keyed by type ID, not an array. The catalog is function-free: there is no built-in `describe`, continuation callback, or executable `next` value. Use normal array/object traversal. Your code runs as the body of an async function. Write plain JavaScript, not TypeScript, and use `return` to return JSON. There is no `dd`, package loader, network, or Datadog API access in this metadata-only sandbox. ## Catalog contract Filter operations by product API (for example, `LogsApi`, `SpansApi`, or `MetricsApi`), method, summary, tags, or HTTP path. Use `.filter(...).slice(0, 3)` for a bounded shortlist; when selecting several operations to execute, collect their referenced types in the same program. Catalog operations have two invocation surfaces. Official SDK operations use `version`, `api`, and `method` through `@datadog/datadog-api-client`. Extension operations use `surface: "code-exec"` plus their exact `module`, `export`, and `method` through the sandbox-only `@datadog/code-exec` package. Don't translate either surface to `dd.<namespace>`; product API/helper namespaces aren't exposed on `dd`. For example, an operation with `version: "v2"`, `api: "SpansApi"`, and `method: "aggregateSpans"` is called as: ```javascript import { client, v2 } from "@datadog/datadog-api-client"; const spans = new v2.SpansApi(client.createConfiguration()); const request = { /* fields from the discovered request declarations */ }; const result = await spans.aggregateSpans(request); ``` ```typescript type SDKVersion = "v1" | "v2"; type TypeID = `${SDKVersion | "code-exec"}.${string}`; interface Catalog { readonly schemaVersion: 1 | 2; readonly operations: readonly (SDKOperation | ExtensionOperation)[]; readonly types: Readonly<Record<TypeID, TypeDefinition>>; } interface SDKOperation { readonly id: string; // for example, "v2.LogsApi.aggregateLogs" readonly version: SDKVersion; readonly api: string; readonly method: string; readonly summary: string; readonly httpMethod: string; readonly path: string; readonly tags: readonly string[]; readonly pagination: boolean; readonly signature: string; readonly typeRefs: readonly TypeID[]; readonly usageNotes: readonly string[]; } interface ExtensionOperation { readonly id: string; // for example, "code-exec.product.operation" readonly surface: "code-exec"; readonly module: "@datadog/code-exec"; readonly export: string; readonly method: string; readonly summary: string; readonly signature: string; readonly typeRefs: readonly TypeID[]; readonly usageNotes: readonly string[]; readonly readOnly: true; } interface TypeDefinition { readonly id: TypeID; readonly declaration: string; readonly refs: readonly TypeID[]; } declare const catalog: Catalog; ```

search_datadog_sdk

Search and retrieve raw log entries or log patterns. Do NOT use for counting or aggregations — use analyze_datadog_logs instead. Best for: viewing raw logs, discovering patterns (use_log_patterns=true), and discovering custom attributes via extra_fields for use as extra_columns in analyze_datadog_logs. Response shape (when extra_fields is set, output is YAML): three buckets — (1) top-level fields like env/host/service queried bare (`env:prod`); (2) `attributes:` map with source-prefixed keys — `custom.X` and `attributes.X` are queried as `@X` (strip the bucket prefix), but `error.X` keeps its prefix as `@error.X` because `error` is a real top-level attribute; (3) `tags:` list of `key:value` strings queried bare. Load the datadog/logs skill for the full key-translation table.

search_datadog_logs

Search Datadog notebooks. Use this tool when you need to find notebooks for investigation or monitoring purposes. Results can be filtered, for example by author, and sorted. This tool returns snippets of the original notebook. To fetch the entire notebook, use the get_datadog_notebook tool.

search_datadog_notebooks

Search and retrieve raw Datadog RUM events using advanced query syntax. Do NOT use for counts, aggregations, or grouped analysis. Best for: inspecting individual RUM events, debugging specific user experience issues, exploring available event attributes in raw or detailed_output responses before deciding what to aggregate. Supports filtering by event types (session, view, action, error, resource, long_task, vital, operation), user attributes, performance metrics, and more. Results include detailed event data for analysis.

search_datadog_rum_events

Submit feedback about capabilities provided by this Datadog MCP server only. Do NOT submit feedback about other MCP servers or plugins (e.g. Atlassian, CodeSandbox, Slack, GitHub). After completing a task, briefly consider whether any Datadog MCP capability was notably unhelpful or whether the workflow was harder than it should have been. If so, submit feedback so the MCP team can improve the experience. You should submit feedback when: - A Datadog MCP capability produced wrong, misleading, or unhelpful results that impacted your ability to help the user. - A Datadog MCP capability's output was missing key information that would have been useful. - You could not accomplish something the user asked for because no Datadog MCP capability exists for it. - A Datadog MCP workflow required many steps or workarounds that could be streamlined. - A Datadog MCP capability's interface was confusing or its parameters were unclear. Keep it to one submission per distinct issue per conversation. Skip transient errors (timeouts, rate limits) that resolved on retry.

submit_mcp_feedback

Update an existing annotation on a Datadog dashboard or notebook. All writable fields are replaced with the provided values, including widget_ids — pass the full intended targeting every call (use list_annotations first if you need the existing widget_ids). Omit end_time to make the annotation point-in-time; provide end_time to make it a time-range annotation.

update_annotation

Validate a widget definition against the dashboard schema. Call when generating a widget JSON.

validate_dashboard_widget

Render tabular data as an interactive visualization (sunburst, treemap, or toplist). WHEN TO USE: - After aggregating data from queries (GROUP BY, analytics, metrics) to visualize hierarchical relationships or rankings - For ad-hoc visualization of data you've already fetched and transformed - When you have grouped data and want to show proportional breakdowns or parent-child relationships ALTERNATIVES: - Use get_widget to directly render data from existing dashboard widgets - Use swap_widget_type to convert saved widget definitions between types

visualize_tabular_data

do-not-call

_dd_gff

do-not-call

_dd_guc

do-not-call

_dd_wfd

do-not-call

_dd_wwd