Datadog
Query and visualize data
- Category
- Developer Tools
- Primary Subcategory
- Observability, Monitoring & Incident Response
Integration details
Description
Datadog MCP Server helps users investigate observability data, inspect dashboards and notebooks, load Datadog skill guidance, search Datadog entities, review change stories, and visualize Datadog metrics, logs, traces, RUM events, incidents, hosts, monitors, and events through ChatGPT for this scoped connection.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Observability, Monitoring & Incident Response
- Secondary Subcategories
- None listed
- Brand
- Datadog
- Access
- Account required
- First tracked
- 2026-09-15
- Tool count
- 42
- Geography
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Get alerts for Datadog
Get updates when Datadog’s Discoverability Score or category rank changes.
ChatGPT Plugin Discovery Score
ChatGPT Plugin discovery is coming soon
ChatGPT can surface a Plugin when it matches a user's request.Your Plugin Discovery Score measures how often yours appears.
No spam. Unsubscribe any time.
What discovery looks like

Competing in ChatGPT Observability, Monitoring & Incident Response
View Category42 tools agents can invoke
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_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_rum_events
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.
aggregate_spans
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_logs
Get targeted instructions for building a Datadog widget. Returns a concise how-to guide — widget type recommendations, required fields, schema patterns, and an annotated example — that you use to build the widget definition yourself. The expert has deep knowledge of all widget types and schemas but does NOT have access to real telemetry, live data, or the user's environment. Any examples in the response use PLACEHOLDER values for queries. You are responsible for discovering real metric names, log queries, or APM resource names through data exploration tools and substituting them — do not copy example queries directly into a widget without first validating them against real data. Returns focused instructions rather than a full schema dump, so it's cheaper than get_widget_reference. Useful at any stage: choosing a widget type, understanding schema requirements, or debugging an invalid widget.
ask_widget_expert
Creates a new Datadog notebook. Include key findings, evidence, supporting data, and complete query documentation unless told otherwise. Do not start the first markdown cell with a heading that repeats the notebook name — it is already displayed as the title. Look up widget reference schemas before constructing graph cells.
create_datadog_notebook
Creates or updates a Datadog ordered-grid dashboard. New dashboards are always ordered; widget updates are only supported on ordered dashboards. When updating widgets, prefer diff-style payloads to minimize tokens: send full definitions only for new or changed widgets, include {"id": N} for unchanged widgets to keep, and omit existing widgets only when deleting them.
upsert_datadog_dashboard
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
do-not-call
get_widget_data_fetcher
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.
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. Useful for exploring metrics before querying them. Set use_cloud_cost=true for Cloud Cost Management metrics.
get_datadog_metric_context
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, 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 TypeScript schemas and building instructions for widget types. Call before generating widget JSON. 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 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.
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
Search Datadog services through the entity graph, including service ownership and direct upstream or downstream 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 ordinary service lookup and dependency questions; kind: is added by the server. Ref, type, and type-specific identity fields are always returned, so omit fields for name-only discovery. Treat an unqualified list or dependency request as complete unless the user asks for a page or sample. Follow page_next_cursor from METADATA and each truncated relationship's next_cursor until complete. Set owned_by_current_user_teams=true instead of inferring the user's teams from telemetry. 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. Use name:*value* and return candidates for contains or ambiguous requests. Contains results are ordered, not relevance-ranked; if they are truncated, narrow the query or ask the user to clarify instead of treating the first page as the best matches. For a dependency question with no direction, request both upstream_services and downstream_services and keep the directions separate. Service ownership is returned as owner; the legacy term team is accepted as an input alias.
search_datadog_entities
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
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_rfw
do-not-call
_dd_wfd
do-not-call
do_not_call_refresh_widget
do-not-call
get_active_feature_flags
do-not-call
get_user_config
How do I improve a ChatGPT Plugin's discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are Datadog alternatives on ChatGPT?
As of 2026-09-20, Datadog competes with Birdie, Connhex, elmah.io MCP, HOME AI Node, Honeycomb, Is It Down? Availability Check, Resolve AI, Rootly, SiteTriage, Threpoly, Watchgoose in ChatGPT Observability, Monitoring & Incident Response, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.