How do I use the Cursor agent to investigate alerts from Prometheus with Tares?

Tares lets Cursor investigate Prometheus alerts by connecting it over MCP to a correlated timeline that holds the alerts next to your metrics and logs. You poll Prometheus with the prometheus_alerts connector, add the Tares MCP server to Cursor, and ask about the service that alerted. Cursor reads the alert together with the evidence around it in one answer.

How it works

• The prometheus_alerts connector polls the alerts endpoint of your Prometheus server every 30 seconds by default. Prometheus keeps deciding what counts as an alert. Tares ingests what it fired. You need no Alertmanager and no PromQL.
• Each alert becomes one event. The event type is the alert name, the text is its summary, and the alert labels become Tares labels. A synthetic state label is firing, pending or resolved.
• Tares tracks state across polls. Each alert fires once, re-emits only when its state changes, and produces a resolved event when it clears.
• The Tares MCP server gives Cursor the read tools. The read tool returns a time-ordered timeline across all sources that match a label and value selector, such as the service that alerted. Metrics, logs and alerts that carry the same label come back merged on one clock.
• Findings recorded for that service appear on the same timeline, so Cursor starts from earlier conclusions. See Connecting agents (MCP) for the full tool list and Build an AI SRE for the end-to-end setup around it.

Set it up

1. Start Tares on your machine.

   tares up

2. Add the alerts source. In the console, go to Sources, Add source, Prometheus alerts, enter the Prometheus URL and click Discover. Or use this source definition. Blank severities means all. Details are on the Prometheus alerts connector page.

   - 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 }

3. Promote the per-alert labels. Discover proposes only severity and state, because those are always present. Once real alerts have been ingested, open the source’s Fields tab and add labels such as service or namespace. Use the same service label on your metrics and log sources so one timeline per service forms.

4. Start the MCP server in a second shell. The daemon alone does not serve the MCP endpoint.

   tares mcp

   The endpoint is http://127.0.0.1:8788/mcp.

5. Add the server to Cursor. Edit ~/.cursor/mcp.json for all projects, or .cursor/mcp.json for one project. Then approve the server under Settings, MCP.

   {
     "mcpServers": {
       "tares": {
         "url": "http://localhost:8788/mcp"
       }
     }
   }

   On a server or Tares Cloud instance, use your own endpoint instead. A secured instance requires a credential, and a scoped API key with the read scope is the preferred one. The console’s Connect page generates the exact client configuration with the endpoint and token filled in.

6. Verify the connection. Ask Cursor:

   Use tares: what are you ingesting right now?

   Cursor calls catalog_list and answers with your sources, triggers and projects. Your alerts source is in that list.

7. Investigate. Name the service that alerted:

   Use tares: what happened to api-server in the last 15 minutes?

   Cursor calls read with the selector service equal to api-server and answers from the merged timeline.

What you get

• One answer that holds the alert, the metric that tripped it and the log lines around it, instead of three tools to check by hand.
• Alert history that is easy to follow. A firing alert appears once, and a resolved event marks when it cleared, so Cursor can tell you when it started and when it ended.
• A starting point from earlier work. Findings recorded on the service’s timeline are part of the read, so each investigation builds on the last.
• Visibility into what Cursor asked. The console’s Reads view lists each read as it happens, tagged client = mcp.
• Narrow access when you want it. For an agent that should work inside one project only, a project key reads that project and records findings in it, and nothing else.

To go from interactive questions to automatic ones, the AI SRE guide shows a trigger that wakes an agent when an alert event arrives.

When something else fits

• If you want an investigation to start without anyone asking, use a trigger that wakes an agent on the alert event. The AI SRE guide covers this.
• If your alerts already route through Alertmanager and you want Tares to receive them from there, use the alertmanager connector instead of polling Prometheus.
• If you prefer a chat inside Tares and no external client, the in-app Ask agent in the console uses the same read tools.

Related