Can an AI SRE restart or fix things itself when it finds slow database queries?

Tares agents read and conclude by default, so they do not restart or fix anything on their own. You can let one agent act by connecting an external MCP server whose tools do the work. Every run records the external tools it called, so you can see what the agent touched.

How it works

A Tares agent starts with two read tools, read and stats. Both cover the sources of the projects its run is for, unless the agent names others with sources.

• read returns one correlated timeline for an entity. For slow database queries, that is the evidence from your sources gathered in one place.
• stats counts each 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.
• When a project has skills, the agent also gets the skill tool, which loads one skill’s instructions by name. Each run records the skills it loaded.
• The agent ends a run with the conclude tool.

That is the default boundary: the agent reads and concludes, and it does not restart, deploy or ticket anything. Connecting external tools moves that boundary for one agent. Tools from an MCP server can act on whatever the server exposes, so a restart or a fix is possible only if a server you connect offers a tool for it. You decide per agent which servers it may touch.

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. The Tools and MCP servers page covers the full detail. For the wider picture of how agents investigate problems, see AI SRE.

Three guardrails apply to external tools:

• 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.

Set it up

1. Start Tares if it is not running yet.

   tares up

2. Register the MCP server under Settings → MCP servers in a project’s Advanced setup. Any project’s agents can then use it. Give it a name, a streamable-HTTP URL and, if the server needs one, an auth header. The header value is stored as a secret and never shown again. Stdio servers are not supported.

3. Limit what the server offers where it supports that. Under Advanced: extra headers you add non-secret headers sent with every request. GitHub’s hosted MCP server, for example, takes X-MCP-Toolsets: repos,pull_requests to limit its tools and X-MCP-Readonly: true for a read-only agent.

4. Select Test. Tares connects live and lists the server’s tools, so you see what the agent could call before you let it.

5. Open the agent’s form and pick the registered server under External tools. Each selection shows as a removable tag. Only agents you opt in get that server’s tools.

6. After a run, open it under Runs to see which external tools it called.

What you get

• An agent that stays read-only until you decide otherwise. Nothing acts on your database unless you connect a server that can.
• Control per agent. One agent can use a server while the others keep reading and concluding.
• An audit trail. Each run lists the external tools it called, shown on the run under Runs, so you know what an agent touched outside Tares.
• Credentials kept as secrets. The auth header value is stored as a secret and is never shown again.
• A run that survives a bad server. If the server is down, the run continues with the tools that remain.

When something else fits

• Keep the default if you want a person to make the final call. The agent reads the evidence, concludes, and you act yourself.
• Choose a read-only setup when a server offers a read-only option, such as the X-MCP-Readonly: true header on GitHub’s hosted server.
• A restart or fix needs an MCP server that exposes that action over streamable HTTP. Tares has no restart tool of its own.

Related