Skip to main content
Glama
vmware-skills

vmware-harden

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

get_baseline_rules

Read-onlyIdempotent

Retrieve every rule in a compliance baseline, including severity and category, to preview what a scan will check before running it. Read-only and local, ideal for auditing baseline coverage.

Instructions

[READ] Return every rule in one compliance baseline. Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {id, title, severity, category}, where severity is one of 'critical', 'high', 'medium', 'low', 'info'. The whole baseline is returned, so truncated is always false and total is the exact rule count. Read-only — parses local baseline YAML only, no database or network access. Use after list_baselines to preview what scan_target will check; use list_violations for actual scan findings.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
baseline_idYesA baseline id exactly as returned by list_baselines — e.g. 'cis-vmware-esxi-8.0-subset', 'vsphere-stig-v9-subset' — not the baseline's display name. Unknown ids raise a not-found error; re-run list_baselines for the valid set, which includes any YAML you dropped in ~/.vmware-harden/baselines/.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.10.4
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / baseline_id / description
      Added value: +"A baseline id exactly as returned by list_baselines — e.g. 'cis-vmware-esxi-8.0-subset', 'vsphere-stig-v9-subset' — not the baseline's display name. Unknown ids raise a not-found error; re-run list_baselines for the valid set, which includes any YAML you dropped in ~/.vmware-harden/baselines/."
  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": "_get_baseline_rules_implOutput",
-  "type": "object"
-}New value: +null
  3. Addedv1.5.29
  4. Removedv1.5.28
  5. First observedv1.5.22

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses that the tool parses local baseline YAML only with no database or network access, always returns the whole baseline, and guarantees truncated is false and total is exact. It also documents severity values and the error behavior for unknown ids in the schema description, giving the agent a strong behavioral model.

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?

Every sentence adds value: the main action, the exact return envelope, the severity vocabulary, the guaranteed truncation behavior, the read-only/local nature, and the sibling routing. The description is slightly longer than minimal, but the extra details are necessary because there is no output schema.

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?

For a one-parameter read-only tool with no output schema, the description explains the return shape, field semantics, severity values, uniqueness guarantees, input requirements, error behavior, and when to use sibling tools. Nothing needed for correct selection or invocation appears to be missing.

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 baseline_id property in the schema already provides rich guidance: exact format, examples, the caution against display names, and behavior on unknown ids. The tool description reinforces the single-baseline scope, but the schema already carries the parameter-semantics burden, so the baseline of 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 description opens with '[READ] Return every rule in one compliance baseline,' which names a specific verb and resource and clarifies the tool returns the full rule set for a single baseline. This clearly distinguishes it from siblings like list_baselines and list_violations by stating the scope and object of the operation.

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?

'Use after list_baselines to preview what scan_target will check; use list_violations for actual scan findings' explicitly tells the agent when to call this tool and which sibling to use for a different purpose. The baseline_id schema description also reinforces the relationship to list_baselines and warns against using display names.

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