VMware-Monitor

get_alarms

Read-onlyIdempotent

Retrieve active and triggered alarms across the VMware inventory, flagging stale or cleared alerts so you can investigate real issues and skip false alarms.

Instructions

[READ] Get active/triggered alarms across the VMware inventory.

Returns the list envelope with a real total. Each alarm carries suggested_actions naming the companion skill and tool for remediation, who acknowledged it and when (acknowledged_by / acknowledged_at), and condition_now: holds (live), cleared (vCenter still shows it but its state condition is false now — a stale alarm; see condition_note), or unknown (event/metric-based or unreadable — never guessed). The envelope's stale_alarms counts the cleared ones. An expired-vCenter-license alarm is re-checked against this vCenter's own license assignment. object_label names alarms about the vCenter appliance itself (e.g. "vCenter appliance 192.168.60.16") that sit on the inventory root; entity_name stays the object vmware-aiops resolves. Do not report a cleared alarm as a live problem; do not report an unknown one as resolved. Empty items with truncated False means there genuinely are no active alarms — never report "no data" otherwise.

Use this for the raw alarm list; prefer get_cluster_health_summary when you want alarms folded into a whole-cluster verdict. Then drill into the flagged object with investigate_vm or investigate_host.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`limit`	No	Max alarms to return (None = all).
`target`	No	vCenter/ESXi target from config (default if omitted).

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedv1.9.2Aug 31, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

addedInput schema / properties / limit / description

Added value: +"Max alarms to return (None = all)."

addedInput schema / properties / target / description

Added value: +"vCenter/ESXi target from config (default if omitted)."

changedOutput schema / (root)

Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "get_alarmsOutput",
-  "type": "object"
-}New value: +null

Changed1 schema field changedv1.5.18May 4, 2026

addedInput schema / properties / limit

Added value: +{
+  "anyOf": [
+    {
+      "type": "integer"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Limit"
+}

First observedv0.1.2Mar 8, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/destructive=false, yet the description goes far beyond them: it discloses the response envelope (real ``total``, ``stale_alarms`` count), the three ``condition_now`` states and their meanings, that expired-license alarms are re-checked against real license assignment, and the object_label vs entity_name distinction. It also guards against misreporting (cleared as live, unknown as resolved).

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?

The description is dense but front-loads purpose and routing before the interpretive detail, and given there is no output schema the return-value semantics earn their space. The '[READ]' tag and some parenthetical asides are slightly noisy, but there is little waste.

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 and only two optional params, the description carries the full burden, and it does so: it documents the envelope, the meaning of each alarm field and condition state, and edge cases like empty items with truncated=False. An agent has everything needed to call and interpret it correctly.

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 description coverage is 100% for the two parameters (limit, target), so the schema already carries the semantics. The description says nothing further about limit or target behavior, so it neither adds nor subtracts; baseline 3 applies.

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?

The opening sentence names a specific verb and resource with scope ("Get active/triggered alarms across the VMware inventory"), leaving no ambiguity about what is returned. It explicitly distinguishes itself from the sibling get_cluster_health_summary, so an agent can route correctly 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?

States when to use this tool ("Use this for the raw alarm list"), names the preferred alternative for a different intent (get_cluster_health_summary), and prescribes the follow-up drill-down path via investigate_vm/investigate_host. This is explicit when/when-not/alternatives guidance.

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

get_alarms

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools