What makes xcpng-aiops notable?

1.3K downloads. Trust evidence available

How should xcpng-aiops 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

xcpng-aiops

Use this skill whenever the user needs to operate an XCP-ng virtualization fleet through Xen Orchestra — a one-shot fleet health overview; VMs (list/get/RRD stats), hosts, pools, storage repositories (SRs) and VDIs, VM snapshots, backup jobs and run logs, XO tasks; four RCA analyses (VM health, SR usage, backup-job failures, pool patch & HA posture); and governed writes (VM start/stop/reboot/migrate, snapshot create/delete/revert, SR rescan). Always use this skill for "xcp-ng vm", "xen orchestra", "xo backup failed", "sr full", "orphaned vdi", "xcp-ng snapshot", "migrate vm to another host", "xcp-ng patches", or "pool HA" when the context is explicitly XCP-ng / Xen Orchestra / a Xen-based fleet. Do NOT use when the target is not an XCP-ng fleet managed by Xen Orchestra — other hypervisors (Do NOT use for Proxmox VE — use proxmox-aiops), NAS/storage appliances, backup software suites, container clusters, and network devices are out of scope (negative routing hints only). Common XCP-ng-via-XO operations with a built-in governance harness (audit, policy, token budget, undo, risk-tiers).

OpenClaw

View on ClawHub Homepage

Rank

Safety

Downloads

1.3k

Updated

Oct 10, 2026

Version

0.8.4

Source

CLAWHUB

About

What it does, and when to use it.

Capability contract not published. No trust telemetry is available yet. 1.3K downloads reported by the source. Last updated 10/10/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 10, 2026
Protocol compatibility: OpenClawcompatibility · observed Oct 10, 2026
Adoption signal: 1.3K downloadsadoption · observed Oct 10, 2026
Latest release: 0.8.4release · observed Sep 16, 2026
Handshake status: UNKNOWNsecurity

Install and run

Setup complexity: low.

clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:xcpng-aiops

Install using `clawhub skill install s171xgnmqse0nqvgqvqnaq5f9183kyre:xcpng-aiops` in an isolated environment before connecting it to live workloads.
No published capability contract is available yet, so validate auth and request/response behavior manually.
Review the upstream CLAWHUB listing at https://clawhub.ai/zw008/xcpng-aiops before using production credentials.

Contract: missing

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

Documentation

CLAWHUB

148,795 characters of source documentation, loaded on request.

Extracted files

5 files captured from the source.

SKILL.md

---
name: xcpng-aiops
slug: xcpng-aiops
displayName: "XCP-ng AIops"
summary: "Governed XCP-ng ops via Xen Orchestra — 29 MCP tools with audit, budget, undo guards."
license: MIT
homepage: https://github.com/AIops-tools/XCPng-AIops
tags: [aiops, mcp, governance, xcpng]
description: >
  Use this skill whenever the user needs to operate an XCP-ng virtualization fleet through Xen Orchestra — a one-shot fleet health overview; VMs (list/get/RRD stats), hosts, pools, storage repositories (SRs) and VDIs, VM snapshots, backup jobs and run logs, XO tasks; four RCA analyses (VM health, SR usage, backup-job failures, pool patch & HA posture); and governed writes (VM start/stop/reboot/migrate, snapshot create/delete/revert, SR rescan).
  Always use this skill for "xcp-ng vm", "xen orchestra", "xo backup failed", "sr full", "orphaned vdi", "xcp-ng snapshot", "migrate vm to another host", "xcp-ng patches", or "pool HA" when the context is explicitly XCP-ng / Xen Orchestra / a Xen-based fleet.
  Do NOT use when the target is not an XCP-ng fleet managed by Xen Orchestra — other hypervisors (Do NOT use for Proxmox VE — use proxmox-aiops), NAS/storage appliances, backup software suites, container clusters, and network devices are out of scope (negative routing hints only).
  Common XCP-ng-via-XO operations with a built-in governance harness (audit, policy, token budget, undo, risk-tiers).
