VMware AIops
PYPI · VMWARE-AIOPS · SCANNED SEP 21
AI-powered VMware vCenter/ESXi VM lifecycle and deployment with 60 MCP tools.
Available components
How this component scores in each security and reliability category. Every signal is checked automatically from public evidence about the published package, including repeated runs of it in an isolated sandbox, and we only credit what we can confirm. How we score → Why this is hard to score →
Supply Chain Security50
- Malware scan not yet available for this package.Unverified
- No known CVEs affecting this package version or its production dependencies.Pass
- Runs hatchling.build at install time, a recognised native-build step with no shell scripting around it. View diagnostics → Pass
- 4 of 50 dependencies flagged as unhealthy. View diagnostics → Partial
Provenance & Transparency35
- Source repository is publicly reachable at the declared URL. View diagnostics → Pass
- Provenance check failed: no build-provenance attestation is published. See how to fix → View diagnostics → Fail
- License check failed: no license is declared. See how to fix → Fail
- Actively maintained (last published 0 days ago).Pass
- Publishes a security disclosure policy (SECURITY.md).Pass
Schema Quality & AI Usability67
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 14238 tokens (~237/item across 60 items; 60 tools + 0 resources), over budget; trim descriptions and params. See how to fix → Fail
- Usage-examples check failed: none of the tools include examples. See how to fix → Fail
Stability & Change Management63
- Stability check failed: the tool surface changed between 1.8.17 and 1.12.0: 0 tool removals, 13 breaking changes, 0 additions. See how to fix → Fail
Tool Coverage100
- 100% of tools have a non-trivial description (not blank, and not just the tool's name).Pass
- 100% of tool parameters carry a description.Pass
- Structured output schemas are declared (30% of tools); any adoption earns full credit.Pass
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 12 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 61 captured unit(s) of tool text and found none that tries to manipulate the model reading it.Pass
Capabilities100
- Implements a supported MCP spec version (2025-11-25); the latest is 2026-07-28.Pass
How do I install the VMware AIops MCP server?
VMware AIops runs locally as a PyPI package, launched with uvx vmware-aiops. Ready-made configuration for Claude, Cursor, VS Code, Codex and 5 more is on this page, copied from each client's own documentation.
pypi · vmware-aiops
claude mcp add vmware-skills-vmware-aiops -- uvx vmware-aiops
{
"mcpServers": {
"vmware-skills-vmware-aiops": {
"command": "uvx",
"args": [
"vmware-aiops"
]
}
}
} {
"servers": {
"vmware-skills-vmware-aiops": {
"command": "uvx",
"args": [
"vmware-aiops"
]
}
}
} codex mcp add vmware-skills-vmware-aiops -- uvx vmware-aiops
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"vmware-skills-vmware-aiops": {
"type": "local",
"command": [
"uvx",
"vmware-aiops"
],
"enabled": true
}
}
} openclaw mcp add vmware-skills-vmware-aiops --command uvx --arg vmware-aiops
mcp_servers:
vmware-skills-vmware-aiops:
command: "uvx"
args: ["vmware-aiops"] {
"McpServers": {
"vmware-skills-vmware-aiops": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"vmware-aiops"
]
}
}
} assistant mcp add vmware-skills-vmware-aiops -t stdio -c uvx -a vmware-aiops
{
"mcpServers": {
"vmware-skills-vmware-aiops": {
"command": "uvx",
"args": [
"vmware-aiops"
]
}
}
} Every change we have recorded for this component, newest first. Security-relevant changes are always shown. ▲ marks a change for the better, ▼ a change for the worse; unmarked changes are neutral.
- 21 Sept 26 −14
- Malware scan: pass → unverified ▼ security
- 20 Sept 26 +15
- Stability: fail → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Malware scan: unverified → pass ▲ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Schema quality: Schema quality not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet. functional
- Package version: 1.11.0 → 1.12.0 functional
- 19 Sept 26 −1
- Tool coverage: 47% → 30% ▼ functional
- Schema quality: 194 → 236 ▼ functional
- Package version: 1.9.7 → 1.11.0 functional
- Package version: 1.9.7 → 1.10.0 functional
- 18 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 57 to 60.
- 16 Sept 26 +1
- Package version: 1.9.5 → 1.9.7 functional
- 15 Sept 26 0
- Stability: fail → unverified ▼ security
- Tool safety: pass → unverified ▼ security
- Malware scan: unverified → pass ▲ security
- Capabilities: pass → unverified ▼ functional
- Tool coverage: 100 → unverified ▼ functional
- Schema quality: Schema quality not yet verified: we do not have a sandbox capture of the MCP schema this version of the package serves yet. functional
- Package version: 1.9.1 → 1.9.5 functional
- Package version: 1.9.1 → 1.9.4 functional
- Package version: 1.9.1 → 1.9.3 functional
- Package version: 1.9.1 → 1.9.2 functional
- 14 Sept 26 +1
- Malware scan: unverified → pass ▲ security
- Package version: 1.9.0 → 1.9.1 functional
- 12 Sept 26 0
- Stability: 0.40 → fail ▼ security
- Package version: 1.8.22 → 1.9.0 functional
Diagnostic detail from the automated scan of this channel: what the scanner observed at each step, so you can see exactly where a check passed or failed. It is informational only and never changes the trust score.
Captured 21 Sept 2026 · Analysed pypi/vmware-aiops@1.12.0
Provenance No attestation
The registry publishes no build provenance for this version, so there is nothing to verify.
| Result | No attestation |
|---|---|
| Ecosystem | pypi |
Background: How many MCP packages publish verified provenance →
Install scripts 1 script
| Hook | Tier | Command |
|---|---|---|
| build_backend | allowlisted | hatchling.build |
Background: Why install scripts are a supply-chain risk →
Dependencies 50 packages
| Packages resolved | 50 |
|---|---|
| Stale | 4 |
| Tree resolution | Complete |
Background: SBOMs and build attestations, explained →
The tools this component advertises to a client, with an estimated token cost for each. Expand a tool to see its parameters and schema. The per-tool counts are indicative and are not scored directly; the schema's total context footprint is one signal in Schema Quality & AI Usability. A tool's description is untrusted text the model reads on every call, which is what makes this list a security surface and not just an inventory: how tool poisoning works →
vm_list_ttl ~95
[READ] List all VMs with TTLs registered, including expiry time and status. Use this first to find the exact vm_name for vm_cancel_ttl. Returns the list envelope: 'items' holds TTL entries with remaining_minutes and expired flag, and 'returned'/'total'/'truncated' state whether the listing is complete. The whole TTL store is read, so truncated is always false.
Input schema present but exposes no named parameters.
No output schema declared.
No examples provided.
vm_migrate ~311
[WRITE] Migrate (vMotion) a VM to another host, optionally with storage vMotion. Without confirm=True this only previews: it returns blast_radius (VM and instance UUID, source host and datastores, target host with its connection and maintenance state, target datastore, and live vMotion vs cold migration) and moves nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused: a target host that is not found, not connected, in maintenance mode or outside a cluster; a target datastore that is not found; a target host that does not mount the VM's datastores when to_datastore is omitted (vCenter rejects cross-host vMotion without shared storage — pass to_datastore); and anything above that cannot be read. The VM's current host with no to_datastore returns action "noop". Run cluster_info first for host names. Returns: Dict with action (preview, noop, migrated), blast_radius, and result.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| target | – | – | vCenter/ESXi target name from config. |
| to_datastore | – | – | Target datastore (required for cross-storage hosts). |
| to_host | string | yes | Target ESXi host name. |
| vm_name | string | yes | VM to migrate. |
No output schema declared.
No examples provided.
vm_power_off ~323
[WRITE] Power off a VM — graceful guest shutdown by default, hard power-off with force=True. Without confirm=True this only previews: it returns blast_radius (VM name and instance UUID, host, power state, VMware Tools status, and whether this is a guest shutdown or a hard power-off) and changes nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Graceful mode calls VMware Tools guest shutdown and waits up to 120s; if it does not finish, action is "still_running". Refused: a graceful shutdown when Tools is not running or the VM is suspended (preview force=True instead), and a VM whose identity or power state cannot be read. An already-off VM returns action "noop". Use vm_power_on to start a VM; vm_delete requires it off first. Returns: Dict with action (preview, noop, powered_off, still_running), blast_radius, and the executor's message under result.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| force | boolean | – | False (default) = graceful guest shutdown via VMware Tools; True = immediate hard power-off (risks guest filesystem damage). |
| target | – | – | vCenter/ESXi target from config.yaml; omit for the default target. |
| vm_name | string | yes | Exact VM name as shown in vCenter inventory (case-sensitive). |
No output schema declared.
No examples provided.
vm_power_on ~100
[WRITE] Power on a virtual machine. Returns a status string; an already-on VM is a no-op. Reverse with vm_power_off. Call this first when a VM is off: guest tools such as vm_guest_exec only work once VMware Tools has finished booting.
| Name | Type | Req | Description |
|---|---|---|---|
| target | – | – | Optional vCenter/ESXi target name from config. Uses default if omitted. |
| vm_name | string | yes | Exact name of the virtual machine. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vm_reconfigure ~152
[WRITE] Change a VM's vCPU count and/or memory. Pass only the fields you want to change; omitted fields are left untouched. Hot-add of CPU/memory requires it to be enabled on the VM and a running guest; otherwise power the VM off first (vm_power_off). Returns: Status string describing the applied change, or a VM-not-found error.
| Name | Type | Req | Description |
|---|---|---|---|
| cpu | – | – | New vCPU count; omit to leave unchanged. |
| memory_mb | – | – | New memory in MB; omit to leave unchanged. |
| target | – | – | vCenter/ESXi target name from config.yaml; omit to use the default target. |
| vm_name | string | yes | Exact name of the VM to reconfigure. |
| Name | Type | Req | Description |
|---|---|---|---|
| result | string | yes | – |
No examples provided.
vm_revert_snapshot ~271
[WRITE] Revert a VM to a named snapshot (loses changes since snapshot). Without confirm=True this only previews: it returns blast_radius (VM and instance UUID, the snapshot's name, id and creation time, total snapshot count, current power state and the power state after the revert) and changes nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Irreversible — everything written since the snapshot is lost. Refused: a snapshot name that is not found, a name that matches more than one snapshot on the VM (vSphere allows duplicates; rename one first), and a VM whose snapshot tree, identity or power state cannot be read. Run vm_list_snapshots first for exact names. To reclaim space without changing state use vm_delete_snapshot. Returns: Dict with action (preview, reverted), blast_radius, and result.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| snapshot_name | string | yes | Snapshot to revert to. |
| target | – | – | vCenter/ESXi target name from config. |
| vm_name | string | yes | VM to revert. |
No output schema declared.
No examples provided.
vm_rollback_plan ~272
[WRITE] Rollback executed steps of a failed plan in reverse order. Without confirm=True this only previews: it returns blast_radius listing the rollback steps that would run (in order, with the VMs a rollback deletes) and those skipped as irreversible — and runs nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Only call this after vm_apply_plan returns status='failed'; check vm_list_plans first for the plan_id. Irreversible steps (delete_vm, revert_snapshot, etc.) are skipped with a warning. Each destructive rollback step (power off, delete snapshot, cluster delete, host removal) is measured as its own tool measures it, in the preview and again just before it runs; a refused check stops the rollback there and the plan stays 'failed'. Refused on a target other than the one the plan was created against.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| plan_id | string | yes | The plan ID of the failed plan. |
| target | – | – | The vCenter/ESXi target the plan was created against. |
No output schema declared.
No examples provided.
vm_set_ttl ~283
[WRITE] Set a Time-To-Live (TTL) for a VM. The daemon auto-deletes it when expired. Without confirm=True this only previews: it returns blast_radius — the VM that will be deleted (identity, host, disks, total size, snapshot count), when (expires_at), and any TTL it replaces — and schedules nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused when the VM's identity or disks cannot be read. Use this for short-lived lab VMs so cleanup is not forgotten; cancel with vm_cancel_ttl and review pending expiries with vm_list_ttl. The scheduler daemon must be running (`vmware-aiops daemon start`) or nothing is ever deleted; it powers a running VM off first. TTLs persist in ~/.vmware-aiops/ttl.json. Returns a dict (action, blast_radius).
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| minutes | integer | yes | Minutes until deletion (minimum 1). |
| target | – | – | Optional vCenter/ESXi target name from config. |
| vm_name | string | yes | Name of the VM to auto-delete. |
No output schema declared.
No examples provided.
vm_task_status ~186
[READ] Poll a long-running vSphere task by its id (from an async vm_delete_snapshot). Use after vm_delete_snapshot returns a task id, instead of re-running the delete. Returns state (queued/running/success/error/gone), progress percent, and the entity name. 'gone' means vCenter already garbage-collected a completed task — re-list the resource to confirm the final state. A failed task reports its fault under 'task_error'; a top-level 'error' key would mean this poll itself failed. Returns: Dict with task_id, state, progress_pct, operation, entity, and task_error/note when relevant.
| Name | Type | Req | Description |
|---|---|---|---|
| target | – | – | vCenter/ESXi target name from config.yaml; omit to use the default target. |
| task_id | string | yes | The task id string returned by an async write operation. |
No output schema declared.
No examples provided.
vmk_ping ~342
[READ] DF-bit-capable ping sourced from a host vmk - MTU path validation. Runs `esxcli network diag ping` on the ESXi host through the vSphere API (no host SSH). df=True sets Don't-Fragment so an oversized packet FAILS instead of fragmenting - that failure is the diagnostic: - df=True size=1572 proves a >=1600 MTU path (overlay/TEP floor) - df=True size=8972 proves full jumbo (9000 minus 28 bytes overhead) A too-big result reports 'Message too long' in the fault field rather than erroring - read success + fault together. Returns: Dict with request, success, and summary (transmitted/received/loss/ rtt) or fault (the esxcli failure text). Errors return "error" + hint.
| Name | Type | Req | Description |
|---|---|---|---|
| count | integer | – | Packets to send (default 3, max 60). |
| dest_ip | string | yes | IPv4 address to ping. |
| df | boolean | – | True sets the Don't-Fragment bit (the MTU probe mode). |
| host_name | string | yes | ESXi host to source the ping from. |
| netstack | – | – | Optional netstack instance (e.g. "vxlan" for real TEP vmks). |
| size | integer | – | ICMP payload bytes (default 56). Path proves size+28 MTU. |
| source_vmk | string | yes | VMkernel device to source from (e.g. "vmk2"). |
| target | – | – | vCenter target name from config.yaml; omit to use the default target. |
No output schema declared.
No examples provided.
What is the VMware AIops MCP server?
VMware AIops is an MCP server listed in the public MCP registry as io.github.vmware-skills/vmware-aiops. AI-powered VMware vCenter/ESXi VM lifecycle and deployment with 60 MCP tools. This page covers its PyPI package (vmware-aiops).
Is the VMware AIops MCP server safe to use?
VMware AIops scores 61 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 21 September 2026. That is a record of what we were able to check automatically, not an endorsement. The category breakdown on this page shows every signal behind the number, including the ones we could not confirm.
What tools does the VMware AIops MCP server expose?
VMware AIops exposes 60 tools: list_vcenter_alarms, acknowledge_vcenter_alarm, reset_vcenter_alarm, cluster_create, cluster_delete, and 55 more. Their descriptions and schemas cost roughly 13,966 tokens of context every time the server is loaded.
Is the VMware AIops MCP server still maintained?
VMware AIops is still listed as active in the MCP registry. We last reached this channel on 21 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.