VMware Storage
PYPI · VMWARE-STORAGE · SCANNED SEP 20
VMware vSphere storage with 14 MCP tools: datastores, iSCSI, vSAN, FC multipath.
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 Security100
- No malware found by supply-chain analysis.Pass
- 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
- 3 of 43 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 Usability65
- AI-judged instruction clarity (excellent).Pass
- Context-footprint check failed: tool/resource definitions use about 4071 tokens (~290/item across 14 items; 14 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 Management53
- Stability check failed: the tool surface changed between 1.8.14 and 1.12.0: 0 tool removals, 4 breaking changes, 2 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
Tool Safety100
- No prompt-injection markers were found in the server instructions, tool names or descriptions we captured.Pass
- All 1 tool(s) whose name or description implies an irreversible operation declare an MCP destructiveHint annotation.Pass
- An AI judge read all 15 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 Storage MCP server?
VMware Storage runs locally as a PyPI package, launched with uvx vmware-storage. 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-storage
claude mcp add vmware-skills-vmware-storage -- uvx vmware-storage
{
"mcpServers": {
"vmware-skills-vmware-storage": {
"command": "uvx",
"args": [
"vmware-storage"
]
}
}
} {
"servers": {
"vmware-skills-vmware-storage": {
"command": "uvx",
"args": [
"vmware-storage"
]
}
}
} codex mcp add vmware-skills-vmware-storage -- uvx vmware-storage
{
"$schema": "https://opencode.ai/config.json",
"mcp": {
"vmware-skills-vmware-storage": {
"type": "local",
"command": [
"uvx",
"vmware-storage"
],
"enabled": true
}
}
} openclaw mcp add vmware-skills-vmware-storage --command uvx --arg vmware-storage
mcp_servers:
vmware-skills-vmware-storage:
command: "uvx"
args: ["vmware-storage"] {
"McpServers": {
"vmware-skills-vmware-storage": {
"Transport": "stdio",
"Command": "uvx",
"Arguments": [
"vmware-storage"
]
}
}
} assistant mcp add vmware-skills-vmware-storage -t stdio -c uvx -a vmware-storage
{
"mcpServers": {
"vmware-skills-vmware-storage": {
"command": "uvx",
"args": [
"vmware-storage"
]
}
}
} 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.
- 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 −2
- Stability: 0.63 → fail ▼ security
- Package version: 1.10.0 → 1.11.0 functional
- 18 Sept 26 0
- Schema quality: 210 → 247 ▼ functional
- Package version: 1.9.3 → 1.10.0 functional
- 16 Sept 26 +1
- Package version: 1.9.2 → 1.9.3 functional
- 15 Sept 26 −15
- Malware scan: pass → unverified ▼ security
- Package version: 1.9.0 → 1.9.2 functional
- Package version: 1.9.0 → 1.9.1 functional
- 14 Sept 26 +16
- Malware scan: unverified → pass ▲ security
- 12 Sept 26 +1
- Package version: 1.8.17 → 1.9.0 functional
- 10 Sept 26 +1
No change was recorded against any check on this day. Stability & Change Management went from 33 to 37. That category is still filling its 30-day observation window: 10 days of observed history at the previous scan, 11 at this one. The score rises as the window fills, whether or not the server changes.
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 20 Sept 2026 · Analysed pypi/vmware-storage@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 43 packages
| Packages resolved | 43 |
|---|---|
| Stale | 3 |
| 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 →
browse_datastore ~154
[READ] Browse files in a datastore directory. Use this for arbitrary files or a glob; prefer scan_datastore_images for deployable images. ds_name comes from list_all_datastores. Returns the list envelope: 'items' holds one row per file, and 'returned'/'total'/'truncated' state whether the listing is complete. All matches are returned, so truncated is always false.
| Name | Type | Req | Description |
|---|---|---|---|
| ds_name | string | yes | Datastore name. |
| path | string | – | Subdirectory path (empty for root). |
| pattern | string | – | Glob pattern to filter files (e.g. "*.ova", "*.iso"). |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
fc_adapter_list ~316
[READ] List Fibre Channel HBAs (FC and FCoE) per ESXi host: vmhba, model, driver, status, port type, WWPN/WWNN and reported link speed. Use this for "which FC adapters does each host have" or to find a host's WWPNs; use storage_device_paths for devices and paths behind them. Scope with cluster OR host; with neither, every host on the target is read (only the adapter list is fetched, so this stays cheap). Returns the list envelope ('items', 'returned', 'total', 'truncated', 'next_offset') plus hosts_without_fc (read, no FC HBA) and hosts_not_read [{host, reason}]. A host in hosts_not_read was NOT read — never report it as having no FC adapters. speed_reported is the raw vSphere value: the API documents bits per second, but hosts commonly report Gbit/s, so it is not converted. Reads host config only; no rescans.
| Name | Type | Req | Description |
|---|---|---|---|
| cluster | – | – | Cluster name exactly as in vCenter. Omit to use host or the whole target. |
| host | – | – | ESXi host name exactly as in vCenter inventory (FQDN or IP). |
| limit | integer | – | Rows per page, 1-200 (default 50). |
| offset | integer | – | Rows to skip; pass the previous page's next_offset. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
list_all_datastores ~107
[READ] List all datastores with capacity, usage percentage, and accessibility. Use this first for the ds_name that browse_datastore and scan_datastore_images require. Returns the list envelope: 'items' holds one row per datastore, and 'returned'/'total'/'truncated' state whether the listing is complete. Enumerated in one pass, so truncated is always false.
| Name | Type | Req | Description |
|---|---|---|---|
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
list_cached_images ~211
[READ] List deployable images (OVA/OVF/ISO/VMDK) from the local cache registry — instant, no vCenter connection or datastore I/O. Reads ~/.vmware-storage/image_registry.json, populated by prior datastore scans; results may be stale or empty if no scan has run. For a live listing use scan_datastore_images instead. Returns the list envelope: 'items' holds {datastore, name, ds_path, size_mb, type, modified} and is empty if nothing matches, while 'returned'/'total'/'truncated' state whether the listing is complete. The whole registry is filtered in memory, so truncated is always false.
| Name | Type | Req | Description |
|---|---|---|---|
| datastore | – | – | Filter by exact datastore name. Omit for all datastores. |
| image_type | – | – | Filter by file extension without the dot, e.g. "ova", "iso", "ovf", "vmdk" (case-insensitive). Omit for all types. |
No output schema declared.
No examples provided.
scan_datastore_images ~147
[READ] Scan a datastore for deployable images (OVA, ISO, OVF, VMDK). Use this for a live scan of one datastore; prefer list_cached_images for a cached answer. ds_name comes from list_all_datastores. Returns the list envelope: 'items' holds one row per image, and 'returned'/'total'/'truncated' state whether the listing is complete. All patterns are browsed, so truncated is always false.
| Name | Type | Req | Description |
|---|---|---|---|
| ds_name | string | yes | Datastore name. |
| path | string | – | Subdirectory path (empty for root). |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
storage_device_paths ~623
[READ] SCSI multipath state per device (NAA) across the hosts of one scope: which hosts see it, path counts and states, working paths, adapters, target WWPN, PSP/SATP policy, and the VMFS datastores on it. Use for: "does datastore X have dead or disabled paths on any host" (datastore=X), "which hosts see naa.… and through which adapters" (cluster + device), "do hosts see different numbers of paths" (cluster + only_differences=true), "which devices and datastores depend on vmhba2" (host + adapter). Exactly one of cluster, host or datastore is required — this tool will not read every host at once. Per device: shared (reached over FC/iSCSI or seen by 2+ hosts), seen_by, not_seen_on (hosts that WERE read and do not see a shared device; a disk inside one host is never listed), path_count_differs, states_needing_attention (dead/disabled only) and per-host {paths_total, by_state, working_paths, policy, satp, adapters}; with adapter set, also paths_via_adapter and only_paths_via_adapter (matched by vmhba name, which can be a different card on each host of a cluster). Per-path detail is included when device or datastore is given. Devices needing attention sort first; 'summary' counts the whole result, not just this page. Gotchas: hosts in hosts_not_read were NOT read (refused, not connected — vCenter's copy of a lost host's config may be stale — or missing from the reply) and are never in not_seen_on — when complete is false, say which hosts are unknown instead of concluding a device is missing. States are as vSphere reports them: 'standby' can be normal (active/passive arrays), and a path count does not prove independent fabrics. NFS/vSAN/vVol datastores have no SCSI paths (scope_note says so). NVMe-oF namespaces may not appear. No rescans.
| Name | Type | Req | Description |
|---|---|---|---|
| adapter | – | – | vmhba name (e.g. vmhba2) to keep devices with a path through it. |
| cluster | – | – | Cluster name exactly as in vCenter. |
| datastore | – | – | Datastore name; scopes to the hosts that mount it and its VMFS extents. |
| device | – | – | Canonical name (e.g. naa.60060e80...) or display name; case-insensitive. |
| host | – | – | ESXi host name exactly as in vCenter inventory. |
| limit | integer | – | Devices per page, 1-200 (default 50). |
| offset | integer | – | Devices to skip; pass the previous page's next_offset. |
| only_differences | boolean | – | Keep only devices whose visibility or path count differs across the hosts that were read. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
storage_iscsi_add_target ~312
[WRITE] Add an iSCSI send (dynamic discovery) target to an ESXi host's software iSCSI adapter, then automatically rescan all HBAs and VMFS volumes to discover new LUNs. Without confirm=True this only previews: it returns blast_radius (the adapter, the send targets configured now, and the adapters the rescan touches) and changes nothing. Show it to the user. Do not set confirm=True on your own because the user asked earlier — they have not seen the preview yet. Refused when software iSCSI is not enabled (run storage_iscsi_enable first) or the host's storage view cannot be read. A duplicate address:port returns action "noop". No separate storage_rescan call is needed afterwards. Returns a dict.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | iSCSI portal IP address (IPv4/IPv6 literal; hostnames are rejected with a validation error). |
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| dry_run | – | – | Deprecated alias for confirm; removed in the next minor release. dry_run=False acts, dry_run=True previews. |
| host_name | string | yes | ESXi host name as shown in vCenter inventory. |
| port | integer | – | iSCSI TCP port, 1-65535 (default 3260). |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
storage_iscsi_enable ~259
[WRITE] Enable the software iSCSI adapter (vmhba) on an ESXi host. Required prerequisite before storage_iscsi_add_target. Without confirm=True this only previews: it returns blast_radius (the host, its current adapters, whether the software adapter already exists) and changes nothing. Show it to the user. Do not set confirm=True on your own because the user asked earlier — they have not seen the preview yet. Already enabled returns action "noop" with the HBA device and IQN. Non-disruptive (no reboot, no impact on existing datastores). Refused when the host's storage view cannot be read. Returns a dict; check state first with storage_iscsi_status.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| dry_run | – | – | Deprecated alias for confirm; removed in the next minor release. dry_run=False acts, dry_run=True previews. |
| host_name | string | yes | ESXi host name exactly as shown in vCenter inventory (FQDN or IP). Errors if not found. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
storage_iscsi_remove_target ~352
[WRITE] Remove an iSCSI send target from an ESXi host's software iSCSI adapter, then rescan all HBAs and VMFS volumes. Destructive: LUNs served only through this target become inaccessible after the rescan. Without confirm=True this only previews: it returns blast_radius (the static targets it discovered, the paths that go with them, the devices and VMFS datastores that lose all or some paths) and changes 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 what it cuts off yet. Refused when a datastore would lose every path (unmount it first), when the address:port is not configured or software iSCSI is disabled, and when any path or static target cannot be attributed. Reversible only by re-adding via storage_iscsi_add_target. Returns a dict.
| Name | Type | Req | Description |
|---|---|---|---|
| address | string | yes | Configured iSCSI portal IP (IPv4/IPv6 literal; hostnames rejected). Must match the existing entry exactly. |
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| dry_run | – | – | Deprecated alias for confirm; removed in the next minor release. dry_run=False acts, dry_run=True previews. |
| host_name | string | yes | ESXi host name as shown in vCenter inventory. |
| port | integer | – | Configured iSCSI TCP port, 1-65535 (default 3260). |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
storage_iscsi_status ~173
[READ] Get the software iSCSI adapter state and configured send targets for an ESXi host. Returns {host, enabled, hba_device, iqn, send_targets: [{address, port}]}; when the adapter is disabled, enabled=false with null device/IQN and an empty target list. Use this before storage_iscsi_enable / storage_iscsi_add_target / storage_iscsi_remove_target to check prerequisites, and afterwards to verify the change took effect.
| Name | Type | Req | Description |
|---|---|---|---|
| host_name | string | yes | ESXi host name exactly as shown in vCenter inventory (FQDN or IP). Errors if not found. No host listing here — get names from vmware-monitor list_esxi_hosts. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
storage_rescan ~277
[WRITE] Rescan all HBAs and VMFS volumes on an ESXi host to discover newly presented LUNs and datastores. Use this when a storage array presents new LUNs, or after out-of-band SAN changes. Not needed after storage_iscsi_add_target / storage_iscsi_remove_target — those rescan automatically. Without confirm=True this only previews: it returns blast_radius (the host, every adapter the rescan touches, the mounted VMFS volumes) and changes nothing. Show it to the user. Do not set confirm=True on your own because the user asked earlier — they have not seen the preview yet. Deletes nothing, but it is I/O-visible on the host and may take a minute or two with many paths. Refused when the host's storage view cannot be read. Returns a dict.
| Name | Type | Req | Description |
|---|---|---|---|
| confirm | boolean | – | False (default) returns the blast radius and changes nothing. True applies it. |
| dry_run | – | – | Deprecated alias for confirm; removed in the next minor release. dry_run=False acts, dry_run=True previews. |
| host_name | string | yes | ESXi host name as shown in vCenter inventory (FQDN or IP). Errors if not found. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
vsan_capacity ~227
[READ] Get space usage of a cluster's vSAN datastore for capacity planning. Returns {cluster_name, vsan_enabled, datastore_name, accessible, total_gb, used_gb, free_gb, usage_pct}. When the vSAN datastore is inaccessible (accessible=false) the four figures are null with a message, not 0 — vCenter answers 0 for a datastore it cannot reach, and 0 GB used reads as a healthy empty datastore. accessible=null means the summary did not say. If vSAN is not enabled on the cluster, returns vsan_enabled=false with an explanatory message rather than an error; errors only if the cluster name is not found. Use vsan_health for disk-group layout and host details; use list_all_datastores for non-vSAN (VMFS/NFS) datastore usage. No side effects.
| Name | Type | Req | Description |
|---|---|---|---|
| cluster_name | string | yes | Cluster name exactly as shown in vCenter. Errors if the cluster is not found. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
vsan_efficiency ~268
[READ] Get vSAN data-efficiency (deduplication + compression) status for a cluster. Returns {cluster_name, vsan_enabled, dedup_enabled, compression_enabled}. Reads it via the vSAN Management SDK (VsanVcClusterConfigSystem), not base pyVmomi. When vSAN reports no data-efficiency config (space efficiency off, or an OSA cluster without it), dedup_enabled/compression_enabled come back null with a message rather than a fabricated false. Errors only if the cluster name is not found. Use vsan_capacity for space usage and vsan_health for disk-group layout. No side effects. Note: vSAN Global Deduplication and vSAN-to-vSAN replication are NOT exposed here — neither has a verified SDK object (global dedup has no distinct field; v2v replication lives in the separate vSAN Data Protection plane). Use the vCenter/vSAN UI for those.
| Name | Type | Req | Description |
|---|---|---|---|
| cluster_name | string | yes | Cluster name exactly as shown in vCenter (case-sensitive). Errors if the cluster is not found — vmware-storage has no cluster-listing tool; get names from vmware-monitor list_all_clusters. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
vsan_health ~351
[READ] Get vSAN overall health, per-check-group health, and per-host disk-group layout for a cluster. Returns {cluster_name, vsan_enabled, overall_health, overall_health_description, health_queried, health_not_queried_reason, health_checked_at, test_groups: [{group_id, group_name, group_health}], host_count, hosts_read, hosts_not_read: [{host, reason}], disk_groups_complete, disk_groups: [{host, cache_disk, cache_size_gb, capacity_disks}]}. overall_health is what vSAN reports — green / yellow / red, and sometimes "unknown", which is vSAN's own answer. When the health service could not be asked at all, overall_health is null and health_queried is false with the reason: a null is "not measured", never a measurement. health_checked_at is the age of vCenter's cached summary (the same one Skyline Health shows); this tool reads the cache rather than triggering a full health run. Check disk_groups_complete before treating disk_groups as the cluster's inventory: vCenter cannot read a disconnected or notResponding host, and an empty disk_groups on such a cluster does NOT mean it has none — the unread hosts are named in hosts_not_read and in the message. If vSAN is not enabled, returns vsan_enabled=false with a message rather than an error. Use vsan_capacity for space usage instead. No side effects.
| Name | Type | Req | Description |
|---|---|---|---|
| cluster_name | string | yes | Cluster name exactly as shown in vCenter. Errors if the cluster is not found. |
| target | – | – | Optional vCenter/ESXi target name from config. |
No output schema declared.
No examples provided.
What is the VMware Storage MCP server?
VMware Storage is an MCP server listed in the public MCP registry as io.github.vmware-skills/vmware-storage. VMware vSphere storage with 14 MCP tools: datastores, iSCSI, vSAN, FC multipath. This page covers its PyPI package (vmware-storage).
Is the VMware Storage MCP server safe to use?
VMware Storage scores 74 out of 100 on VerifyMCP. We found no known CVEs affecting it as of 20 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 Storage MCP server expose?
VMware Storage exposes 14 tools: list_all_datastores, browse_datastore, scan_datastore_images, list_cached_images, storage_iscsi_enable, and 9 more. Their descriptions and schemas cost roughly 3,777 tokens of context every time the server is loaded.
Is the VMware Storage MCP server still maintained?
VMware Storage is still listed as active in the MCP registry. We last reached this channel on 20 September 2026. Those dates come from our own scans of the registry and the channel itself, not from anything the publisher announced.