installer:
  kind: uv
  package: xcpng-aiops
argument-hint: "[vm/sr/snapshot uuid or describe your XCP-ng task]"
allowed-tools:
  - Bash
metadata: {"openclaw":{"requires":{"anyBins":["xcpng-aiops","uvx"]},"optional":{"env":["XCPNG_AIOPS_CONFIG","XCPNG_AIOPS_MASTER_PASSWORD"]},"homepage":"https://github.com/AIops-tools/XCPng-AIops","emoji":"🖥️","os":["macos","linux"]}}
compatibility: >
  Standalone, self-governed XCP-ng operations via Xen Orchestra's REST API /rest/v0. REQUIRES a Xen Orchestra instance (XO from sources or the Xen Orchestra Appliance, 5.x) — XO is the management plane; direct per-host XAPI access is out of scope for v0.1. The governance harness (audit, policy, token/runaway budget, undo, risk-tiers) is bundled in the package — no external skill-family dependency.
  All write operations are audited to a local SQLite DB under ~/.xcpng-aiops/ (relocatable via XCPNG_AIOPS_HOME).
  Credentials: Each XO target's personal authentication token is stored ENCRYPTED in ~/.xcpng-aiops/secrets.enc (Fernet/AES-128 + scrypt-derived key) — never plaintext on disk. Run 'xcpng-aiops init' to onboard, or 'xcpng-aiops secret set <target>' to add one (create the token in the XO UI: user menu → Personal tokens, or `xo-cli --createToken`). The store is unlocked by a master password from XCPNG_AIOPS_MASTER_PASSWORD (non-interactive/MCP/CI) or an interactive prompt (CLI on a TTY). A legacy plaintext env var XCPNG_<TARGET_NAME_UPPER>_TOKEN is still honoured as a fallback with a deprecation warning (migrate with 'xcpng-aiops secret migrate'). The token is sent in headers (Authorization: Bear

_meta.json

{
  "ownerId": "kn7b067awq2s97bn3d7p5qfhw5827pxc",
  "slug": "xcpng-aiops",
  "version": "0.8.4",
  "publishedAt": 1789535956634
}

references/agent-guardrails.md

# Agent guardrails — running xcpng-aiops with a smaller / local model

If you drive these tools with a local model (Llama, Qwen, Mistral … via Goose,
Ollama, LM Studio, or any OpenAI-compatible runtime), you will get noticeably
better results with a short system prompt. This page gives you one, and — more
importantly — tells you which guardrails you **no longer need to write**, because
the tool now enforces them itself.

The distinction matters. A guardrail in a prompt is a request. A guardrail in the
harness is a guarantee. Anything below that we could move into the harness, we did.

## Authorization is not this tool's job — decide it where it belongs

Whether a write should happen is your decision, or the account's. The tool does
not gate it — there is no read-only switch and no approval prompt to configure.
The two right places to control read vs write:

- **The Xen Orchestra account whose token you connect with.** Give that XO user
a read-only ACL, or scope its personal token down. A write then fails at Xen
Orchestra, which is the only place the permission actually lives — a revoked
permission cannot be argued around by a model, but a skill-side flag can.
- **Your agent's system prompt.** If you want an observe-only session, tell the
model not to call the write tools (they are clearly tagged `[WRITE]`).

What the tool *does* guarantee is that you can always see what happened:

## What the tool enforces — do not waste prompt budget on these

