vmware-aria

delete_report

Destructive

Permanently delete a generated report artifact from Aria Operations by report UUID, previewing the blast radius first. Report definitions and schedules remain intact; use list_reports for valid UUIDs.

Instructions

[WRITE] Permanently delete a generated report artifact from Aria Operations. Removes only the generated report instance and its output — the report definition and any schedules remain intact; re-run generate_report to recreate it. Deletion is irreversible and is recorded in the audit log. Returns an error if the report_id does not exist; use list_reports to find valid UUIDs first.

Without confirm=True this only previews: it returns blast_radius (report id, title, status, definition id, completion time, owner) and deletes 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 deletes yet. Refused with confirm=True: a report whose status or definition 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": {
      "report_id": "<report_id>"
    },
    "name": "delete_report"
  }
}

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.
`report_id`	Yes	The report UUID to delete (from generate_report or list_reports).

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 delete. 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 / confirmed / description

Added value: +"Must be True to actually delete. Default False = preview only."

addedInput schema / properties / report_id / description

Added value: +"The report UUID to delete (from generate_report or list_reports)."

addedInput schema / properties / target / description

Added value: +"Aria target name from config; default when omitted."

Changed1 schema field changedv1.5.38Jun 12, 2026

addedInput schema / properties / confirmed

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

Addedv1.5.29May 29, 2026
Removedv1.5.28May 21, 2026
Addedv1.5.18May 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already flag destructive=true and idempotent=false, but the description adds substantial context beyond them: scope of the deletion, irreversibility, audit-log recording, error behavior on unknown report_id, the exact preview payload fields, and the conditions under which confirm=True is refused.

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 deletion scope before operational detail. The confirm paragraph is somewhat repetitive ('do not set confirm=True on your own because the user asked earlier'), but every clause carries an actionable constraint.

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 naming the preview return fields and the error case. For a destructive single-target write with three parameters, nothing an agent needs in order to call it safely is missing.

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

Parameters4/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 goes further by explaining what confirm=False actually returns (blast_radius with report id, title, status, definition id, completion time, owner) and by constraining when the agent may set it. target and report_id add nothing beyond the schema.

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?

Specific verb + resource: 'Permanently delete a generated report artifact from Aria Operations', and it immediately scopes what is NOT deleted (definition, schedules), which separates it from delete_alert_definition and similar siblings.

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?

Explicit routing: use list_reports to obtain valid UUIDs first, and use generate_report to recreate. It also defines the two-step flow — call without confirm to get blast_radius, show the user, then confirm=True only with their explicit decision, with a named refuse condition.

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

Deploy Server