How do I use the Cursor agent to investigate Datadog monitors with Tares?

Tares lets Cursor investigate a Datadog monitor by reading the alert together with the logs, metrics and findings for the same service. Datadog posts each alert to a Tares webhook source, Cursor connects over MCP, and you ask about the service that alerted. Tares has no connector of its own for Datadog today, so the alerts reach it through the webhook connector and a Datadog webhook setup.

How it works

• Datadog sends the alert to Tares through its Webhooks integration. You write the JSON payload yourself from Datadog variables such as $ALERT_ID, $EVENT_MSG and $LINK, so you choose the shape.
• Tares stores the payload lossless in a webhook source. Labels map payload fields into the event. One label is primary, and it is the one that ties the alert to a service.
• Sources that carry the same label value, such as your logs and metrics for that service, line up on one timeline.
• Cursor connects to the Tares MCP endpoint and discovers the Tares tools. When you ask about a service, it calls read, which returns a time-ordered timeline across all sources that match a label selector. The Datadog alert appears next to the evidence around it.

The payload must stay flat. event_type_field and text_template read top-level fields only, so put the fields you need at the top of the JSON you write in Datadog.

Set it up

1. Start Tares and the MCP server. Locally, the daemon alone does not serve /mcp, so run the MCP server as a second process in another shell.

   tares up
   tares mcp

2. Create a webhook source for Datadog. In the console, go to Sources → Add source → webhook, or ask a connected agent to create it. Declare a label for each payload field you want to correlate on, and mark one primary. Use the label name your other sources use for the service, so the timelines join up. The source page then shows the ingest endpoint to copy.

   - name: datadog-monitors
     connector: webhook
     config:
       labels:
         - { name: service, field: service, primary: true }

3. Point Datadog at it.

   • In Datadog, open the Webhooks integration and add a webhook whose URL is the Tares ingest URL.
   • Write the payload as flat JSON from Datadog variables, and include a top-level field that carries the service name so the label has something to read.
   • If Tares has auth on, add custom headers as JSON with an Authorization Bearer header holding an ingest-scoped API key. On an open instance you do not need it.
   • Put @webhook- followed by your webhook’s name in the monitor message so the monitor calls it.

4. Connect Cursor. Add this 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, replace the URL with yours. A secured instance also needs a credential, and a scoped API key with the read scope is the one to prefer.

5. Verify. Ask Cursor:

   Use tares: what are you ingesting right now?

   It should call catalog_list and list your sources, including the Datadog one. Then trigger a monitor and check Recent events on the source page. Fields shows which payload fields arrive and how often.

6. Investigate. Name the service from the alert:

   Use tares: Datadog alerted on checkout. What happened to checkout in the last 15 minutes?

   Cursor reads the timeline for that service and answers from the alert and the evidence around it. In the console, Reads lists each read as it happens, tagged client = mcp.

What you get

• Datadog monitor alerts land on the same per-service timeline as your other sources, so Cursor sees them in context instead of as an isolated message.
• One question to Cursor returns a single correlated answer, so you do not have to open a different tool for each signal.
• The alert is stored lossless, so fields you did not label are still there when Cursor reads it.
• Your Datadog monitors stay where they are. Datadog keeps owning the alerting, and Tares ingests what fires.
• If an agent records a finding on the service, the next question you ask Cursor reads that finding along with the evidence.

When something else fits

• If you want an agent to wake on its own when a monitor fires, instead of you asking, add a trigger and an agent. The AI SRE guide walks through that setup.
• If you use Claude Code, Codex or another client instead of Cursor, the same endpoint works. See Connecting agents for the per-client setup.
• If your payload needs fields nested deeper than one level in labels or text templates, flatten it in the Datadog payload first.

Related