vmware-aria

acknowledge_alert

Idempotent

Acknowledge active alerts by taking ownership without cancelling them. Preview the blast radius first, then confirm to assign the alert to the API user.

Instructions

[WRITE] Acknowledge an active alert by taking ownership (does not cancel it).

The suite-api has no dedicated "acknowledge" action; this maps to POST /alerts?action=takeownership, assigning the alert to the API user (control state ASSIGNED). The alert remains active until cancelled. Use this when you want to own the alert without closing it; cancel_alert closes it for good.

Without confirm=True this only previews: it returns blast_radius (alert id, definition, criticality, status, control state, and the resource it is on) and changes nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen what it changes yet. Refused with confirm=True: a cancelled alert, and an alert whose status or resource cannot be read.

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

Input Schema

Name	Required	Description
`target`	No	Aria target name from config; default when omitted.
`confirm`	No	False (default) returns the blast radius and changes nothing. True applies it.
`alert_id`	Yes	The alert UUID to acknowledge.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv2.4.2Nov 1, 2026

removedInput schema / properties / confirmed

Removed value: -{
-  "anyOf": [
-    {
-      "type": "boolean"
-    },
-    {
-      "type": "null"
-    }
-  ],
-  "default": null,
-  "description": "Deprecated alias for confirm; removed in the next minor release. confirmed=False holds even when confirm=True.",
-  "title": "Confirmed"
-}

Changed5 schema fields changedv1.16.0Sep 19, 2026

addedInput schema / properties / confirm

Added value: +{
+  "default": false,
+  "description": "False (default) returns the blast radius and changes nothing. True applies it.",
+  "title": "Confirm",
+  "type": "boolean"
+}

addedInput schema / properties / confirmed / anyOf

Added value: +[
+  {
+    "type": "boolean"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / confirmed / default
```
Previous value: -falseNew value: +null
```

changedInput schema / properties / confirmed / description

Previous value: -"Must be True to actually acknowledge. Default False = preview only."New value: +"Deprecated alias for confirm; removed in the next minor release. confirmed=False holds even when confirm=True."

removedInput schema / properties / confirmed / type
```
Removed value: -"boolean"
```

Changed4 schema fields changedv1.10.0Sep 8, 2026
- addedInput schema / additionalProperties
```
Added value: +false
```
- addedInput schema / properties / alert_id / description
```
Added value: +"The alert UUID to acknowledge."
```
- addedInput schema / properties / confirmed / description
```
Added value: +"Must be True to actually acknowledge. Default False = preview only."
```
- addedInput schema / properties / target / description
```
Added value: +"Aria target name from config; default when omitted."
```
Addedv1.5.29May 29, 2026
Removedv1.5.28May 21, 2026

Changed1 schema field changedv1.5.18May 5, 2026

addedInput schema / properties / confirmed

Added value: +{
+  "default": false,
+  "title": "Confirmed",
+  "type": "boolean"
+}

First observedv1.3.2Mar 27, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=false, destructiveHint=false, idempotentHint=true, but the description adds far more: the confirm-gated two-phase preview, exactly what blast_radius returns, what is mutated (control state ASSIGNED, ownership assigned to the API user), what is not (alert stays active), and the cases it will refuse. This is substantial added context beyond structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the [WRITE] tag and the core action, then the API mapping, then the confirm workflow — a sensible order. There is mild redundancy between 'The alert remains active until cancelled' and the later 'own the alert without closing it', but overall every paragraph carries decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by enumerating the blast_radius return fields. Combined with the confirm workflow, refusal cases, and sibling routing, an agent has everything needed to call this correctly and safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description reinforces confirm semantics in workflow terms (preview vs. apply) but largely restates the schema's own confirm description, and says nothing about the 'target' parameter beyond what the schema documents.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Acknowledge an active alert by taking ownership'), names the underlying API operation, and explicitly contrasts with the sibling cancel_alert ('this when you want to own the alert without closing it; cancel_alert closes it for good'). An agent can distinguish it from every other alert-related sibling without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use ('own the alert without closing it'), when-not ('does not cancel it'), the named alternative (cancel_alert), and a hard rule about the confirm workflow including the anti-pattern of setting confirm=True on the user's behalf. Refusal conditions (cancelled alert, unreadable status/resource) are also stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server