Skip to main content
Glama
vmware-skills

vmware-harden

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

list_violations

Read-onlyIdempotent

Retrieve compliance violations from the latest VMware vSphere scan snapshot with severity filtering and pagination. Check coverage to distinguish evaluated from undetermined rules before claiming compliance.

Instructions

[READ] List compliance violations recorded by the most recent scan snapshot in the local twin DB (~/.vmware-harden/twin.duckdb). Returns an envelope {violations: [...], total, limit, offset, has_more, coverage, note}; each violation is {id, rule_id, node_id, severity, baseline_id, evidence}, sorted severity-descending then rule_id. total is the full matching count (unbounded by limit) so nothing is hidden — page by raising offset while has_more is true. AN EMPTY LIST IS NOT A COMPLIANCE VERDICT: rules whose data no collector gathers are not executed and count as undetermined, never as passing. Read coverage {evaluated, undetermined, total, tracked, complete, undetermined_rules} before summarising — when complete is false, say how many rules were evaluated out of how many and do not call the estate compliant or clean; when tracked is false the snapshot predates coverage tracking, so re-scan rather than assume. note states the same in one sentence, or null when coverage is complete. Empty envelope (total 0) when no scan exists — run scan_target first. Read-only local DB query, no network calls. Pass a row's 'id' to get_remediation for a fix plan.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum rows in this page, must be >= 1 (default 50). It bounds the rows serialized, not the 'total' count, so a small limit never hides how much there is.
offsetNoRows to skip before the page starts, must be >= 0 (default 0 = first page). Page by raising it by 'limit' while the envelope's has_more is true.
severityNoReturn only violations of exactly this severity. One of 'critical', 'high', 'medium', 'low', 'info' — lowercase, matched exactly; anything else is refused with a ValueError naming the five. Omit to return every severity (the default).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.10.4
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / description
      Added value: +"Maximum rows in this page, must be >= 1 (default 50). It bounds the rows serialized, not the 'total' count, so a small limit never hides how much there is."
    • addedInput schema / properties / offset / description
      Added value: +"Rows to skip before the page starts, must be >= 0 (default 0 = first page). Page by raising it by 'limit' while the envelope's has_more is true."
    • addedInput schema / properties / severity / description
      Added value: +"Return only violations of exactly this severity. One of 'critical', 'high', 'medium', 'low', 'info' — lowercase, matched exactly; anything else is refused with a ValueError naming the five. Omit to return every severity (the default)."
  2. Changed3 schema fields changedv1.6.2
    • addedInput schema / properties / limit
      Added value: +{
+  "default": 50,
+  "title": "Limit",
+  "type": "integer"
+}
    • addedInput schema / properties / offset
      Added value: +{
+  "default": 0,
+  "title": "Offset",
+  "type": "integer"
+}
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "_list_violations_implOutput",
-  "type": "object"
-}New value: +null
  3. Addedv1.5.29
  4. Removedv1.5.28
  5. First observedv1.5.22

TDQS

A4.6/5.0
Behavior5/5

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

With readOnlyHint=true and idempotentHint=true, annotations already establish the safe, non-destructive nature, but the description adds substantial context: no network calls, local DuckDB storage, envelope shape, pagination semantics, coverage semantics, and the critical warning that an empty list means undetermined, not compliant. This goes well beyond what annotations provide.

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 long but dense with essential operational warnings, making it justifiably detailed for a tool with tricky semantics (coverage, empty-list meaning). It front-loads the purpose and read-only nature. Minor redundancy with schema-level pagination descriptions keeps it from a 5.

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, so the description compensates by fully specifying the return envelope and violation fields, sorting, pagination, coverage semantics, and the no-scan case. It also covers the prerequisite action and the remediation handoff. The agent has everything needed to call this tool correctly and interpret its results safely.

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%, and the parameter descriptions already explain limit/offset behavior, severity matching, and defaults. The tool description adds little to parameter-level meaning beyond reinforcing pagination with has_more and noting that total is unbounded. Baseline 3 is appropriate since the schema carries the semantic burden.

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 pair: '[READ] List compliance violations recorded by the most recent scan snapshot'. This clearly identifies what is returned and the data source (local twin DB). It distinguishes itself from related tools by referencing get_remediation for follow-up on a row ID.

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?

Explicitly says when to use this tool (to list violations from the latest scan), when not to trust an empty result as a compliance verdict, and what to do first if no scan exists ('run scan_target first'). It also tells the agent to route to get_remediation for a fix plan, providing clear alternative guidance.

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