| You might be tempted to prompt | Why you don't need to |
|---|---|
| "Don't invent a value when a field is missing" | A field Xen Orchestra did not return comes back as `null`, never as `""`. A VM with no `name_label`, a task with no `properties.name`, an SR with no `content_type` — all report `null`. Absent and empty are distinguishable in the payload. |
| "Tell me if the output was cut off" | Every listing returns `{"vms": [...], "returned": N, "limit": L, "truncated": true/false}` (same shape with `srs`, `vdis`, `snapshots`, `tasks`, `jobs`, `logs`, `undos`). Truncation is **measured** — the full collection length client-side, or one over-fetched record for `backup_log_list` — never guessed from the row count matching the limit. The RCA tools report `inputTruncated` when the listing they correlated over was itself capped. |
| "Preserve the ordering / tell me what's most urgent" | RCA findings carry an explicit `severity` (`high`/`medium`/`low`) and are already sorted worst-first, each with the measured number in `evidence` and a concrete `action`. Priority is in the payload, not implied by list position. |
| "Confirm before anything destructive" | Destructive operations (`snapshot_delete`, `snapshot_revert`, `vm_stop`/`reboot`/`migrate`) require a `dry_run` preview + double confirmation at the CLI. Reversible writes capture the prior state so the undo token can restore it. |
| "Never stop the Xen Orchestra VM itself" | **Only if the operator declared it.** Set `xo_self_vm_uuid` on the target a

references/capabilities.md

# xcpng-aiops — Capabilities (29 MCP tools: 19 read, 8 write, 2 undo)

All tools go through the bundled `@governed_tool` harness (audit / policy /
budget / undo / risk-tier). XO object ids are uuids; get them from the matching
`*_list` tool first. Every tool takes an optional `target` (XO target name
from config; omit for the default).

**Listing envelopes.** `vm_list`, `sr_list`, `vdi_list`, `snapshot_list`,
`task_list`, `backup_job_list`, `backup_log_list` and `undo_list` return
`{<items>: [...], "returned": N, "limit": L, "truncated": bool}` — read the
items under the named key (`vms`, `srs`, `vdis`, `snapshots`, `tasks`, `jobs`,
`logs`, `undos`). `truncated` is measured, not guessed: filters run first, the
cap after, and `backup_log_list` over-fetches one record. When it is true,
re-run with a higher `limit`. The RCA tools report `inputTruncated` when the
listing they correlated over was itself capped.

**Absent vs empty.** A field XO did not return is `null`, never `""` — do not
infer a value for it.

**Authorization.** The tool records; it does not gate. Whether a write may run
is the agent's decision or the connecting Xen Orchestra account's permissions —
there is no read-only switch or approval gate. See `agent-guardrails.md`.

## Overview

| Tool | Risk | Description |
|------|------|-------------|
| `overview` | low | One-shot fleet health: pools, hosts (disabled / reboot-required / versions), VMs by power state + running-without-tools, SRs near full, recent backup failures. Start any triage here. |

## VMs

| Tool | Risk | Description |
|------|------|-------------|
| `vm_list(power_state?, pool?, limit?)` | low | VMs with power state, host, guest-tools status, sizing. |
| `vm_get(vm_id)` | low | One VM: state, host, OS, tools, tags, start time. |
| `vm_stats(vm_id, granularity?)` | low | Recent RRD averages: cpuAvgPercent, memoryUsedPercent. |
| `vm_health_rca(vm_id?)` | low | **RCA**: halted-unexpectedly (auto-poweron/HA set), paused, suspended, guest-tools-missing, cpu-pressure (≥90%), memory-pressure (≥90%). Cause + severity + evidence + action per finding. Fleet mode caps stats pulls at 5 running VMs. |
| `vm_start(vm_id, dry_run?)` | medium | Start a VM. **Undo: vm_stop** (recorded). |
| `vm_stop(vm_id, force?, dry_run?)` | medium | Clean shutdown (hard with force). **Undo: vm_start** — only recorded if the VM was Running before. Refuses the VM declared as running XO (`xo_self_vm_uuid` on the target); with none declared there is **no** such guard — XO has no self endpoint, so it fails open rather than guess. `dry_run` refuses the declared uuid too, and returns `selfVmHint` (a possible IP coincidence, never a verdict, never a block — on either path). |
| `vm_reboot(vm_id, force?, dry_run?)` | medium | Clean/hard reboot. Prior power state captured; **no undo**. |
| `vm_migrate(vm_id, host_id, dry_run?)` | medium | Live-migrate. Captures the REAL source host before moving; **undo: migrate back to it**. |

