Skip to main content
Glama
vmware-skills

vmware-storage

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_storage_device_paths

Read-onlyIdempotent

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

Instructions

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

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hostNoESXi host name exactly as in vCenter inventory.
limitNoDevices per page, 1-200 (default 50).
deviceNoCanonical name (e.g. naa.60060e80...) or display name; case-insensitive.
offsetNoDevices to skip; pass the previous page's next_offset.
targetNoOptional vCenter/ESXi target name from config.
adapterNovmhba name (e.g. vmhba2) to keep devices with a path through it.
clusterNoCluster name exactly as in vCenter.
datastoreNoDatastore name; scopes to the hosts that mount it and its VMFS extents.
only_differencesNoKeep only devices whose visibility or path count differs across the hosts that were read.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false), yet the description adds substantial behavior: hosts_not_read semantics ('refused, not connected... vCenter's copy may be stale'), how to interpret 'complete: false', that 'standby' can be normal on active/passive arrays, that a path count does not prove independent fabrics, and 'No rescans.' This is exactly the value-add the description should provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is organized under clear signposts ('Use for:', 'Per device:', 'Gotchas:') and front-loads purpose before detail. It is dense, and the long per-device field enumeration is heavier than strictly necessary, but for a 9-parameter tool most sentences carry real information rather than padding.

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 accepts the full burden of describing returns — it lists per-device fields, per-path detail conditions, and the 'summary counts the whole result, not just this page' pagination note — plus caveats about NFS/vSAN/vVol and NVMe-oF. Nothing an agent needs to invoke or interpret the result correctly is missing.

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%, so the baseline is 3, but the description adds meaning beyond the schema: it enforces the 'exactly one of cluster/host/datastore' mutual-exclusion rule, clarifies that adapter matches by vmhba name which 'can be a different card on each host', and explains only_differences scoping. These semantics are not present in the schema fields.

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 opening sentence gives a specific verb ([READ]), resource (SCSI multipath state per device/NAA), and scope (across hosts of one scope), then enumerates what it reports (path counts/states, adapters, target WWPN, PSP/SATP, VMFS datastores). This lets an agent distinguish it from siblings like list_fc_adapters or list_all_datastores without opening any schema.

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

Usage Guidelines5/5

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

Four concrete 'Use for:' scenarios map directly to parameter combinations (datastore=X; cluster+device; cluster+only_differences=true; host+adapter). The constraint 'Exactly one of cluster, host or datastore is required — this tool will not read every host at once' is an explicit when-not rule, leaving nothing to inference.

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

Deploy Server

Other Tools