The Dash0 MCP Server doesn't only expose individual read-only telemetry tools. It can also hand a whole investigation to Agent0 through the runTask tool, so Agent0 forms hypotheses, runs its own queries across metrics, logs, and traces, and reports back, instead of your AI assistant assembling those queries itself.

Note

This page covers the outbound direction: your AI assistant (Claude Code, Claude.ai, Cursor, and similar) 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.

What It Is

Delegation, not query assembly: runTask sends a question to Agent0 and lets it investigate, rather than requiring your assistant to work out which telemetry tools to call and in what order.
Read-only over MCP: Agent0 investigates and reports. It does not apply changes through this path. It cannot create dashboards or check rules, open pull requests, or write to Dash0 or any connected system. Those capabilities exist in Chat and Automations, not over MCP.

When to Use It

Open-ended or underspecified questions that span metrics, logs, and traces: incident investigation, "why is X slow or failing," impact analysis, anything that requires forming and testing a hypothesis. Agent0 works out the right queries instead of you or your assistant assembling them.
A single, already-known value: use the matching direct telemetry tool instead. It's faster and consumes no credits.

Question	Better fit
"Why did checkout-service get slow around 14:00?"	`runTask` — spans multiple signals and needs a hypothesis tested
"What's the current p95 latency for checkout-service?"	`getMetricQuery` — a single known value
"Did the last deploy correlate with the error spike?"	`runTask` — needs correlation across deploys, logs, and traces
"List the failed checks in the last hour"	`getFailedChecks` — direct, no investigation needed

Cost

Delegating to Agent0 consumes Agent0 credits, roughly 1-2 credits for a full investigation depending on how many steps it takes. See Pricing for the current credit rate.

The other Dash0 MCP tools, the direct telemetry queries like getMetricQuery, getLogRecords, or getFailedChecks, consume nothing. That's the tradeoff: delegation costs credits because Agent0 does the investigative work; calling a specific tool for a value you already know how to ask for doesn't.

Mechanics

Delegation uses two MCP tools together.

runTask

Starts or continues an Agent0 investigation.

message and dataset are required. dataset is the dataset to query. Use the listDatasets tool to discover available datasets.
timeoutSeconds (default 25, max 45): how long runTask waits inline for Agent0's answer. If Agent0 finishes within this window, you get the answer directly. If not, runTask hands back a thread link and Agent0 keeps working in the background rather than being cut off.
threadIdOrUrl (optional): pass a previous thread's ID or URL to continue that conversation instead of starting a new one.
networkLevel (default full): controls what the agent can reach on the network while it investigates. See below.

waitForTask

Blocks until an in-flight runTask thread finishes, then returns its final answer.

threadIdOrUrl and dataset are required, matching the thread runTask handed back.
timeoutSeconds (default 300, max 600): how long to block waiting for the result.

If an investigation is still running after waitForTask's timeout, call it again with the same thread rather than starting over. getAgent0ThreadStatus and getAgent0ThreadContent can also inspect a backgrounded thread's progress without blocking, and listAgent0Threads finds threads by title if the link was lost.

networkLevel

The same egress concept as Agent0 Chat's network mode, exposed here as a per-call parameter:

full (default): unrestricted outbound access.
trusted_only: a curated allowlist of common package registries, source control, and cloud SDKs. See the full trusted hosts list.
no_network: no outbound network access. Some connectors won't be available.

Disabling Agent0 delegation

There is no server-side or organization-level switch to disable an individual Dash0 MCP tool today. runTask and waitForTask ship as part of the same MCP server as the read-only telemetry tools, so turning them off is done per client, in whatever tool is connecting to the Dash0 MCP Server.

Note

This is different from the per-tool checkboxes under Settings → Integrations → MCP. Those control tools that external MCP servers expose to Agent0 as connectors. They have no effect on runTask or waitForTask, which are tools the Dash0 MCP Server exposes to your assistant. See Set Up MCP Integration for that other direction.

Claude Code

Deny the specific tools in permissions.deny, using the pattern mcp__<server>__<tool>, where <server> is whatever name you gave the Dash0 MCP server when you added it (check with claude mcp list if unsure):

json

12345678
{
  "permissions": {
    "deny": [
      "mcp__dash0__runTask",
      "mcp__dash0__waitForTask"
    ]
  }
}

The rest of the server's tools stay available. Denying the bare server name (mcp__dash0) removes the whole server instead.

Claude.ai connectors

Claude.ai doesn't have a settings.json equivalent. Individual tools are toggled from the conversation itself: open the Search and tools menu (the + button, or /, in the message composer) and turn off runTask and waitForTask under the Dash0 connector.

Cursor

Cursor has no config-file option for disabling individual tools; mcp.json only configures which servers connect. Disable specific tools from Settings → Tools & MCP, expand the Dash0 server, and toggle off runTask and waitForTask.

Delegate to Agent0 via MCP