Can an AI agent find the cause of crash loops without me running the queries?

Yes, Tares lets an agent investigate crash loops without you running queries, because the agent makes one read call and gets a correlated, time-ordered timeline back. The timeline covers logs, metrics, alerts and findings from every source that matches the entity you name. The agent needs no per-system tools for Prometheus, your logs or your alerting, because Tares does the correlation. Connect Claude Code, Codex, Cursor or any MCP client and ask in plain words.

How it works

Tares ingests your systems through connectors, such as Prometheus, Docker logs, Alertmanager and GitHub, and stores the events with labels. When your agent connects over MCP, it discovers the Tares tools and uses them instead of a separate client for each system.

The tool that matters for crash loops is read:

• You or the agent name an entity with a label and value selector, for example the service that keeps restarting. All labels in the selector must match.
• Tares returns one time-ordered timeline across every source that matches. Logs, metrics, alerts and findings sit side by side in the order they happened.
• The agent can narrow the read with project or sources when it wants only the sources that matter.

The agent never writes a PromQL query, a log filter or an alert lookup. It reads the timeline, sees what changed around the time the restarts began, and reports the likely cause in plain language.

If the agent needs more context, catalog_list and catalog_describe show what Tares is ingesting, including each object’s schema, entities, freshness and sample events. create_trigger wakes the agent when the problem happens again, and remember or record_finding writes back what it learned. The Connecting agents page lists every tool.

The AI SRE guide shows how this fits into a wider setup.

Set it up

1. Start Tares locally.

   tares up

2. Start the MCP server as a second process. The daemon alone does not serve /mcp. On a server or Tares Cloud instance the MCP server is already running, so skip this step.

   tares mcp --transport streamable-http --port 8788 --taresd http://localhost:8787

3. Connect your client. For Claude Code, run this in your terminal:

   claude mcp add --transport http tares http://localhost:8788/mcp

   The Tares plugin path for Claude Code also captures your sessions. Codex, Cursor and other MCP clients use the same endpoint, and the console’s Connect page generates the exact command with the endpoint and token filled in.

4. On a secured instance, pass a credential. Use an API key with the read scope, sent as an Authorization: Bearer header. An open local instance needs no credential.

5. Verify the connection by asking your client:

   Use tares: what are you ingesting right now?

   The client calls catalog_list and answers with your sources, triggers and projects.

6. Ask about the crash loop in your own words, for example: what happened to api-server in the last 15 minutes? The agent calls read and answers from the correlated timeline. In the console, Reads lists each read as it happens, tagged client = mcp.

The agent can only correlate what Tares ingests. Make sure the sources for the failing service, such as its metrics, container logs and alerts, are connected and carry a shared label like the service name.

What you get

• One read, one timeline. Metrics, logs, alerts and findings arrive together and in order, so the agent sees the sequence of events around the crash loop without switching tools.
• No queries from you. The agent picks the entity and reads. You do not open a metrics UI, a log viewer and an alert list to piece things together.
• No per-system tooling. The agent needs one MCP connection to Tares, not a tool for every system you run.
• Visible reads. Every read the agent makes shows up under Reads in the console, so you can check what it looked at.
• Follow-up built in. The agent can create a trigger to be woken on the next occurrence and record a finding so the next investigation starts with what was learned.
• Scoped access. A read key gives the read surface only. A project key limits an agent to one project, where it reads that project and records findings in it.

When something else fits

• If the failing service has no sources connected in Tares, the timeline has nothing to correlate, so connect its metrics, logs and alerts first.
• If you want to explore the data yourself without wiring up an external client, use Ask in the console, a chat loop hosted inside Tares that has the same read tools.

Related