Dash0 acquires Polar Signals

Last updated:

Query Telemetry via MCP

Reference for the Dash0 MCP Server's direct read-only tools, the ones your AI assistant calls to query metrics, logs, traces, services, checks, SLOs, synthetics, dashboards, and frontend data, with their required parameters and the conventions they share.

The Dash0 MCP Server exposes a set of direct, read-only tools that let your AI assistant (Claude Code, Claude.ai, Cursor, and similar) query your observability data without learning PromQL or OpenTelemetry semantics. Each tool answers one specific question, returns a value, and consumes no Agent0 credits.

This page is the reference for those direct tools. For handing a whole open-ended investigation to Agent0 instead, see Delegate to Agent0 via MCP.

Note

This page covers the outbound direction: your AI assistant calling into Dash0 through the Dash0 MCP Server. It is not about connecting external MCP servers into Agent0 as connectors, the opposite direction. For that, see Use MCP in Chat and Automations.

Direct Tools vs Delegation

The server exposes two kinds of tools:

  • Direct telemetry tools: the ones documented on this page. Your assistant picks the tool, supplies the parameters, and gets back a value. They read and return data only, and consume no credits.
  • Agent0 delegation tools: runTask, waitForTask, and the thread-inspection tools. These hand a question to Agent0, which works out the queries itself. They consume Agent0 credits and are documented, together with their cost and how to disable them, in Delegate to Agent0 via MCP.

Reach for a direct tool when you already know which value you want ("the current p95 latency for checkout-service", "the failed checks in the last hour"). Delegate when the question is open-ended and spans signals ("why did checkout-service get slow around 14:00?").

Connecting

The direct tools become available once the Dash0 MCP Server is connected to your assistant. Setup snippets for each supported tool are in the Integration Hub. See Use AI in Dash0 for the overview.

Common Parameters

Most direct tools share the same conventions. They are described once here and not repeated for every tool below.

  • dataset: Required by every tool except listDatasets. Pass the dataset's technical ID. Call listDatasets first to discover the available datasets and their technical IDs.
  • timeRange: An object with from and to. Both accept ISO timestamps (2026-01-15T14:30:00.000Z) or relative references (now, now-1h, now-30m). from must be a time in the past and must be earlier than to; the two values must differ. Where a tool makes timeRange optional, it defaults to the last hour.
  • filters: An array of { key, operator, value } objects. Discover available keys with getAttributeKeys and their values with getAttributeValues. Supported operators: is, is_not, is_set, is_not_set, is_one_of, is_not_one_of, contains, does_not_contain, starts_with, does_not_start_with, ends_with, does_not_end_with, matches, does_not_match, gt, gte, lt, lte, is_any. The default operator is is.
  • pagination: Limits the result set. limit is between 1 and 50. List and catalog tools page with an offset; record-oriented tools (logs, spans, failed checks, metric catalog, web events) page with a cursor returned in each response.

Discovery

Start here to learn what you can query before querying it.

listDatasets

Lists the datasets you can access, with each one's display name and technical ID. Takes no parameters. The technical ID it returns is the dataset value every other tool expects.

getAttributeKeys

Lists the attribute keys present in a given telemetry kind over a time range.

  • Required: scope, timeRange, dataset.
  • scope: Selects the data source, one of logs, metrics, spans, resources (resource-level attributes), or web-events (browser and RUM events).
  • Optional: filters, a regex to match keys, sorting, pagination.

getAttributeValues

Lists the values present for one or more attribute keys. Pass several keys in one call to avoid repeated round trips.

  • Required: attributeKeys (a single key or an array), scope, timeRange, dataset.
  • Optional: filters, a regex to match values, sorting, pagination.

Services and Infrastructure

getServiceCatalog

Returns the catalog of services with their RED metrics (request rate, errors, duration) and a map of their inter-dependencies.

  • Required: dataset.
  • Optional: timeRange (defaults to the last hour), filters, sort (by requests_total, errors_percentage, duration_p95_seconds, service.name, or service.namespace), pagination.
  • Note: Rows whose dash0.resource.type is external are uninstrumented dependencies you do not operate (databases, queues, third-party APIs); their RED reflects the dependency's own aggregate health. Use getServiceDetails for a per-caller breakdown.

getServiceDetails

Returns one service's RED metrics, health, operations, replicas, infrastructure, related resources, and direct dependencies.

  • Required: serviceName, dataset.
  • Optional: serviceNamespace, timeRange (defaults to the last hour).

getK8sPods

Returns the catalog of Kubernetes pods with their RED metrics and a dependency map.

  • Required: timeRange, dataset.
  • Optional: filters, pagination.

Metrics

getMetricCatalog

Lists the metrics available in a dataset, each with its OpenTelemetry type.

  • Required: timeRange, dataset.
  • Optional: filters, pagination.

getMetricDetails

Returns the details of a single metric, including its type and attributes.

  • Required: metricName, metricType, timeRange, dataset.
  • metricType: One of sum, gauge, histogram, exponential_histogram, summary. If you do not know it, call getMetricCatalog or getMetricDetails first rather than guessing, since the wrong type makes the query fail.

getMetricQuery

Builds a PromQL expression for a metric and returns it as text. It does not execute the query and takes no time range.

  • Required: metricName, metricType, dataset.
  • Optional: aggregationFunction (min, max, avg, sum, or a percentile such as p95; percentiles apply only to histogram and exponential_histogram, and summary accepts only avg), aggregationInterval (the range-vector window, default 5m), filters, groupBy, metricUnit.
  • Note: Use this to construct a correct expression, then run it with promql.

promql