## Hosts

| Tool | Risk | D

references/cli-reference.md

# xcpng-aiops — CLI reference

Global pattern: `xcpng-aiops <group> <command> [args] [--target <t>]`.
`--target/-t` selects a Xen Orchestra target from `~/.xcpng-aiops/config.yaml`
(default: the first one). Write commands support `--dry-run` (prints the API
call, changes nothing) and destructive ones require **double confirmation**.

## Setup & health

```bash
xcpng-aiops init                    # onboarding wizard: XO URL, TLS verify (default yes), encrypted token
xcpng-aiops doctor [--skip-auth]    # config + secret store + XO reachability + pool count
xcpng-aiops overview [-t xo1]       # one-shot fleet health summary (JSON)
xcpng-aiops mcp                     # start the MCP server (stdio)
```

## VMs

```bash
xcpng-aiops vm list [--state Running|Halted|Paused|Suspended] [--pool <pool_uuid>] [--limit 200]
xcpng-aiops vm get <vm_uuid>
xcpng-aiops vm stats <vm_uuid> [--granularity seconds|minutes|hours|days]
xcpng-aiops vm health-rca [<vm_uuid>]          # RCA (fleet-wide when uuid omitted)
xcpng-aiops vm start <vm_uuid> [--dry-run]                 # governed; undo = stop
xcpng-aiops vm stop <vm_uuid> [--force] [--dry-run]        # double confirm; undo = start
xcpng-aiops vm reboot <vm_uuid> [--force] [--dry-run]      # double confirm; no undo
xcpng-aiops vm migrate <vm_uuid> <host_uuid> [--dry-run]   # double confirm; undo = migrate back
```

`--force` = hard power operation (no guest tools needed); default is a clean
guest shutdown/reboot.

## Hosts

```bash
xcpng-aiops host list [--pool <pool_uuid>]
xcpng-aiops host get <host_uuid>
xcpng-aiops host missing-patches <host_uuid>
```

## Pools

```bash
xcpng-aiops pool list
xcpng-aiops pool get <pool_uuid>
xcpng-aiops pool posture [<pool_uuid>]   # RCA: patches / reboots / version skew / HA
```

## Storage (SRs / VDIs)

```bash
xcpng-aiops sr list [--pool <pool_uuid>] [--limit 200]
xcpng-aiops sr get <sr_uuid>
xcpng-aiops sr vdis [--sr <sr_uuid>] [--orphaned-only] [--limit 200]
xcpng-aiops sr usage-rca                 # RCA: near-full / overcommit / orphaned VDIs
xcpng-aiops sr rescan <sr_uuid> [--dry-run]
```

## Snapshots

```bash
xcpng-aiops snapshot list [--vm <vm_uuid>] [--limit 200]
xcpng-aiops snapshot create <vm_uuid> <name> [--dry-run]
xcpng-aiops snapshot delete <snapshot_uuid> [--dry-run]    # double confirm, IRREVERSIBLE
xcpng-aiops snapshot revert <snapshot_uuid> [--dry-run]    # double confirm, IRREVERSIBLE
```

## Backups & tasks

```bash
xcpng-aiops backup jobs [--limit 200]
xcpng-aiops backup logs [--limit 50]
xcpng-aiops backup failure-rca [--limit 50]   # RCA: vdi-chain / quiesce / transport / storage-full
xcpng-aiops task list [--status pending|success|failure] [--limit 200]
```

## Secrets (encrypted store)

```bash
xcpng-aiops secret set <target> [--value <token>]   # omit --value to be prompted (hidden)
xcpng-aiops secret list                             # names only
xcpng-aiops secret rm <target>
xcpng-aiops secret migrate                          # import legacy plaintex

Github ReposUpdated 1d 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.