Skip to main content
Glama
vmware-skills

VMware-Monitor

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

get_vm_performance

Read-onlyIdempotent

Monitor real-time CPU, memory, disk, and network utilization per VM to rank load and identify performance bottlenecks.

Instructions

[READ] Real-time CPU/memory/disk/network utilisation per virtual machine.

Returns the list envelope with a real total (VMs that reported metrics) — with the default limit of 25, truncated tells you whether more VMs sit behind it. LIVE data (cpu_usage_pct, mem_usage_pct, mem_consumed_mb, mem_ballooned_mb, mem_swapped_mb, disk_read_kbps, disk_write_kbps, net_kbps), busiest first. mem_usage_pct is mem.usage.average — ACTIVE guest memory over configured, not consumed, so it can read low on a VM under pressure; non-zero mem_ballooned_mb (mem.vmmemctl.average) or mem_swapped_mb (mem.swapped.average) is the pressure signal. counters names the counter behind every field. Only powered-on VMs have a real-time provider; powered-off VMs are skipped. Point-in-time only.

Use this to rank load across VMs; for one VM's configuration use get_vm_info, and to see the same VM correlated with its host, alarms and events use investigate_vm.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax VM rows to return (default 25; None = all).
targetNovCenter/ESXi target from config (default if omitted).
vm_nameNoFilter to a single VM by exact name (None = all powered-on VMs).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.2.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial behavior beyond them: only powered-on VMs (no real-time provider) are returned, results are point-in-time, ordering is busiest-first, the list envelope carries total/truncated, and it discloses a metric pitfall (mem_usage_pct can read low under pressure; balloon/swapped are the real pressure signals) plus a counters field mapping.

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?

The '[READ]' tag front-loads the operation type and the rest is dense with no filler, though the mem_usage_pct/counters passage is long enough to slightly dilute the core routing message. Every sentence carries actionable information, so nothing is truly wasted.

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?

No output schema exists, yet the description fully explains the return shape (list envelope with real total and truncated, named live fields, counters mapping) and the powered-off exclusion. An agent has everything needed to call and interpret it.

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; however the description adds meaning beyond the schema by tying the default limit of 25 to the 'truncated' flag semantics and clarifying that an omitted vm_name covers all powered-on VMs, which the schema does not state.

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+resource ('Real-time CPU/memory/disk/network utilisation per virtual machine') and explicitly distinguishes itself from siblings by naming get_vm_info and investigate_vm with their respective scopes. An agent can select it correctly 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?

Gives explicit routing: 'Use this to rank load across VMs; for one VM's configuration use get_vm_info, and to see the same VM correlated with its host, alarms and events use investigate_vm.' Names the alternatives and the condition selecting each.

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