Your AI assistant could already read Dash0: run a metric query, pull log records, list failed checks. That works when you already know what to ask for. It works badly when you don't, because the assistant has to guess which attribute, which filter, which time range, and then guess again when the first answer looks wrong.
runTask hands the whole question to Agent0 instead. You describe the problem in plain language. Agent0 works out which telemetry to pull, follows what it finds, and reports back a conclusion. One of these is a delegation: one question, one investigation, one Agent0 thread in Dash0 you can open and read.
What you can ask it
- "What's wrong with checkout?" Vague on purpose. Agent0 works out the right query rather than making you name the exact attribute and filter.
- "Did the 13:52 deploy cause the error spike?" A hypothesis you want confirmed or refuted against live telemetry, not a number you already know.
- "If I rename http.request.duration, what breaks?" Which dashboards and check rules depend on a metric, span, or attribute before you change it.
- "Which endpoint is burning the most CPU?" A profiling question, not a metrics question.
- "I just shipped the fix. Did it work?" Verification against telemetry after a change.
What you get beyond the telemetry tools
What it can reach that your assistant cannot
The MCP server gives your assistant read access to your telemetry: metrics, logs, traces, spans, services, failed checks. That is the right tool when you already know what you want. Agent0 has all of it, and more:
- Continuous profiling. Not available through the telemetry tools at all, so questions about CPU and memory at the code level can only be answered this way.
- What is inside your dashboards and check rules. Your assistant can list them. Agent0 can read them, which is how it works out what a renamed metric will break.
- Validation before it hands anything over. When the answer is a new dashboard or check rule, Agent0 confirms it is valid first, so what you get back is something you can actually create.
- Full user sessions, not just individual web events.
- Deep links, so it can hand you a pre-filtered link into the Logs or Trace Explorer rather than telling you where to look.
Where your organization has connected them, it can also read context outside Dash0, such as your repository or issue tracker, to tie a change in the data back to a change someone made.
It knows how Dash0 works
Handing an assistant a PromQL tool does not teach it Dash0's PromQL. It still has to work out how metrics are selected, how OpenTelemetry attribute names map to Prometheus ones, which attributes to fall back to when a metric is not where it expects, and how Dash0's synthetic metrics work. It will get some of that wrong, and a query that runs but returns the wrong thing looks exactly like one that is right.
Agent0 already knows, along with the equivalent for turning spans into latency percentiles and error rates, joining across logs, spans, and web events, and reading dashboards and check rules. It is the difference between a capable assistant guessing at an unfamiliar system and one that already knows it.
How it works in practice
Quick questions come back inline. Anything substantial takes longer than a tool call should block for, so runTask hands you a thread link and Agent0 keeps working in the background while you carry on. Ask for the result when you want it, or open the link to watch the investigation in Dash0 and see exactly which telemetry it queried to reach its answer. Follow up on the same thread and it keeps the earlier context.
You do not have to take its word for it. Every step is on the thread, so a conclusion you doubt is one you can check.
What it costs
An investigation uses Agent0 credits, billed exactly as a conversation in the Dash0 UI is. There is no flat rate per question. Cost scales with the work the question takes: how many steps Agent0 runs, and how much telemetry it analyzes. Checking whether a metric exists is cheap. Root-causing an incident across metrics, logs, and traces on a busy service costs more. Following up on a thread costs credits too.
The direct telemetry tools stay free. If you already know the exact value you want, ask for it directly and pay nothing.
Your organization's Agent0 credit limit applies here as everywhere else, so this cannot run past the cap you have set.
Worth knowing: your assistant decides when to delegate. It reads your question, judges it open-ended, and calls runTask on its own. You do not have to name Agent0 for a delegation to happen.
Staying in control
It cannot change anything
Over MCP, Agent0 investigates and reports. It does not edit code, open pull requests, post messages, or create, edit, or delete anything in Dash0. When the answer is a new dashboard or check rule, it hands you the definition to create yourself.
This is not a matter of trusting the model to behave. Every investigation started over MCP runs on a read-only credential, so a write is refused by the Dash0 API regardless of what the agent tries.
Turning it off
For the whole organization. An admin can switch off Agent0 via MCP under Settings → AI. It is on by default. Turning it off applies to everyone in the organization and in every MCP client, so it is the setting to use if you want a guarantee rather than a per-developer convention. Agent0 disappears from the MCP server; the read-only telemetry tools stay connected and stay free. Only organization admins can change it.
For yourself. There is no per-user setting in Dash0. If you want to keep delegation off in your own editor while the organization leaves it on, deny runTask and waitForTask in your MCP client. Claude Code takes them in permissions.deny; Claude.ai and Cursor have per-tool toggles.
Full detail, including per-client instructions: Delegate to Agent0 via MCP.
This is one way to reach Agent0
MCP is a new door, not a new agent. The same Agent0 answers in Dash0 Chat, runs Automations on a schedule or a trigger, and replies in Slack. An investigation you start from your editor becomes a thread you can open in Dash0, hand to a colleague, or turn into an automation later.
If you have not used Agent0 before, Agent0 Overview is the shorter path than working it out from a tool description.