Can an AI SRE restart or fix things itself when it finds a disk filling up?

Yes, Tares can let an agent act on a disk filling up, once you connect an external MCP server whose tools do the fixing. By default a Tares agent reads and concludes and does not act. Connecting a server moves that boundary for that one agent, and every run records the external tools it called.

How it works

A Tares agent starts with two tools, both routed through the same Tares read path and both covering the sources of the projects its run is for:

• read returns one correlated timeline for an entity.
• stats counts per value of one label, this window against the window before, largest change first.

When a disk filling up shows in your sources, the agent uses these to gather evidence and then ends its run with the conclude tool. Out of the box it does not restart, deploy or ticket anything.

To let an agent act, you connect external tools. Tools from an MCP server can act on whatever the server exposes, so what the agent can do about a disk depends on the tools of the server you register. You choose per agent which servers it may touch. Other agents stay on read and conclude.

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. The run continues with the tools that remain.
• A failed call is returned to the model as an error to reason about.

For the wider picture of how agents watch and investigate, see AI SRE.

Set it up

1. Register the server. In a project’s Advanced setup, open Settings → MCP servers and add a name, a streamable-HTTP URL and an optional auth header. The header value is stored as a secret and never shown again. Stdio servers are not supported. Any project’s agents can then use the server.
2. Store the auth value as a GitHub credential if you prefer. The auth value can point at a stored GitHub credential with credential:github/<name>, so rotating the token in one place rotates the server too.
3. Add non-secret headers if the server needs them. Under Advanced: extra headers you add headers sent with every request. GitHub’s hosted MCP server, for example, takes these two:

X-MCP-Toolsets: repos,pull_requests
X-MCP-Readonly: true

The first limits the tools the server offers. The second makes the agent read-only on that server. 4. Click Test. It connects live and lists the server’s tools, so you see exactly what an agent could call before you opt anything in. 5. Opt the agent in. On the agent’s form, under External tools, pick any registered server. Each selection shows as a removable tag. Remove the tag and the agent goes back to reading and concluding. 6. Check the runs. Open Runs and look at the run. It shows the external tools the agent called.

The Tools and MCP servers page covers the same steps and the guardrails in one place.

What you get

• An agent that investigates a disk filling up with read and stats and ends with a conclusion, with no change to your systems.
• A per-agent choice to let it act. Only the agents you opt in can call a server’s tools, and they can call only the tools that server exposes.
• Narrow access when you want it. Extra headers such as X-MCP-Readonly: true keep an agent read-only on a server that supports it.
• An audit trail. Each run records the external tools it called, shown on the run under Runs, so you can see what an agent touched outside Tares.
• Safe failure behavior. A down server is skipped, a failed call becomes an error the model reasons about, and a tool result never exceeds 8,000 characters.
• Secret handling you can rotate. Auth values are stored as secrets, and a stored GitHub credential rotates every server that points at it.

When something else fits

• Keep an agent on the default if you want a disk-filling finding to be a conclusion that a person acts on. The agent reads, concludes and does not touch anything.
• If you need the agent to act only through a server with narrow tools, register that server and opt in only the agents that need it.
• If a server is stdio only, it cannot be registered, because Tares supports streamable-HTTP servers.

Related