Skip to Content
Tares

Can an AI SRE restart or fix things itself when it finds a cron job that stopped?

By default a Tares agent reads and concludes, and you can let one agent act on a stopped cron job by connecting an external MCP server to it. Without that, the agent reports what it found and does not restart, deploy or ticket anything. Every run records the external tools it called, so you can see what the agent touched.

How it works

A Tares agent that investigates a cron job that stopped starts with a read-only toolset. It reads and concludes, and you decide whether it ever gets more.

  • read returns one correlated timeline for an entity, for example the job and the events around its last run.
  • stats counts events per value of one label, this window against the window before, largest change first. It helps on a busy stream where reading lines would only show the latest few.
  • skill appears when a project the run is for has skills. It loads one skill’s instructions by name, and each run records the skills it loaded.
  • conclude ends the run with the agent’s finding.

Both read and stats cover the sources of the projects the run is for, unless the agent names others with sources. None of these tools can restart a job, deploy a fix or open a ticket. That is the default boundary.

Connecting external tools moves that boundary for that one agent. You register an MCP server, then opt the agent in. At run time the selected servers’ tools are offered to the model alongside read and stats, prefixed by server name, for example github__create_issue. Those tools can act on whatever the server exposes. If the server exposes a tool that restarts a job, the agent can call it. If it exposes nothing like that, the agent cannot.

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.

For the full tool list and the boundary, see Tools and MCP servers. For where this fits in incident work, see AI SRE.

Set it up

  1. Make sure Tares is running. On a local Tares, start it from a terminal:
tares up
  1. Register the server that exposes the actions you want. Open Settings → MCP servers in a project’s Advanced setup. Enter 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. Any project’s agents can then use the server.
  2. Point the auth value at a stored GitHub credential if the server is GitHub’s, so rotating the token in one place rotates the server too.
  3. Under Advanced: extra headers, 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.
  4. Select Test. It connects live and lists the server’s tools, so you can confirm that a restart or fix tool is there before any agent uses it.
  5. Open the agent’s form and, under External tools, pick the registered server. Each selection shows as a removable tag. Only agents you opt in get the server’s tools.
  6. After the next run, open it under Runs and check the external tools it called.

What you get

  • A read-only agent by default. An agent you have not opted in investigates the stopped cron job, concludes, and changes nothing.
  • Action per agent. You choose which agents may touch which servers, so one agent can act while the others stay read-only.
  • A narrow reach. With a server such as GitHub’s, the extra headers limit the tools it offers, and you can make an agent read-only on that server.
  • An audit trail. Each run records the external tools it called, shown on the run under Runs. You can see what the agent touched outside Tares.
  • Runs that survive failures. A server that is down is skipped and logged, and a failed call comes back to the model as an error, so the run still ends with a conclusion.

When something else fits

  • If you want a human to approve every restart, keep the agent on the default read and conclude behavior and act on its finding yourself.
  • If the server you need only speaks stdio, it cannot be registered, because Tares supports streamable-HTTP servers only.
  • If no MCP server exposes the action you need, the agent has no way to perform it, so the finding is where its work ends.

Still stuck? Get help

Last updated on
Quickstart