Can an AI agent find the cause of slow database queries without me running the queries?

Yes, Tares lets an AI agent trace the cause of slow database queries from one correlated timeline, so you do not run the queries yourself. The agent calls the Tares read tool and gets metrics, logs, alerts and changes for the same entity in a single time-ordered answer. Tares does the correlation, so the agent needs no per-system tools for your database, your metrics store or your log store.

How it works

Tares ingests your sources into one place and joins them by label. The agent works through MCP and needs only the Tares tools:

• One read, all sources. The read tool returns a correlated, time-ordered timeline across all sources that match a {label: value} selector. The match is a strict AND, and project or sources narrows it.
• Signals together. Logs, metrics, alerts and findings arrive in the same answer. If you also ingest commits and pull requests from a GitHub repo, they can sit on the same timeline, so a change shows up next to the symptom it may have caused.
• No per-system tools. The agent does not need a Prometheus client, a log query tool or an alert API. Each source has a connector that Tares polls or receives from, and the agent only reads the result.
• Orientation tools. catalog_list lists your sources, triggers and projects. catalog_describe shows one object’s schema, entities, freshness and sample events. Inside a project, stats compares counts per label value for this window against the one before, and list_findings shows what agents already recorded.

This is the pattern behind AI SRE: you connect the sources once, and any agent can ask what happened to an entity. Because the agent only reads, a key with the read scope is enough.

Set it up

1. Add the sources that describe your database and the service in front of it. For example, Prometheus metrics, container logs, Prometheus alerts and GitHub commits. Give them matching labels, such as a shared service label, so one selector pulls them together.
2. Start the MCP endpoint. On your own machine, start Tares and then the MCP server as a second process. On a server or Tares Cloud instance the MCP server is already running, so there is nothing to start.

tares up
tares mcp --transport streamable-http

3. Connect your agent. Claude Code, Codex, Cursor and any MCP client can connect. In Cursor, add this to .cursor/mcp.json, then approve the server under Settings → MCP:

{
  "mcpServers": {
    "tares": {
      "url": "http://localhost:8788/mcp"
    }
  }
}

For Claude Code, the Tares plugin is the default path. It wires the MCP read-back and session capture together. See Connecting agents (MCP) for the Claude Code, Codex and generic client commands. 4. Add a credential on a secured instance. Use a scoped API key with the read scope and send it as an Authorization: Bearer header. On an open local instance no credential is needed. 5. Verify. Ask your client: “Use tares: what are you ingesting right now?” It should call catalog_list and answer with your sources, triggers and projects. 6. Ask the real question. For example: “Queries on the orders service got slow in the last 30 minutes. What changed, and what else moved at the same time?” The agent reads the timeline and answers from it. In the console, Reads lists each read as it happens, tagged client = mcp.

What you get

• A cause you can check. The agent answers from events in the timeline, so you can open the same read and see what it saw.
• No manual querying. You do not run queries, copy logs into a chat or switch between dashboards. The agent asks Tares and gets the correlated view.
• One setup for every agent. Claude Code, Codex, Cursor and your own agents all use the same MCP tools. Adding a source later makes it available to all of them.
• Follow-up that stays with the work. The agent can use create_trigger to be woken if the slowdown happens again. It can use remember to write back what it found, and inside a project record_finding stores the result for the next reader, human or agent.
• Scoped access. A project key limits an agent to one project, so it reads that project and records findings in it and nothing else.

When something else fits

• The timeline holds what your sources capture. If the cause sits in data none of them ingest, such as a query plan, add a source for it or give the agent a tool of its own for that system.
• If you want to explore without wiring up an external client, use Ask in the console, which runs the same read tools inside Tares.
• If you want an agent that wakes on a trigger and writes a finding on its own, use a Tares agent instead of an external one.

Related