Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault

No arguments

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_baselinesA

[READ] List all available compliance baselines: built-in (CIS ESXi 8.0, vSphere SCG v8, PCI-DSS 4.0, DengBao 2.0 L3, EU NIS2, BSI ITGS) plus any user-imported YAML baselines from ~/.vmware-harden/baselines/. Takes no parameters. Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {id, name, version, applies_to (node types covered), rule_count}, and entries that fail to load carry an 'error' field instead. Every baseline is listed, so truncated is always false and total is exact — this is the complete set, not a page of it. Read-only — parses local baseline YAML only, no database or network access. Start here to discover valid baseline ids for get_baseline_rules and scan_target.

list_violationsA

[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.

get_remediationA

[READ] Fetch the persisted LLM-generated remediation Suggestion for one violation. Returns {summary, execution_plan.steps, impact_prediction (workload impact, maintenance window, rollback plan), confidence (0.0-1.0), human_review_required}, or None when no advisor suggestion has been generated for that violation yet (generate one via the vmware-harden CLI advisor). Read-only lookup in the local twin DB (~/.vmware-harden/twin.duckdb); no network calls and nothing is executed — suggestions are advisory only.

list_drift_eventsA

[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.

get_baseline_rulesA

[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.

scan_targetA

[READ] Run a compliance scan of a vCenter target against a baseline and persist results locally. Makes read-only vCenter API calls (inventory collection only — never modifies VMware infrastructure) and writes a new snapshot, violations, and drift events (vs the prior scan of the same target) to the local twin DB (~/.vmware-harden/twin.duckdb). Returns summary counts {snapshot_id, target, baseline, hosts, violations, coverage, note}; inspect details via list_violations and list_drift_events. violations is meaningful only together with coverage: rules whose data no collector gathers are not executed and count as undetermined, never as passing, so violations=0 is not by itself evidence of compliance. When coverage.complete is false, report how many rules were evaluated out of how many instead of calling the estate compliant. May take minutes on large inventories.

list_stig_controlsA

[READ] List the built-in vSphere 9 / VCF 9 STIG-aligned host baseline's controls (baseline id 'vsphere-stig-v9-subset'). Returns the family list envelope {items, returned, limit, total, truncated, hint}; each item is {id, title, severity (one of critical/high/medium/low/info), category, advanced_setting} where advanced_setting names the ESXi advanced setting the control governs (e.g. 'Security.AccountLockFailures'). total is the exact catalog size, so truncated tells you definitively whether to raise offset. Read-only — parses local baseline YAML only, no database, network, or compliance API (VCF Operations ACC/SPM has none). Use scan_target with baseline 'vsphere-stig-v9-subset' to evaluate these controls against a target; use describe_stig_content_sync for how this catalog is kept in sync.

describe_stig_content_syncA

[READ] Explain harden's vSphere STIG integration and route continuous enforcement. Takes no parameters. Returns {compliance_api_available (always false — VCF Operations ACC/SPM exposes no public compliance REST API), why_no_api, content_sources (the open-source MITRE InSpec/Cinc STIG repos harden syncs against), mechanism (how upstream controls become harden rules), routing_note (use VCF Operations SPM/ACC UI for fleet-wide continuous enforcement; harden is the API-scriptable point-in-time scanner), importer_status}. Read-only, local static content — no database, network, or API call. Call this before assuming a compliance endpoint exists; use list_stig_controls to see the actual controls.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.4/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have clearly distinct purposes: baselines, rules, scans, violations, drift, remediation, and STIG sync are separate concerns. The main ambiguity is between get_baseline_rules and list_stig_controls, since both can return rule/control lists for baselines, though the STIG-specific tool adds advanced_setting detail.

Naming Consistency4/5

The naming pattern is mostly verb_noun and readable, with list_* for collections and get_* for specific lookups. Minor inconsistency exists between list_baselines and get_baseline_rules, plus scan_target and describe_stig_content_sync break the simple list/get prefix pattern, but the style is consistent enough to predict behavior.

Tool Count5/5

Eight tools is well-scoped for a compliance scanning and remediation advisory server. Each tool covers a distinct part of the workflow from baseline discovery, rule preview, scanning, violation review, drift tracking, and remediation lookup without feeling padded or redundant.

Completeness4/5

The core lifecycle is covered: discover baselines, inspect rules, scan a target, list violations, inspect drift, and fetch remediation. Minor gaps exist—there is no tool to manage scan history, list targets, or generate remediation suggestions directly—but agents can work around these via the CLI or by treating this as a read-only reporting surface.

Maintenance

ActivityActive
ResponsivenessResponsive