How do I use the Cursor agent to investigate CloudWatch alarms with Tares?

Tares lets Cursor read a CloudWatch alarm together with the logs, metrics and deploys around it. CloudWatch alarms reach Tares through the webhook connector and an EventBridge setup, and Cursor connects over MCP. Ask Cursor about the service that alerted and it answers from one correlated timeline instead of from the alarm alone.

How it works

Tares has no connector of its own for CloudWatch today. The alarm arrives through the webhook connector with a vendor setup in EventBridge.

• An EventBridge rule on the default event bus matches source aws.cloudwatch and detail-type CloudWatch Alarm State Change. Its target is an API destination whose endpoint is your Tares ingest URL, with method POST.
• EventBridge posts the event as a JSON body. The webhook connector parses it whatever the Content-Type and stores it lossless. source and detail-type are top-level fields. detail.alarmName works as a one-level dotted label.
• The webhook source carries a service label with a constant value, marked primary. Every alarm that arrives on that source’s ingest URL is tagged with that service, so use one source for each service whose alarms you send. Your logs and metrics sources carry the same service label, which is how the alarm and the evidence sit on one timeline.
• Cursor connects to the Tares MCP endpoint. It calls the read tool with a selector such as service set to checkout, and gets a time-ordered timeline across all matching sources.

This is the pull half of an AI SRE: you ask, and the agent reads the evidence on demand.

Set it up

1. Create the webhook source in the console under Sources, Add source, webhook, or ask a connected agent to create it. Keep the alarm label secondary and make the service label primary:

- name: cloudwatch-alarms
  connector: webhook
  config:
    event_type_field: detail-type
    labels:
      - { name: service, const: checkout, primary: true }
      - { name: alarm, field: detail.alarmName }

2. Copy the ingest endpoint from the source page. It must be public HTTPS for EventBridge to reach it.
3. In EventBridge, create an API destination with that endpoint and the POST method. Give it a connection, which EventBridge requires on every API destination. Use API key authorization with header name Authorization and the value Bearer followed by an ingest-scoped API key. The key only matters when Tares has auth on.
4. Create a rule on the default event bus that matches source aws.cloudwatch and detail-type CloudWatch Alarm State Change, and set the API destination as its target. If you want detail.state.value as a label or in text_template, flatten it with an input transformer on the rule target, because it is two levels deep.
5. Start the MCP endpoint next to a local Tares:

tares up
tares mcp

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

On a server or Tares Cloud instance, use your own endpoint instead. The console’s Connect page shows it. On a secured instance, Cursor needs a credential. Prefer a scoped API key with the read scope, sent as an Authorization Bearer header. See Connecting agents for the details.

7. Verify in Cursor. Ask “Use tares: what are you ingesting right now?” The client calls catalog_list and lists your sources, including the CloudWatch webhook source.
8. Investigate. When an alarm fires, ask “Use tares: what happened to checkout in the last 15 minutes?”

What you get

• The alarm state change sits on the service’s timeline next to its logs, metrics and deploys, merged on one clock.
• Cursor answers from that single read. It sees what fired, since when, and what changed around it, without you pasting evidence into the chat.
• The raw EventBridge event stays intact in the lossless payload, including detail.state.reason. The alarm label lets you tell which alarm fired.
• Findings recorded in the project show up in later reads, so a follow-up 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 woken the moment an alarm arrives instead of asking Cursor yourself, add a trigger on the source and see the AI SRE guide.
• CloudWatch alarm actions that publish to SNS do not fit this route. An SNS HTTPS subscription cannot send a custom header, and its SubscriptionConfirmation message would never be confirmed. Use the EventBridge route above, or OTLP or http_poll against an API.
• If you use Claude Code or Codex instead of Cursor, the same MCP endpoint works. Only the client command differs, as shown in Connecting agents.

Related