mcp-vmware

Overview Schema Source Related Servers Discussions Admin

vmware_host_health

Read-only

Monitor ESXi host hardware health by checking sensors for CPU, memory, and storage state. Returns a structured summary with sensor counts and details for non-green sensors.

Instructions

Hardware health sensors of a host (equivalent of esxcli hardware): overall CPU/memory/storage state and alerting sensors.

Returns a structured object {host, sensor_count, summary:{green, yellow, red, unknown}, sensors:[{name, state, reading}]} — by default only non-green sensors are listed.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "host": "<host>"
    },
    "name": "vmware_host_health"
  }
}

Input Schema

Name	Required	Description	Default
`host`	Yes	Name of the ESXi host
`all_sensors`	No	List all sensors (default: only abnormal ones)

Output Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Jul 14, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=false. The description adds valuable behavioral details: it returns a structured object, by default only non-green sensors are listed, and details the summary with color counts. No contradictions; the description supplements annotations effectively.

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?

Two crisp sentences: first states purpose and equivalence, second details the return format. No fluff, essential information front-loaded. Every sentence adds value.

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?

Given two parameters, existence of output schema, and low complexity, the description is complete. It explains the return structure thoroughly and notes the default filtering. The presence of a separate output schema reduces burden; description aligns well.

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% with descriptions for both parameters. The description adds meaning by explaining the default behavior ('by default only non-green sensors are listed') and the return structure, which clarifies the purpose of 'all_sensors' without repeating schema. It adds context 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 clearly states it reports hardware health sensors of a host, equivalent to esxcli hardware. It provides a specific verb and resource (health sensors) and distinguishes from sibling tools like vmware_get_host (general host info) and other vmware_host_* tools by focusing solely on health sensors.

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?

The description mentions 'equivalent of esxcli hardware', providing context for when to use. However, it does not explicitly state when not to use or compare to alternatives like vmware_host_advanced_settings or vmware_get_host. The sibling tools are not directly conflicting, so implicit guidance is sufficient but lacks explicit exclusions.

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