Can an AI SRE restart or fix things itself when it finds 5xx errors on an API?

Yes, Tares agents can act on 5xx errors on an API once you connect an external MCP server whose tools do the restart or the fix. By default a Tares agent reads and concludes and does not act, so you choose per agent which servers it may touch. Every run records the external tools it called, so you can see what the agent did outside Tares.

How it works

A Tares agent starts with two built-in tools, read and stats. read returns one correlated timeline for an entity, for example the API service whose 5xx errors you care about. stats counts per value of one label, this window against the window before, largest change first, which helps on a busy stream where reading lines would only show the latest few. The agent ends its run with the conclude tool.

That is the default boundary: the agent reads and concludes, with no restarting, deploying or ticketing. Connecting external tools moves that boundary for that one agent. Tools from an MCP server can act on whatever the server exposes, so what your agent can do about a 5xx spike depends on the server you register.

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 respond, see AI SRE.

Set it up

1. Open Settings → MCP servers in a project’s Advanced setup and register the server that can act on your API. Give it a name and a streamable-HTTP URL. Stdio servers are not supported. Any project’s agents can then use the server.
2. Add an auth header if the server needs one. The value is stored as a secret and never shown again. The value can also point at a stored GitHub credential, so rotating the token in one place rotates the server too.
3. Add non-secret headers under Advanced: extra headers if you want to narrow what the server offers. GitHub’s hosted MCP server takes these two, one to limit its tools and one for a read-only agent:

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

4. Select Test. Tares connects live and lists the server’s tools, so you can confirm the 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 these tools.
6. After the agent runs, open the run under Runs to see which external tools it called. Details of the built-in tools and the MCP setup are on the Tools and MCP servers page.

What you get

• An agent that can go from finding 5xx errors to acting on them, using the tools of the MCP servers you chose, instead of stopping at a conclusion.
• Control per agent. One agent can read and conclude only, while another gets a server with tools that act.
• An audit trail. Each run records the external tools it called, shown on the run under Runs, so you know what an agent touched outside Tares.
• Stable runs. An unreachable server is skipped and logged, and the agent carries on with read, stats and any other tools it has.
• Secrets handled in one place. Auth values are stored as secrets, and a stored GitHub credential can be rotated once for every server that uses it.

When something else fits

• Keep the default if you want an agent that only investigates 5xx errors. It reads, correlates and concludes, and a person decides what to do next.
• Use a read-only setup if a server supports it. For GitHub’s hosted MCP server, the X-MCP-Readonly: true header gives you a read-only agent.
• If the server you need only runs over stdio, it cannot be registered today, so the agent cannot act through it.

Related