Can an AI agent read alerts from Prometheus through Tares and explain them?

Yes, an AI agent connected to Tares over MCP can read Prometheus alerts and explain them from one correlated timeline. Tares polls the alerts your Prometheus rules have fired, and the agent asks Tares, not Prometheus. The agent needs no connector of its own for the alert vendor.

How it works

Two pieces work together: the prometheus_alerts connector brings alerts in, and the MCP server lets your agent read them back.

• Ingest. The Prometheus alerts connector polls the alerts endpoint of your Prometheus server every 30 seconds by default. It reads the alerts your alerting rules have already fired. Prometheus decides what counts as an alert. No Alertmanager and no PromQL are needed.
• State tracking. Tares tracks state across polls. Each alert fires once, and it re-emits only when its state changes. When an alert disappears, Tares emits a resolved event instead of repeating a copy on every tick.
• What an alert looks like. Each alert becomes one event. The event_type is the alert name, the text is its summary, and the alert’s labels become Tares labels. Tares adds a synthetic state label with the value firing, pending or resolved.
• Read-back. Your agent connects to Tares as an MCP client. Its read tool returns a correlated, time-ordered timeline across all sources that match a label selector, so an alert appears next to the logs, metrics and findings for the same entity. The catalog_describe tool shows one object’s schema, entities, freshness and sample events.

The agent talks to Tares only. Tares holds the connection to Prometheus, with its URL and any bearer token or basic-auth credentials. So the agent client needs no Prometheus connector, no alert-vendor SDK and no credentials for Prometheus. See Connecting agents (MCP) for the full tool list and client setup.

Set it up

1. Install and start Tares locally.

   uv tool install tares
   tares up

2. Add the alerts source. Use Sources, Add source, Prometheus alerts in the console, or ask a connected agent to ingest the firing alerts from your Prometheus. The YAML form looks like this:

   - name: alerts
     connector: prometheus_alerts
     poll: 30s
     config:
       url: http://localhost:9090
       severities: critical,warning   # blank = all
       labels:
         - { name: severity, field: labels.severity, primary: true }
         - { name: state, field: state }

   Set include_pending to also ingest alerts that are still waiting out their for: duration. Add bearer_token, or username and password, if your Prometheus needs authentication.

3. Start the MCP server. Locally, the daemon alone does not serve /mcp, so run this as a second process:

   tares mcp --transport streamable-http --port 8788 --taresd http://localhost:8787

4. Connect your client. For Claude Code:

   claude mcp add --transport http tares http://localhost:8788/mcp

   On a secured instance, pass an API key with the read scope as an Authorization: Bearer header. Codex, Cursor and other MCP clients connect with the same endpoint.

5. Verify. Ask your client: “Use tares: what are you ingesting right now?” It calls catalog_list and lists your sources, including alerts. Then ask it to explain the firing alerts. In the console, Reads lists each read as it happens, tagged client = mcp.

6. Promote more labels. Discover proposes only the labels guaranteed to be present, severity and state. Once real alerts have been ingested, open the Fields tab and add labels such as namespace or service. Your agent can then correlate on them.

What you get

• An agent that explains an alert in context. It reads the alert name, the summary text, the severity, the state and your own labels, and it sees the surrounding logs, metrics and findings in the same time-ordered timeline.
• One event per active alert, plus a resolved event when it clears, so the agent can tell what is still firing from what has recovered.
• No repeated copies of the same alert on every poll, because Tares emits again only on a state change.
• A single connection for the client. Whether the agent is Claude Code, Codex, Cursor or your own MCP client, it speaks to Tares, and Tares handles Prometheus.
• Control over what the agent sees. You can limit ingestion by severity, and use a scoped read API key on a secured instance.
• An optional next step: the agent can call create_trigger to be woken when an alert fires again, and remember to write back what it found.

When something else fits

• You want a metric value, not an alert. The alerts connector reads only what your rules have fired. To bring in metrics you pick by name or label, with no PromQL, use the Prometheus metrics connector instead.
• Alertmanager already routes your alerts. If you want the alerts Alertmanager sends, point a webhook receiver at a Tares ingest URL and use the Alertmanager connector. That path is push, not poll.
• You need to ask in a chat, not in an external client. The console includes Ask, an in-app agent with the same read tools, so you can explore alerts without wiring up a client.
• Prometheus is unreachable from Tares. The connector polls your server, so Tares needs a reachable Prometheus URL with alerting rules configured.

Related