Skip to main content
Glama

scan_target

Read-onlyIdempotent

Assess vCenter compliance against a selected baseline via a read-only scan, then save results locally for review and drift tracking.

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetYesA vCenter target name as configured in vmware-aiops (~/.vmware-aiops/config.yaml) — this skill has no target config of its own and borrows aiops' connection manager. Use the config's target key, not a hostname or IP.
baselineNoA baseline id from list_baselines (default 'cis-vmware-esxi-8.0-subset'). Which baseline you pick decides which rules can reach a verdict at all: a baseline whose rules need data no collector gathers reports them as undetermined, which is why coverage must be read alongside the violation count.cis-vmware-esxi-8.0-subset

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.10.4
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / baseline / description
      Added value: +"A baseline id from list_baselines (default 'cis-vmware-esxi-8.0-subset'). Which baseline you pick decides which rules can reach a verdict at all: a baseline whose rules need data no collector gathers reports them as undetermined, which is why coverage must be read alongside the violation count."
    • addedInput schema / properties / target / description
      Added value: +"A vCenter target name as configured in vmware-aiops (~/.vmware-aiops/config.yaml) — this skill has no target config of its own and borrows aiops' connection manager. Use the config's target key, not a hostname or IP."
  2. Addedv1.5.29
  3. Removedv1.5.28
  4. First observedv1.5.22

TDQS

A3.9/5.0
Behavior1/5

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

The description is extremely transparent about side effects: it writes a new snapshot, violations, and drift events to twin.duckdb, makes only read-only vCenter calls, and warns about coverage interpretation. However, it contradicts the annotations: readOnlyHint=true and idempotentHint=true despite 'writes a new snapshot' and persistent local writes, so the required contradiction penalty applies.

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 dense and front-loaded: the main purpose and '[READ]' safety cue come first, followed by side-effect details, return shape, interpretation caveat, and timing warning. Every sentence adds operational value; none is filler.

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?

With no output schema, the description still specifies the exact summary fields, names follow-up tools, discloses local persistence and duration, and explains how to interpret violations/coverage. This is complete for an agent to decide to call it and to interpret its result correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the description adds interpretive meaning beyond the schema, especially for baseline: the choice of baseline determines which rules can reach a verdict, and coverage must be read alongside violations. The target parameter's 'config key, not hostname' rule is already in the schema, so the description doesn't need to repeat it.

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 names a specific action ('Run a compliance scan of a vCenter target against a baseline and persist results locally') and a clear resource (vCenter target). It also distinguishes itself from sibling list/get tools by stating that follow-up details are inspected via list_violations and list_drift_events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives explicit context: target must be a configured vmware-aiops key, baseline should come from list_baselines, and results are inspected with the list_violations/list_drift_events siblings. It does not explicitly state 'use X instead of this' because no sibling performs scans, but the when-to-use context is clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.