Skip to main content
Glama
vmware-skills

VMware-Monitor

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

datastore_capacity

Read-onlyIdempotent

Detect datastores at risk of running out of space by checking thin-provisioning overcommit and free capacity. Returns riskiest datastores first.

Instructions

[READ] Per-datastore capacity with thin-provisioning over-commit.

Returns the list envelope with a real total: capacity_gb, free_gb, committed_gb, provisioned_gb, used_pct, overcommit_pct, riskiest first. Adds the risk signal list_all_datastores lacks — overcommit_pct over 100% means more space is promised to VMs than physically exists, so a thin datastore can fill up while still showing free space. Point-in-time.

Whose figure: view (vCenter / ESXi host / unknown) and view_note. Provisioned space is summed by the endpoint over the VMs it has registered on the datastore, so a vCenter and a directly-reached ESXi host can report different provisioned_gb for one datastore — each row's vm_count says how many VMs the figure covers, and vms_not_connected names those reported as orphaned/inaccessible/disconnected (None = could not be read).

Use this for the capacity view, then datastore_investigation_bundle to drill into a specific datastore's hosts, VMs and alarms. Reclaiming space (delete snapshots, storage vMotion) belongs to vmware-aiops.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax datastore rows to return (None = all).
targetNovCenter/ESXi target from config (default if omitted).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.9.2
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / description
      Added value: +"Max datastore rows to return (None = all)."
    • addedInput schema / properties / target / description
      Added value: +"vCenter/ESXi target from config (default if omitted)."
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "datastore_capacityOutput",
-  "type": "object"
-}New value: +null
  2. Addedv1.6.1

TDQS

A4.7/5.0
Behavior5/5

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

Annotations declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true. The description adds substantial behavioral context beyond this: 'Point-in-time.' explains the snapshot nature; it details how provisioned_gb is summed and may differ between vCenter and ESXi; it clarifies the meaning of overcommit_pct >100% and the vm_count/vms_not_connected fields. This significantly enriches the agent's understanding of what to expect, especially the inconsistency between views.

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?

Although the description is longer than average, it is well-structured with distinct sections: purpose, return fields, caveats about view differences, and usage routing. Every sentence adds value—no filler. It front-loads the core purpose and then layers caveats and alternatives logically. The structure aids comprehension and efficient scanning.

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?

For a read-only tool with no output schema, the description covers all essential aspects: return fields and their meaning, the key risk signal, the view-dependent inconsistency, and the recommended follow-up tool. It also notes the point-in-time nature and what is not covered. An agent has enough to correctly invoke the tool and interpret results. No gaps remain.

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%, so both parameters (limit and target) already have clear descriptions in the schema. The tool description does not add additional parameter-level detail beyond what the schema provides. The baseline of 3 is appropriate because the schema carries the burden, and the description focuses on output and usage rather than parameters.

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 clear purpose: 'Per-datastore capacity with thin-provisioning over-commit.' It explicitly differentiates from list_all_datastores by noting it adds the risk signal overcommit_pct, which is a concrete distinction from a sibling. The verb and resource are specific, and the scope is unambiguous.

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 description provides explicit usage guidance: 'Use this for the capacity view, then datastore_investigation_bundle to drill into a specific datastore...' and clearly states what belongs elsewhere ('Reclaiming space ... belongs to vmware-aiops'). It also explains the data source caveat (vCenter vs ESXi view), which helps an agent choose the right tool. This is clear when-to-use and when-not-to-use guidance.

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