Can an AI SRE restart or fix things itself when it finds high latency?

Yes, Tares lets an AI SRE act on high latency, but only when you connect an external MCP server to that agent. By default a Tares agent reads your sources, finds the cause and concludes, and it does not restart, deploy or ticket anything. You choose which servers each agent may use, and every run records the tools it called.

How it works

A Tares agent investigating high latency starts with built-in tools that read your data:

• read returns one correlated timeline for an entity, such as the service that slowed down.
• stats counts per value of one label, this window against the window before, largest change first. It suits a busy stream where reading lines would only show the latest few.
• skill loads one skill’s instructions by name. The agent gets it when a project the run is for has skills, and each run records the skills it loaded.
• conclude ends the run with its finding.

Both read and stats cover the sources of the projects the run is for, unless the agent names others with sources. With only these tools, the agent can tell you which service, deploy or label value moved with the latency, and it stops there. It does not change anything in your systems.

Connecting external tools moves that boundary for one agent. Tools from an MCP server can act on whatever the server exposes, so what an agent can do depends on the servers you register and the agents you opt in. Other agents stay read-only.

At run time the selected servers’ tools are offered to the model next to read and stats, prefixed by server name, for example github__create_issue. Three guardrails apply:

• A tool result is capped at 8,000 characters, so a verbose server cannot crowd out the evidence.
• A server that is down when the run starts is skipped and logged, and the run continues with the remaining tools.
• A failed call is returned to the model as an error to reason about.

The tools and MCP servers page covers the full boundary. For the wider picture of how agents watch your systems, see AI SRE.

Set it up

1. Start Tares if it is not running.

tares up

2. Register the server. Open Settings → MCP servers in a project’s Advanced setup. Give it a name and a streamable-HTTP URL. Stdio servers are not supported. Any project’s agents can then use the server.
3. Add authentication if the server needs it. The optional auth header value is stored as a secret and never shown again. It can also point at a stored GitHub credential, so rotating the token in one place rotates the server too.
4. Limit what the server offers. Under Advanced: extra headers you can add non-secret headers sent with every request. GitHub’s hosted MCP server takes X-MCP-Toolsets: repos,pull_requests to limit the tools it offers and X-MCP-Readonly: true for a read-only agent.
5. Select Test. Tares connects live and lists the server’s tools, so you see what an agent could call before you opt anyone in.
6. Opt the agent in. On the agent’s form, under External tools, pick any registered server. Each selection shows as a removable tag, and you can remove it later to return that agent to read-only.
7. After a latency investigation, open the run under Runs and check which external tools it called.

The agent only gets the actions your server exposes. If you want an agent that restarts a service, register a server that offers a restart tool and opt that agent in. If you want an agent that files a ticket, a server with an issue tool does that.

What you get

• A read-only default. An agent that investigates high latency reads and concludes without touching your systems.
• Per-agent control. You decide which servers each agent may touch, so one agent can act while the others only read.
• An audit trail. Each run records the external tools it called, shown on the run under Runs. That is the record of what an agent touched outside Tares.
• Resilient runs. A server outage does not stop a run, and a failed call becomes an error the model can reason about.
• Focused evidence. The 8,000 character cap on tool results keeps the evidence from being crowded out.

When something else fits

If you want findings only, keep the default and read the agent’s conclusion yourself, with no external servers registered. If you want a read-only agent that still uses an external server such as GitHub’s hosted one, add the X-MCP-Readonly: true header. If a fix needs a human decision, let the agent conclude and act on the finding yourself.

Related