Skip to main content
Everything an AI agent needs to investigate your project already exists: the REST API exposes your traces, event timelines, logs, and metrics over typed endpoints, and llms.txt documents all of it — including safe agent workflows — in a single brief written for LLMs. Give an agent those two things plus a server key, and you can ask questions like:
  • “Explain why traces in the past 24 hours have been having more errors.”
  • “Which attribute values are most correlated with failed traces this week?”
  • “Summarize what happened in trace 317 and where it went wrong.”
  • “Are bridge transfers failing more often on one chain than the others?”
  • “Compare error rates before and after yesterday’s 14:00 UTC deploy.”
There’s no special AI product surface to enable — no plugin, no separate endpoint. Any agent that can make HTTP requests (Claude Code, a custom agent built on the Claude API, an internal incident bot) can do this today.

​
Why this works well

The REST API was designed with agent use in mind, and a few properties make investigations reliable rather than hallucinated:
  • Discoverable field universe. The discovery catalogues list every tag, attribute key, service, and metric your project has actually used, so an agent composes filters and PromQL from real names instead of guessing.
  • Exact counts in one request. GET /v1/traces with page_size=1 returns a top-level total — an exact count. An agent can compare error volume across time windows with a handful of cheap requests before drilling into anything. (/v1/logs/stats does the same for logs.)
  • Complete evidence per trace. GET /v1/traces/{trace_id}/events returns the full, ordered event timeline, so conclusions about why a trace failed are grounded in the actual events, not the summary alone.
  • Safe by default. All queries are GET; the only mutations in the API are dashboard and alert management, and llms.txt instructs agents never to send PUT or DELETE without explicit authorization. Constrain your agent’s tool to GET and it can’t mutate anything.

​
The three ingredients

1

A server key

Create one in the dashboard under your project’s API keys — see Authentication. Use a dedicated key per agent so you can revoke it independently.
2

The llms.txt brief

https://api.mirador.org/llms.txt documents the auth scheme, every endpoint, the filter grammar, pagination, and response shapes — enough for an agent to query Mirador with no other context. Paste it into the agent’s context or let the agent fetch it (the endpoint requires no key).
3

A question

Ask in plain English. Good questions name a time window and an outcome — “why are errors up in the last 24 hours” gives the agent a concrete comparison to run.

​
What an investigation looks like

For a question like “why are errors up in the past 24 hours?”, a well-briefed agent typically:
  1. Establishes the baseline — counts error traces in the last 24 hours vs. the prior 24 hours using filter=severity="error" with since/until windows.
  2. Discovers the field universe — lists tags and attribute keys so the next step slices along dimensions that actually exist.
  3. Finds the concentration — re-counts errors sliced by tag, attribute value, or trace name to find where the increase is concentrated (one chain? one country? one flow?).
  4. Drills into evidence — pulls the full event timelines of a few representative failing traces and reads the actual error events.
  5. Reports with pointers — summarizes the likely cause and links the specific trace_ids to investigate in the dashboard.
The worked investigation walks through this end to end with real requests and responses.

​
Next Steps

Connect an agent

Wire up Claude Code, a custom agent, or an incident bot

Worked investigation

“Why are errors up in the past 24 hours?” — step by step

REST API overview

The endpoints agents query

Authentication

Create and manage server keys