Skip to main content
Glama
vmware-skills

VMware-Monitor

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_events

Read-onlyIdempotent

Sweep vCenter/ESXi events by severity and time window. Use it for inventory-wide reviews of recent critical, warning, or info activity.

Instructions

[READ] Get recent vCenter/ESXi events filtered by severity.

Returns the list envelope, newest first. Up to 5000 events in the window are read; when more matched, read_truncated is true and read_note says how far back the read got — the oldest events were not examined, so narrow hours before concluding nothing happened earlier in the window.

Severity is this skill's own ranking where it has one, and otherwise vCenter's published event catalogue. An event neither can rank comes back with severity "unknown" (it is returned, not filtered out) and is counted in the envelope's unclassified, with classification_note explaining. An empty items alongside a non-zero unclassified does NOT mean the window was quiet — read the note before reporting all-clear.

Use this for an inventory-wide event sweep. When you already know the object, prefer investigate_vm / investigate_host instead: they return the same events correlated with that object's state in one call. ESXi syslog lines are not events — use scan_host_logs for those.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
endNoWindow end, ISO 8601; defaults to now.
hoursNoHow many hours back to query (default 24). Ignored when both start and end are given; with end alone, how far back from end.
startNoWindow start, ISO 8601 (e.g. "2026-09-03T12:00:00Z"; no zone = UTC). Use it to ask about a specific day rather than the last N hours.
targetNovCenter/ESXi target from config (default if omitted).
severityNoMinimum severity: "critical", "warning", or "info".warning
include_routineNoList routine login/logout session events too. By default they are folded and counted in ``routine_folded`` — one local agent's logins can outnumber everything else in a window.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.14.0
    • addedInput schema / properties / end
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Window end, ISO 8601; defaults to now.",
+  "title": "End"
+}
    • changedInput schema / properties / hours / description
      Previous value: -"How many hours back to query (default 24)."New value: +"How many hours back to query (default 24). Ignored when both start and end are given; with end alone, how far back from end."
    • addedInput schema / properties / include_routine
      Added value: +{
+  "default": false,
+  "description": "List routine login/logout session events too. By default they are folded and counted in ``routine_folded`` — one local agent's logins can outnumber everything else in a window.",
+  "title": "Include Routine",
+  "type": "boolean"
+}
    • addedInput schema / properties / start
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "description": "Window start, ISO 8601 (e.g. \"2026-09-03T12:00:00Z\"; no zone = UTC). Use it to ask about a specific day rather than the last N hours.",
+  "title": "Start"
+}
  2. Changed6 schema fields changedv1.9.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / hours / description
      Added value: +"How many hours back to query (default 24)."
    • addedInput schema / properties / severity / description
      Added value: +"Minimum severity: \"critical\", \"warning\", or \"info\"."
    • addedInput schema / properties / severity / enum
      Added value: +[
+  "critical",
+  "warning",
+  "info"
+]
    • 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_eventsOutput",
-  "type": "object"
-}New value: +null
  3. First observedv0.1.2

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare read-only/idempotent/non-destructive, yet the description discloses behavior they cannot: a 5000-event read cap with read_truncated/read_note, severity 'unknown' events returned rather than filtered and counted in 'unclassified', and the trap that empty items with non-zero unclassified is not an all-clear. This is exactly the extra context annotations cannot carry.

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 core purpose and the truncation caveat before the routing advice. It is long, but nearly every sentence encodes a distinct failure mode (truncation, unclassified, routine folding) rather than padding, so length is justified rather than wasteful.

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 return envelope fields (read_truncated, read_note, unclassified, classification_note, routine_folded) and their semantics. For a complex, open-world read tool this is complete enough to call and interpret correctly.

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, but the description adds real semantic guidance beyond the schema: it explains why to narrow 'hours' (truncation means the oldest events were never examined) and how severity ranking works (skill ranking, else vCenter catalogue, else 'unknown' still returned). It does not restate the start/end interaction the schema already covers.

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?

Opens with a specific verb+resource+scope: '[READ] Get recent vCenter/ESXi events filtered by severity.' It also names the siblings it is not (investigate_vm/investigate_host) and the adjacent log tool (scan_host_logs), so an agent can distinguish it without opening schemas.

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 for an inventory-wide event sweep; when the object is known, prefer investigate_vm/investigate_host; ESXi syslog lines are not events, use scan_host_logs. All three conditions (when, when-not, alternative) are stated.

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

Deploy Server

Other Tools