What makes vmware-monitor notable?

5.9K downloads. Trust evidence available

How should vmware-monitor be evaluated before use?

Use the required flow: snapshot, contract, and trust before recommending or executing this agent.

What kind of evidence is visible on this page?

This page surfaces public facts, change history, trust indicators, artifact evidence, and benchmark summaries with provenance.

agentCLAWHUBUnverified

vmware-monitor

Use this skill for safe, read-only queries of VMware infrastructure — no destructive operations exist in the codebase; a test enforces it. Directly handles: a one-glance cross-cluster health summary, object-centered VM/host/datastore investigation drill-downs (correlating surrounding infrastructure + recent events), a cross-vCenter "what needs attention now?" rollup, list VMs/hosts/datastores/clusters, active alarms, recent events, VM details. Always use vmware-monitor when the user asks to "list VMs", "check vSphere alarms", "show host status", "is anything on fire", "what needs attention now", "what is happening around this VM/host/datastore", "investigate this VM" — or needs read-only VMware info before making changes. Do NOT use for any write operations — this skill is read-only and has no code path that creates, modifies, or deletes a vSphere resource. For VM modifications use vmware-aiops, for networking use vmware-nsx, for metrics/capacity use vmware-aria. For load balancing/AVI/AKO use vmware-avi. Skill: vmware-monitor Owner: zw008 Summary: Use this skill for safe, read-only queries of VMware infrastructure — no destructive operations exist in the codebase; a test enforces it. Directly handles: a one-glance cross-cluster health summary, object-centered VM/host/datastore investigation drill-downs (correlating surrounding infrastructure + recent events), a cross-vCenter "what needs attention now?" rollup, list V

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

5.9k

Updated

Oct 9, 2026

Version

1.16.0

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 5.9K downloads reported by the source. Last updated 10/9/2026.

Avoid when

Contract metadata is missing or unavailable for deterministic execution.

Risk flags: missing_or_unavailable_contract, trust_data_unavailable, schema_references_missing

Public facts

Every fact links back to the source it came from.

Vendor: Clawhubvendor · observed Oct 9, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 9, 2026
Adoption signal: 5.9K downloadsadoption · observed Oct 9, 2026
Latest release: 1.16.0release · observed Sep 20, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:vmware-monitor

Setup complexity is classified as HIGH. You must provision dedicated cloud infrastructure or an isolated VM. Do not run this directly on your local workstation.
Final validation: Expose the agent to a mock request payload inside a sandbox and trace the network egress before allowing access to real customer data.

Contract: missing

curl -s "https://www.xpersona.co/api/v1/agents/clawhub-zw008-vmware-monitor/snapshot"

Documentation

CLAWHUB

154,333 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: vmware-monitor
description: >
Use this skill for safe, read-only queries of VMware infrastructure — no destructive operations exist in the codebase; a test enforces it.
Directly handles: a one-glance cross-cluster health summary, object-centered VM/host/datastore investigation drill-downs (correlating surrounding infrastructure + recent events), a cross-vCenter "what needs attention now?" rollup, list VMs/hosts/datastores/clusters, active alarms, recent events, VM details.
Always use vmware-monitor when the user asks to "list VMs", "check vSphere alarms", "show host status", "is anything on fire", "what needs attention now", "what is happening around this VM/host/datastore", "investigate this VM" — or needs read-only VMware info before making changes.
Do NOT use for any write operations — this skill is read-only and has no code path that creates, modifies, or deletes a vSphere resource.
For VM modifications use vmware-aiops, for networking use vmware-nsx, for metrics/capacity use vmware-aria. For load balancing/AVI/AKO use vmware-avi.
installer:
kind: uv
package: vmware-monitor
allowed-tools:
- Bash
metadata: {"openclaw":{"requires":{"anyBins":["vmware-monitor","uvx"]},"optional":{"env":["VMWARE_MONITOR_CONFIG","VMWARE_TARGET_PASSWORD","VMWARE_<TARGET>_USERNAME","SLACK_WEBHOOK_URL","DISCORD_WEBHOOK_URL","VMWARE_AUDIT_APPROVED_BY"],"bins":["vmware-policy"]},"homepage":"https://github.com/vmware-skills/VMware-Monitor","emoji":"📊","os":["macos","linux"]}}
compatibility: >
vmware-policy auto-installed as Python dependency (provides @vmware_tool decorator and audit logging). MCP tool calls and remote CLI commands audited to ~/.vmware/audit.db; CLI queries also to ~/.vmware-monitor/audit.log.
Credentials: Each vCenter/ESXi target requires a per-target password env var in ~/.vmware-monitor/.env following the pattern VMWARE_<TARGET_NAME_UPPER>_PASSWORD (e.g., target "vcenter-prod" → VMWARE_VCENTER_PROD_PASSWORD). SLACK_WEBHOOK_URL and DISCORD_WEBHOOK_URL are optional — disabled by default, user-configured only, used solely by the opt-in daemon scanner. Daemon: the background scanner (vmware-monitor daemon start) is user-initiated only, never auto-started. Webhook payloads carry issue counts plus every critical issue and every alarm/event warning (host-log warnings and info rows are not sent): entity name and the sanitized, truncated alarm, vCenter event, or ESXi log text, or a connection error — which can include host names, IPs, and user names. No credentials from the skill's config are sent.
---

