Skip to main content
Glama

list_violations

Read-onlyIdempotent

Retrieve compliance violations from the last scan with severity filtering, pagination, and coverage details to show evaluated vs undetermined rules.

Instructions

[READ] List compliance violations recorded by the most recent scan snapshot in the local twin DB (~/.vmware-harden/twin.duckdb). severity (optional string): filter to exactly one of 'critical', 'high', 'medium', 'low', 'info'; omit to return all severities. limit (optional int, default 50): max rows returned; offset (optional int, default 0): rows to skip for paging. 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
limitNo
offsetNo
severityNo
Behavior5/5

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

Annotations provide readOnlyHint, idempotentHint, and destructiveHint, but the description adds crucial behavior: sorting by severity then rule_id, pagination via has_more, the meaning of empty results (undetermined vs passing), and coverage fields. The description confirms read-only local DB query with no network calls and does not contradict annotations.

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 long but each sentence adds operational value: it starts with a [READ] marker, front-loads the core query and envelope, then details edge cases and coverage semantics. No filler or redundant phrasing.

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?

Despite having no output schema and only 3 simple parameters, the description covers return envelope fields, sorting, pagination, empty-scan behavior, coverage semantics, and related tools. It is self-sufficient for an agent to invoke the tool correctly and interpret results.

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 has 0% description coverage, but the description explains severity allowed values ('critical', 'high', 'medium', 'low', 'info'), limit default 50, offset default 0, and how to page by raising offset while has_more is true. It fully compensates for the schema's lack of 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 'List compliance violations recorded by the most recent scan snapshot', which specifies the verb (list), resource (compliance violations), and scope (most recent snapshot in local twin DB). It clearly distinguishes from siblings by pointing to get_remediation and scan_target as related but different actions.

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 guidance says to run scan_target first when no scan exists, and to pass a violation id to get_remediation for a fix plan. It also warns that an empty list is not a compliance verdict and instructs to check coverage before drawing conclusions, effectively defining when to use this tool vs alternatives.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vmware-skills/VMware-Harden'

If you have feedback or need assistance with the MCP directory API, please join our Discord server