Skip to main content
Glama
vmware-skills

vmware-harden

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_drift_events

Read-onlyIdempotent

Identify configuration drift between scans by listing fields that changed since the previous snapshot, with old and new values and detection time. Use to track changes across vSphere targets.

Instructions

[READ] List configuration drift events from the most recent scan snapshot — fields whose values changed since the prior scan of the same target. Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {node_id, field, old_value, new_value, detected_at}. total is the snapshot's exact change-event count, so truncated tells you definitively whether rows were left behind — raise limit when it is true. Returns an empty envelope (total 0) when no snapshot exists or there was no prior snapshot to diff against (a target must be scanned at least twice). Read-only query of the local twin DB (~/.vmware-harden/twin.duckdb); no network calls. Use for change tracking; use list_violations for compliance failures.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows returned, ordered by node_id then field (default 50). There is no offset or cursor here — this tool cannot page, so when the envelope's 'truncated' is true the only way to see the rest is to re-call with a larger limit.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.10.4
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / description
      Added value: +"Maximum rows returned, ordered by node_id then field (default 50). There is no offset or cursor here — this tool cannot page, so when the envelope's 'truncated' is true the only way to see the rest is to re-call with a larger limit."
  2. Changed1 schema field changedv1.8.8
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "_list_drift_events_implOutput",
-  "type": "object"
-}New value: +null
  3. Addedv1.5.29
  4. Removedv1.5.28
  5. First observedv1.5.22

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, but the description adds meaningful behavior beyond them: read-only query of the local twin DB path, no network calls, exact total count semantics, definitive truncated behavior, and empty-envelope behavior when no prior snapshot exists. This is substantial context, not just annotation repetition.

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?

The description is dense but well-ordered: purpose first, then response envelope, item shape, pagination/count semantics, edge cases, storage/network behavior, and usage routing. Every sentence carries load-bearing information; there is no filler or redundancy.

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?

There is no output schema, yet the description fully documents the envelope fields, item fields, total/truncated semantics, empty-envelope conditions, storage location, read-only nature, and routing to list_violations. An agent has everything needed to invoke the tool and interpret its results 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?

The schema covers 'limit' at 100%, but the description adds crucial actionable semantics: ordering by node_id then field, no offset/cursor, and explicit guidance to re-call with a larger limit when truncated is true. This goes well beyond the schema's 'Maximum rows returned' definition.

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 description starts with '[READ] List configuration drift events' and immediately scopes to the most recent scan snapshot, defining drift as fields whose values changed since the prior scan. It also explicitly distinguishes this tool from list_violations, so an agent can tell sibling tools apart 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?

It explicitly says 'Use for change tracking; use list_violations for compliance failures,' naming the sibling alternative and the selection condition. It also states the precondition that a target must be scanned at least twice, which is critical for knowing when this tool will return empty data.

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