Skip to main content
Glama
vmware-skills

vmware-storage

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_vsan_health

Read-onlyIdempotent

[READ] Get vSAN overall health, per-check-group health, and per-host disk-group layout for a cluster.

Instructions

[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 get_vsan_capacity for space usage instead. No side effects.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoOptional vCenter/ESXi target name from config.
cluster_nameYesCluster name exactly as shown in vCenter. Errors if the cluster is not found.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.0.0

TDQS

A4.4/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 context: it reads the cache rather than running a full health check, explains that a null overall_health means 'not measured' and never a measurement, warns that disk_groups is incomplete when hosts are unread, and notes vSAN-disabled returns a message rather than an error.

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?

Front-loads purpose, then the return shape, then the important caveats (null semantics, disk_groups_complete, vsan-disabled path). It is dense and each sentence earns its place, though the return-shape enumeration is lengthy.

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 fully carries the burden: it enumerates the return shape and explains the semantics of the ambiguous fields (overall_health nulls, health_checked_at, disk_groups_complete). Nothing an agent needs to interpret the result is missing.

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

Parameters3/5

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

Schema description coverage is 100% (both target and cluster_name are documented, including the 'errors if not found' behavior), so the schema carries the parameter burden. The description adds no parameter-specific detail beyond what the schema states, making the baseline 3 appropriate.

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?

States a specific verb (Get) plus resource (vSAN health) and scope: overall health, per-check-group health, and per-host disk-group layout for a cluster. It explicitly distinguishes itself from the sibling get_vsan_capacity, so an agent can route between them without opening a schema.

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

Usage Guidelines4/5

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

Names an alternative explicitly ('Use get_vsan_capacity for space usage instead') and clarifies that it reads vCenter's cached summary rather than triggering a full health run, which tells the agent when this is the cheap option. It lacks broader when-not guidance, but the routing context is clear.

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