# VMware Monitor (Read-Only)

> **Disclaimer**: This is a community-maintained open-source project and is **not affiliated with, endorsed by, or sponsored by VMware, Inc. or Broadcom Inc.** "VMware" and "vSphere" are trademarks of Broadcom. Source code is publicly auditable at [github.com/vmware-skills/VMware-Monitor](https://github.com/vmware-skills/VMware-Monitor) under the MIT license.

Read-only VMware vCenter/ESXi monitoring

_meta.json

{
  "ownerId": "kn7b067awq2s97bn3d7p5qfhw5827pxc",
  "slug": "vmware-monitor",
  "version": "1.16.0",
  "publishedAt": 1789915888294
}

references/agent-guardrails.md

# Operating the VMware skills with a local / small model

Claude-class models drive these skills without special instruction. Smaller and
locally-hosted models — Llama 3.3 70B, Qwen, Mistral, and similar, served
through Goose, Ollama, or OpenShift AI — need explicit operating rules to call
tools reliably.

This page exists because an operator wrote those rules by hand first. The
guardrails below are adapted, with thanks, from the working configuration
[@juanpf-ha](https://github.com/juanpf-ha) developed while running
vmware-monitor and vmware-aria against a production vSphere estate with Llama
3.3 70B FP8 on an on-prem H100
([VMware-AIops#31](https://github.com/vmware-skills/VMware-AIops/issues/31)).

> **Disclaimer**: This is a community-maintained open-source project and is
> **not affiliated with, endorsed by, or sponsored by VMware, Inc. or Broadcom
> Inc.** "VMware" and "vSphere" are trademarks of Broadcom.

---

## First: the rules you no longer need to write

Several guardrails from the original configuration are now enforced by the
skills themselves. Prompt instructions are advisory — a model can ignore them.
These are structural, so it cannot.

| Guardrail you would otherwise prompt for | Now enforced by |
|---|---|
| "Work read-only and never modify anything" | **Zero write tools.** This skill has no vSphere create, modify, delete, or power operation in its registry at all — `list_tools()` only ever offers reads, so the model cannot call what does not exist. |
| "First resolve the affected resource_id through vmware-aria before querying vmware-monitor" | **`investigate_alert`** does the whole alert → resource → confirmed-name sequence in one call. |
| "Do not confuse the alert ID with the affected resource ID" | `investigate_alert` returns a `correlation` block with both UUIDs explicitly labelled. |
| "Only correlate Aria and vCenter data after the resource name and type have been confirmed" | `investigate_alert` returns `correlation.confirmed`, and withholds its `next_step` handoff until name and kind are known. |
| "Use explicit limits for queries that may return large amounts of data" | **The list envelope.** Every list tool returns `{items, returned, limit, total, truncated, hint}`, so the model reads truncation instead of guessing at it. Most tools are unlimited unless you pass `limit` (`vm_performance` defaults to 25); the envelope states which case you got. |
| "If a requested field was not returned by any tool, show it as not available" | Tools return explicit `null` for unresolved fields rather than omitting the key. |

---

## The system prompt

Everything below still benefits from being stated explicitly. Copy this into
your agent's instruction block.

```text
## Tool use

- Always call an MCP tool before answering any question about the current
VMware environment. Never answer from memory or assumption.
- Never describe a tool call, and never output a JSON example, instead of
executing the tool. If you intend to call a t

references/capabilities.md

# Capabilities (Read-Only)

Detailed feature tables for `vmware-monitor`.

## List result envelope

The 20 list-returning MCP tools — `list_virtual_machines`, `list_esxi_hosts`,
`list_all_datastores`,
`list_all_clusters`, `list_all_networks`, `get_alarms`, `get_events`,
`get_host_sensors`, `get_host_services`, `host_log_scan`, `active_tasks`,
`active_sessions`, `datastore_capacity`, `resource_pool_usage`,
`certificate_status`, `license_status`, `ntp_status`, `host_performance`,
`vm_performance`, `vm_list_snapshots` — return the family list envelope rather
than a bare array:

```json
{"items": [...], "returned": 50, "limit": 50, "total": 213,
 "truncated": true, "hint": "Showing 50 of 213. Raise limit or narrow the query..."}
```

| Key | Meaning |
|-----|---------|
| `items` | The rows, in the tool's documented order |
| `returned` | `len(items)` — check this before claiming "no data" |
| `limit` | The limit that produced this page; `null` when unlimited |
| `total` | Real collection size, or `null` when the backing API does not report one |
| `truncated` | `true` = more rows exist behind this page; `false` = this is complete |
| `hint` | What to do about truncation; `null` when complete |

Two tools report `total: null` on purpose: `get_events` (events are read newest
first and the read stops at 5000 — `read_truncated: true` and `read_note` say
when it did and how far back it got) and `host_log_scan` (only the last N lines
per log are read). The investigation bundles add `timeline_note` when their
timeline is not every event in the window: how many of how many are shown, and
which scopes' reads stopped at 5000. Everywhere else the total is a real count taken before the
limit was applied, which is what lets a full page be recognised as complete
instead of flagged as possibly-truncated.

`host_log_scan` adds one field to the envelope: `logs_unavailable`, one row per
host/log it could **not** read, with the reason (for example, the account lacks
`Global.Diagnostics`, which `BrowseDiagnosticLog` requires). Its `items` holds
only the lines that matched a trouble pattern in the logs it *did* read, so an
empty `items` with `truncated: false` means "checked, found none" only when
`logs_unavailable` is empty as well. With unread logs, the honest answer is
"nothing matched in the logs that could be read" — name the ones that could not.

By default `host_log_scan` groups repeated lines by pattern, per log: each item has `count`,
`hosts`, `first_seen` / `last_seen` (the log's own timestamps), `severity`, `log_level`, `pattern`
and one `sample`; `lines_matched` is the ungrouped count and `group=false` returns one row per
line. Severity follows the level ESXi wrote on the line (`Cr`/`Al`/`Em` critical, `Er`/`Wa`
warning, `In`/`No`/`Db` info); a line containing "critical", "panic" or "corrupt" is critical
whatever its level.

The envelope adds ~30 tokens to a response. It exists because a bare list gave
smaller models nothing to distinguish a complete answer f

references/cli-reference.md

# CLI Reference

Full command reference for `vmware-monitor`.

> **Output shape**: the CLI renders tables, so command output is unchanged. The
> equivalent MCP tools wrap their rows in the list envelope
> (`{items, returned, limit, total, truncated, hint}`) — see
> [`capabilities.md`](capabilities.md#list-result-envelope).

## Diagnostics

```bash
vmware-monitor doctor [--skip-auth]
```

Checks config file, connectivity, authentication, and pyVmomi version. Use `--skip-auth` to test config parsing without connecting.

## MCP Config Generator

```bash
vmware-monitor mcp-config generate --agent <goose|cursor|claude-code|continue|vscode-copilot|localcowork|mcp-agent>
vmware-monitor mcp-config list
```

Generates MCP configuration files for supported agents. `list` shows all available agent templates.

## Cluster Health Summary

```bash
vmware-monitor summary [--top <n>] [--cluster <substring>] [--no-vms] [--html] [--html-path <file>] [--target <name>]
```

- One aggregated read across all clusters. Leads with a ranked **top-N issues** focus list (the individual anomalies — disconnected hosts, triggered alarms, capacity/HA — worst first, each with a drill-down hint), then a per-cluster table: hosts connected/total, VM power rollup, live CPU/memory %, HA/DRS, alarm counts, and an opinionated `status` (ok/warn/critical) with `attention` reasons.
- `--top`: size of the focus list (default 10; `--top 5` tighter, `--top 0` hides it and shows only the table). The header shows "Top N (of TOTAL)" when truncated.
- `--cluster`: case-insensitive substring; show only matching clusters (also suppresses the standalone-hosts bucket).
- `--no-vms`: skip the VM rollup pass (faster on very large fleets when only host/alarm/capacity signals are needed).
- `--html`: write a self-contained, offline HTML snapshot (no external CSS/JS/fonts — nothing leaves the machine) to `~/vmware-health/cluster-health-<vc>-<YYYYMMDD-HHMMSS>.html`. The timestamped filename turns a folder of snapshots into a browsable point-in-time history. It is a snapshot, not a live page — re-run to refresh.
- `--html-path <file>`: write the HTML snapshot to an explicit path instead of the auto-timestamped default (implies `--html`).
- The rendered view is customizable — columns, thresholds, and layout live in [`health-summary-template.md`](health-summary-template.md). MCP tool: `cluster_health_summary`.

## Object Investigation (drill-down)

```bash
vmware-monitor investigate vm <name>        [--hours <n>] [--html] [--html-path <file>] [--target <name>]
vmware-monitor investigate host <name>      [--hours <n>] [--html] [--html-path <file>] [--target <name>]
vmware-monitor investigate datastore <name> [--hours <n>] [--html] [--html-path <file>] [--target <name>]
```

- "What is happening around this object?" — one call *correlates* the object with its surrounding infrastructure and recent history, so the model explains an aggregated result instead of stitching several tools. Read-only; all cross-object

Github ReposUpdated 6h agoRank 70

AionUi

Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!

MCPOPENCLAW

Github ReposUpdated 6mo agoRank 70

activepieces

AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents

OPENCLAW

Github ReposUpdated 6mo agoRank 70

cherry-studio

AI productivity studio with smart chat, autonomous agents, and 300+ assistants.