investigate_alert
Resolve an Aria alert to its affected resource in one call: fetch the alert, correlate its resource UUID, confirm the resource name and kind, and suggest the next monitoring step.
Instructions
[READ] Resolve one alert to its affected resource in a single call — use this instead of chaining get_alert then get_resource by hand.
Does the whole alert-to-object correlation server-side: fetches the alert, reads its resourceId, fetches that resource, and confirms the resource name and kind before suggesting anything downstream.
Returns five always-present keys: alert (Aria's values verbatim, with its contributing symptoms named as in get_alert, including the object each is on and get_alert's GET /symptoms cost — check each symptom's definition_lookup and symptom_definitions_note), resource (or null), correlation (both UUIDs labelled, plus confirmed name, kind and a confirmed flag), next_step (which vmware-monitor tool to call next, or null; for a "not receiving data" alert, the list_resources call that names the objects that stopped reporting), and warnings (empty on success).
Gotchas: alert_id is the alert UUID from list_alerts, NOT the resource UUID — mixing them up is the most common error here; the correlation block labels each. An unresolvable resource degrades to a warning plus nulls rather than an error, so the alert is never lost. Never match the resource against vCenter inventory unless correlation.confirmed is true.
Tool call template
Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.
{
"id": 1,
"jsonrpc": "2.0",
"method": "tools/call",
"params": {
"arguments": {
"alert_id": "<alert_id>"
},
"name": "investigate_alert"
}
}Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| target | No | Aria target name from config; default when omitted. | |
| alert_id | Yes | The alert UUID from list_alerts (not the resource UUID). |