How many reads and turns does an AI SRE need per diagnosis with one MCP server per tool compared with Tares?
On the same incident with the same agent, one MCP server per tool took 6 reads and 3 turns per diagnosis, while Tares took 1 read and 2 turns. When a Tares trigger pushed the timeline to the agent, the agent needed 0 reads. These are single runs, so treat them as directional. The code is in the tares-cookbooks repository.
How it works
The comparison holds the incident and the agent constant and changes only how the agent gets production data.
- One MCP server per tool. The agent makes one call per tool. It pulls from each server itself, so a diagnosis took 6 reads and 3 turns.
- Tares, agent reads. One read returns the correlated timeline of a service across every connected source. The diagnosis took 1 read and 2 turns.
- Tares, trigger pushes. A trigger fires on a condition and wakes the agent with the timeline already in hand. The diagnosis took 0 reads.
The numbers in one table:
| Setup | Reads per diagnosis | Turns per diagnosis |
|---|---|---|
| One MCP server per tool | 6 | 3 |
| Tares, agent reads the timeline | 1 | 2 |
| Tares, trigger pushes the timeline | 0 | not reported |
The gap comes from the shape of the data access. With a server per tool, evidence stays split across tools and the agent collects it call by call. With Tares, your metrics, logs, alerts and deploys land in one local DuckDB file, so a single read returns them together. A trigger can also wake your own agent service over a webhook or wake a Tares agent, and the agent then writes its finding back onto the timeline where the next investigation starts.
Each result is a single run. Use the figures to see the direction of the difference, not as a benchmark with error bars.
Set it up
To see the difference on your own incident, build the Tares side and compare it with what you run today. The full walkthrough is in Build an AI SRE, which has you cause an incident and watch an agent diagnose it.
-
Install the CLI.
uv tool install tares # or: brew install glassflow/tap/tares -
Start Tares locally.
tares up -
Connect the tools that hold your signals, such as metrics, logs, alerts and deploys. Keep the alerting you already run.
-
Add a trigger so an alert wakes the agent. Your own agent, such as Claude Code, works with any MCP client, and a Tares agent works too.
-
Cause the incident and count the reads and turns the agent needs. Do the same with one MCP server per tool and compare.
-
For the exact incident, agent and measurement code behind the figures above, open the tares-cookbooks repository and look in
cookbooks/01_sre_incident_response.
The side by side table in AI SRE compared shows how the two approaches differ beyond reads and turns, including wake-up on a condition and findings written back.
What you get
- Fewer reads. One correlated read replaces a call to each tool. With a trigger, the agent starts with the timeline and reads nothing.
- Fewer turns. The Tares run took 2 turns where the per-tool setup took 3.
- A wake-up on a condition. A trigger starts the agent the moment an alert fires, instead of the agent pulling from each server.
- Findings that persist. The agent writes its finding back onto the timeline, so the next investigation starts from it.
- Local operation. Tares runs on your machine or your server, in one local DuckDB file, and it is open source under MIT.
Keep the limits in mind. Each figure comes from one run on one incident with one agent, so it points a direction and does not predict your numbers.
When something else fits
- If your data sits in one or two tools that already ship an MCP server and you investigate by hand when paged, one MCP server per tool is the least setup. You give up the single correlated read and the wake-up on a condition.
- If most of your telemetry lives in one observability vendor and its data covers your incidents, that vendor’s built-in AI works inside data it already holds and needs no system for you to host.
- Tares earns its place when evidence is spread across several tools, or when you want your own agent to read the same timeline a built-in agent writes to.