Executes a PromQL query.

  • Required: query, dataset.
  • Optional: timeRange, timestamp (the reference point for an instant query), timeSeriesOptions (produces a time series by evaluating at multiple steps).
  • Note: Select a metric by its OpenTelemetry name as the value of the otel_metric_name label, for example {otel_metric_name="dash0.spans"}. The dots-to-underscores rule applies only to label keys, never to the metric name itself.

sql

Executes a D0QL query, a ClickHouse SQL subset, against your observability data.

  • Required: query, timeRange, dataset.
  • Note: SELECT queries return at most 20 rows.

Logs

getLogRecords

Returns log records matching the filters and time range.

  • Required: timeRange, dataset.
  • Optional: filters, logAttributeKeys (the attribute keys to return, default service.name and dash0.resource.type), pagination.

getFullLogRecord

Returns a single log record by ID, with its full attributes and body.

  • Required: logRecordId, dataset.

getLogCorrelations

Compares a baseline population of logs against a subset to find the attributes most correlated with the subset.

  • Required: dataset.
  • Optional: baselineFilters, timeRange (defaults to the last hour), minAbsoluteCorrelation.
  • Defining the subset: Use subsetSelection to pick a named subset within the baseline (errorLogs, or logsAfterTimestamp with a timestamp), or subsetFilters to define the subset as its own independently filtered population (for example logs from a failing pod against a healthy one). The two are mutually exclusive; subsetFilters must repeat any scope the baseline already applied. The default is errorLogs.

Traces and Spans

getSpans

Searches spans and returns their name, status, service, resource, metadata, and extra attributes.

  • Required: dataset.
  • Optional: filters, timeRange (defaults to the last hour), ordering (latestFirst or oldestFirst), spanAttributeKeys (extra keys to display), pagination.

getTraceDetails

Returns the details of a trace or span, including its events, hierarchy, and comparison to similar spans.

  • Required: traceId, dataset.
  • Optional: spanId (defaults to the trace's root span; use it to navigate into children or ancestors), timeRange.
  • Note: Always pass timeRange when you have time context. Looking up a trace without any time constraint is much slower.

getFullSpanEvent

Returns a single span event with its full attributes. Use it when getTraceDetails shows a span event with truncated attributes, such as an exception.stacktrace.

  • Required: traceId, spanId, eventName, dataset.
  • Optional: eventIndex (0-based, to disambiguate events sharing a name; defaults to the first match).

getSpanCorrelations

Compares a baseline population of spans against a subset to find the attributes most correlated with the subset.

  • Required: dataset.
  • Optional: baselineFilters, timeRange (defaults to the last hour), minAbsoluteCorrelation.
  • Defining the subset: Use subsetSelection for a named subset within the baseline (errorSpans, spansAboveDurationThreshold, spansAfterTimestamp, or spansWithinBoundingBox), or subsetFilters for an independently filtered population. The two are mutually exclusive; subsetFilters must repeat any scope the baseline already applied. The default is errorSpans.

Checks and SLOs

getFailedChecks

Lists failed checks over a time range.

  • Required: timeRange, dataset.
  • Optional: filters, pagination.
  • Note: Each status is as of the end of the requested time range, not the present moment. A check that ended within the range reports resolved, and unknown means the status is missing rather than healthy.

getFailedCheckDetails

Returns detailed information about one failed check.

  • Required: issueIdentifier, timeRange, dataset.
  • Note: issueIdentifier (dash0.issue.identifier) is one grouping of a check rule that fired, not a check rule ID (dash0.check.id). To go from a rule to its issues, list failed checks filtered on dash0.check.id first.

listSlos

Lists the Service Level Objectives defined natively in Dash0, each with its ID, origin, and display name. This is the starting point for any SLO, SLI, or error-budget question.

  • Required: dataset.
  • Optional: pagination, a regex to match name or origin.

getSlo

Returns one SLO's full definition (its objective, target, and indicator) by the ID or origin taken from listSlos.

  • Required: sloId, dataset.
  • Optional: format set to openslo to return the definition as a public OpenSLO v1 YAML document instead of Dash0's internal representation.

Synthetic Checks

getSyntheticChecks

Returns synthetic HTTP check statuses and their current health state.

  • Required: timeRange, dataset.
  • Optional: filters.

getSyntheticCheck

Returns one synthetic check's definition by ID or origin.

  • Required: syntheticCheckId, dataset.

Frontend and Real User Monitoring

listWebsites

Lists website services in alphabetical order with their metrics: sessions, page views, users, bounce rate, requests, errors, LCP, CLS, and INP.

  • Required: timeRange, dataset.
  • Optional: pagination.

getWebEvents

Searches web events and returns their ID, name, associated span and trace IDs, and extra attributes. Returns at most 50 events.

  • Required: dataset.
  • Optional: filters, eventNames, eventAttributeKeys, ordering, serviceName, sessionId, timeRange, pagination.
  • Note: When sessionId is set, serviceName is required and the time range, event names, and pagination are ignored. Otherwise timeRange and pagination apply.

Dashboards

listDashboards

Lists the dashboards in a dataset.

  • Required: dataset.
  • Optional: pagination, a regex to match name, description, or tags.

generateDash0Url

Generates a shareable Dash0 deep-link URL for a specific page, returned as a <dash0link> tag that renders as a clickable button.

  • Required: page, dataset.
  • page: An object whose pageType selects the target and the fields it accepts: logs (Logs Explorer), traces (Trace Explorer), web-events (Web Events Explorer), check-rules (Alerting Check Rules), automations (Agent0 Automations), or agent0-thread (a specific Agent0 conversation thread).

Further Reading