Skip to main content
Glama

storage_device_paths

Read-onlyIdempotent

Identify dead or disabled SCSI paths per device across hosts: check which hosts see a device, path counts, working paths, and linked datastores to resolve multipath problems.

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. Addedv1.10.0

TDQS

A5/5.0
Behavior5/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, and the description does not contradict them. It adds substantial operational behavior beyond annotations: hosts_not_read are never in not_seen_on, 'standby' can be normal for active/passive arrays, NFS/vSAN/vVol datastores have no SCSI paths, NVMe-oF namespaces may not appear, and no rescans are performed.

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

Conciseness5/5

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

The description is long but tightly organized into 'Use for', 'Per device', and 'Gotchas' sections, with the core scoping rule stated early. Every section earns its place by addressing a distinct aspect an agent needs: purpose, query patterns, output shape, pagination, and edge cases.

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?

Although there is no output schema, the description fully enumerates the per-device and per-host result fields, pagination mechanics, failure semantics via hosts_not_read, and known exclusions such as NFS/vSAN/vVol and NVMe-oF. An agent has enough context to invoke the tool correctly and interpret results confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents each parameter. The description still adds valuable cross-parameter semantics: exactly one scope is required, adapter matching by vmhba name may refer to different cards per host, datastore scopes to mounting hosts and VMFS extents, and pagination uses next_offset while 'summary' covers the whole result. This goes well beyond the schema.

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 description opens with a specific verb and resource: '[READ] SCSI multipath state per device (NAA) across the hosts of one scope' and enumerates concrete outputs such as path counts, adapters, target WWPN, and PSP/SATP policy. It clearly distinguishes this tool from storage-related siblings like storage_iscsi_status or vsan_health by focusing on multipath state and path visibility.

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?

The 'Use for' section gives explicit example queries mapped to parameter combinations, and the description states the key selection rule: 'Exactly one of cluster, host or datastore is required.' It also provides when-not-to-use guidance, e.g., warning that hosts in hosts_not_read must not be used to conclude a device is missing.

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