Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

list_anomalies

Read-onlyIdempotent

Rank VMs by total active anomalies (symptoms, events, violations) to identify the worst offenders, or scope to a specific resource for its anomaly count.

Instructions

[READ] Report per-resource anomaly counts (System Attributes|total_alarms metric).

The suite-api does not expose the UI's anomalous-metrics list; this is the Total Anomalies metric — active symptoms, events and DT violations on the object and its children. With resource_id: that resource's count. Without: ranks every VM in the environment and returns the worst limit of them. For root cause, follow up with list_alerts(resource_id=...).

limit bounds the answer, not the scan — raising it does not widen the search, and lowering it does not hide worse objects. The whole inventory is read either way, in bulk pages, because the ranking metric is not a field the appliance can sort on.

Returns a paginated envelope: flagged rows worst-first under items, plus returned, limit, total, truncated, hint, scanned (objects examined), vm_total and scan_complete. Only flagged VMs are returned, so a short list is not by itself proof the environment is clean. When scan_complete is true, total is the number of anomalous objects found and truncated is exact; when it is false the scan hit its cap, total is the environment's VM count, and a note says the ranking is partial — an unexamined object could outrank every row shown.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum ranked rows to return (1–500). Default 50. Rejected, not clamped, when out of range.
targetNoAria target name from config; default when omitted.
resource_idNoOptional resource UUID to scope to a single resource.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / description
      Added value: +"Maximum ranked rows to return (1–500). Default 50. Rejected, not clamped, when out of range."
    • addedInput schema / properties / resource_id / description
      Added value: +"Optional resource UUID to scope to a single resource."
    • addedInput schema / properties / target / description
      Added value: +"Aria target name from config; default when omitted."
  2. Changed1 schema field changedv1.8.9
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "list_anomaliesOutput",
-  "type": "object"
-}New value: +null
  3. Addedv1.5.29
  4. Removedv1.5.28
  5. First observedv1.3.2

TDQS

A5/5.0
Behavior5/5

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

Even though annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, the description adds critical behavioral detail: limit bounds the answer but not the scan, the whole inventory is read in bulk pages, and scan_complete/truncated semantics reveal when results may be partial. It goes well beyond annotation coverage and explains real-world edge cases like a short list not proving a clean environment.

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

Conciseness5/5

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

Though lengthy, the description is tightly structured with a READ marker, context, parameter behavior, and output envelope explanation. Every sentence contributes necessary operational knowledge, and the most important purpose statement is front-loaded. The length is justified by the tool's non-obvious scan/ranking behavior.

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?

With no output schema, the description fully documents the paginated response envelope and the meaning of each field, including returned, limit, total, truncated, hint, scanned, vm_total, and scan_complete. It also covers the partial-scan caveat and explains why a short result list is not sufficient evidence of cleanliness. Nothing critical is missing for an agent to call this correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description substantially enriches parameter meaning. It explains the resource_id branching behavior, clarifies that limit is a result bound rather than a scan bound, and notes that out-of-range limits are rejected. This adds genuine semantic value beyond the schema's already-good descriptions.

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?

Description states a precise verb and resource: 'Report per-resource anomaly counts' via the Total Anomalies metric. It clearly distinguishes itself from the UI's anomalous-metrics list and from list_alerts, which is for root cause follow-up. An agent can tell exactly what this tool computes.

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?

The description gives explicit mode-based guidance: with resource_id it returns that resource's count, without it ranks all VMs and returns the worst limit. It also names list_alerts as the follow-up tool for root cause, providing an alternative routing decision. This is strong, actionable usage guidance.

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

Install Server

Other Tools