How do I use the Cursor agent to investigate PagerDuty incidents with Tares?

Tares lets Cursor investigate a PagerDuty incident by reading the alert together with the logs, metrics and findings for the same service. PagerDuty reaches Tares through the webhook connector and a vendor setup, and Cursor connects over MCP. You ask Cursor about the service that alerted, and it answers from one correlated timeline.

How it works

Tares has no connector of its own for PagerDuty today, so the incident events arrive through the webhook connector. The Cursor side is the MCP read surface described on the connecting agents page.

• PagerDuty sends a v3 webhook subscription delivery to a Tares ingest URL. The body is a JSON object with an event key that holds event_type (for example incident.triggered), resource_type, occurred_at and data.
• A Tares webhook source stores the payload lossless and maps fields into labels. Labels use one-level dotted fields such as event.event_type. The event type is fixed on the source, because event_type_field reads top-level fields only.
• Give the PagerDuty source a label that your logs, metrics and alerts sources also carry, such as service. A read matches a label and value selector across all sources, so the incident lands on the same timeline as the evidence.
• Cursor connects to the Tares MCP endpoint and calls the read tool with that selector. It gets a time-ordered timeline across every matching source.

The pattern is the pull half of an AI SRE: you or your agent investigate on demand from the same evidence a trigger would hand to an agent.

Set it up

1. Create the PagerDuty source. Scope the PagerDuty subscription to one service, then declare a constant service label for it, so it matches your other sources. Add a second label for the PagerDuty event type. Use Sources → Add source → webhook in the console, or this YAML:

- name: pagerduty
  connector: webhook
  config:
    event_type: incident
    labels:
      - { name: service, const: checkout, primary: true }
      - { name: event, field: event.event_type }

Copy the ingest endpoint from the source page.

2. In PagerDuty, create a v3 webhook subscription, in the console or with the Webhook Subscriptions API. Set its delivery URL to the Tares ingest URL. Choose events such as incident.triggered and incident.resolved, and pick the scope: account, team or service.

3. If Tares has auth on, add a custom header to the delivery method. It is an Authorization header with a Bearer value that holds an ingest-scoped API key. Do not set a signature scheme on the source. PagerDuty signs with a v1= prefixed header that hmac_sha256 does not accept, so the Bearer header is the credential.

4. Trigger a test incident. On the source page, check Recent events for the delivery and Fields for the payload fields that arrive.

5. Start the MCP endpoint if Tares runs locally. On a server or Tares Cloud instance it is already running.

tares mcp --transport streamable-http

6. Add Tares to ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project), then approve the server under Settings → MCP:

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

For a server or Tares Cloud instance, use your own endpoint. On a secured instance the MCP surface needs a credential, preferably an API key with the read scope. The console’s Connect page generates the exact client commands with the endpoint and token filled in.

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

8. Investigate. When PagerDuty pages you for checkout, ask: “Use tares: what happened to checkout in the last 15 minutes?” Cursor calls read with service set to checkout.

What you get

• One timeline per service, with the PagerDuty incident events next to logs, metrics and other alerts on one clock.
• Answers in Cursor that tie the page to the evidence around it, instead of an alert with no context.
• Findings carried forward. If your key allows project tools, Cursor can call list_findings to see earlier conclusions and record_finding to leave its own, so the next investigation starts from them.
• Resolution visible in the same place, because incident.resolved deliveries land on the same timeline when you subscribe to them.
• A trail you can audit. In the console, Reads lists each read as it happens, tagged client = mcp.

When something else fits

• If you want an agent woken the moment an incident arrives, instead of asking Cursor yourself, add a trigger and a Tares agent. The AI SRE guide walks through that push half.
• If you use Claude Code or Codex rather than Cursor, the connecting agents page has the matching setup for each client.
• If your alerts come from Prometheus or Alertmanager, use their own connectors instead of routing them through PagerDuty.

Related