How do I use the Cursor agent to investigate Alertmanager alert groups with Tares?

Tares lets Cursor investigate Alertmanager alert groups over MCP: Alertmanager pushes alerts to a Tares source, and Cursor reads them next to the logs, metrics and findings for the same service. You connect Cursor to the Tares MCP endpoint, then ask about the service that alerted. Cursor answers from one correlated, time-ordered timeline instead of from the alert alone.

How it works

Two pieces work together.

• Alertmanager to Tares. The alertmanager connector is a push receiver. You point a receiver’s webhook URL at the source’s ingest endpoint. Alertmanager has already grouped and deduped the alerts, and with send_resolved it also sends the resolved state. Tares fans the alerts array out into one event per alert. The event_type is the alert name, the text is its summary, and the alert labels become Tares labels plus a status of firing or resolved. The full alert, including its fingerprint, stays in the payload.
• Cursor to Tares. Cursor connects to the Tares MCP endpoint and discovers the Tares tools. The read tool returns a correlated timeline across all sources that match a label and value selector, so one call returns the alert, the logs and the metrics for that service together. catalog_list shows what Tares is ingesting, and list_findings shows findings already recorded in a project.

The entity key for an alert is derived from a label, in the order namespace, service, job, instance, unless you declare a primary label. For the alert to line up with your other evidence, your other sources need to carry the same label, such as service. This is how the AI SRE guide keeps one timeline per service.

Set it up

1. Create the Alertmanager source. In the console, go to Sources, then Add source, then Alertmanager alerts, name it and click Create. Or ask a connected agent: “Use tares to create an Alertmanager source and give me the webhook URL.” The source page shows a receiver block with the ingest URL filled in.

2. Add the receiver to your alertmanager.yml and reload Alertmanager:

receivers:
  - name: tares
    webhook_configs:
      - url: http://localhost:8787/ingest/<ingest_key>
        send_resolved: true
route:
  receiver: tares

If Tares has auth on, the sender uses a Bearer Authorization header holding an ingest-scoped API key. Add it to the webhook_configs entry through Alertmanager’s http_config authorization block, which the source page also shows. An open local instance needs no credential.

3. Start Tares and, in a second terminal, the MCP endpoint that Cursor will use:

tares up
tares mcp --transport streamable-http

4. Connect Cursor. Add this to ~/.cursor/mcp.json for all projects, or to .cursor/mcp.json for one project, then approve the server under Settings, then MCP:

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

For a server or Tares Cloud instance, use your own endpoint instead. Tares Cloud shows it in the console under Connect, and that page generates the client command with the endpoint and token filled in. On a secured instance, give the client a scoped API key with the read scope. See Connecting agents for the authentication details.

5. Verify the connection by asking Cursor: “Use tares: what are you ingesting right now?” It should call catalog_list and list your sources, including the Alertmanager one.

6. Send a test alert if you have no live one yet, then open Recent events on the source. Fields shows the alert labels, so you can promote namespace or service to correlate on:

curl -X POST http://localhost:8787/ingest/<ingest_key> \
  -H 'Content-Type: application/json' \
  -d '{"alerts":[{"status":"firing","labels":{"alertname":"PostgresDown","severity":"critical","namespace":"prod"},"annotations":{"summary":"Postgres is down"},"startsAt":"2024-01-01T00:00:00Z"}]}'

7. Ask about the service that alerted, for example: “What happened to prod in the last 15 minutes?” Cursor calls read with that label and answers from the merged timeline.

What you get

• Cursor reads the alert together with the logs, metrics and findings around it, in one time-ordered read.
• Firing and resolved events for each alert sit on the same timeline, so you can ask when an alert started and when it cleared.
• Alertmanager keeps owning grouping, silencing and resolved semantics. Tares records what it pushes and correlates it with your other sources.
• Findings recorded in the project show up in the read, so a later question starts from the earlier conclusion.
• In the console, Reads lists each read as it happens, tagged client = mcp.

When something else fits

• If you want an agent that wakes on its own when an alert arrives, instead of you asking from Cursor, use a trigger. The AI SRE guide walks through it.
• If you do not need Alertmanager’s grouping and silencing and only want fired Prometheus alerts polled, the prometheus_alerts connector is the simpler source.
• If you would rather ask inside Tares than wire up a client, the console’s Ask chat uses the same read tools.

Related