Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

list_rightsizing_recommendations

Read-onlyIdempotent

Get VM rightsizing recommendations: recommended CPU, memory, and disk sizes with direction and actionability. Use this to identify oversized or undersized VMs and plan capacity adjustments.

Instructions

[READ] List VM rightsizing data — recommended CPU/memory/disk size per VM, with units, direction and whether to act.

Reads the three OnlineCapacityAnalytics recommendedSize metrics, the only rightsizing signal the public API publishes, on both 8.x and 9.x. Get VM UUIDs from list_resources. One bulk stats call and one bulk properties call cover the whole page.

Read sizing_status before quoting any number: recommendation — recommended_* carry sizes. reclaimable — the engine publishes 0 for a VM it holds reclaimable. That is NOT a recommendation to size it to zero, and recommended_* are null here. none_published — the VM needs no resizing OR analytics never scored it. The appliance does not distinguish these two; do not report it as either one.

Units: recommended_* are raw MHz / KB / GB (see recommended_units) — never quote the CPU number as vCPUs. Use recommended_vcpus (MHz converted with the VM's own host core speed, rounded up) against current_vcpus, and recommended_memory against current_memory_kb. cpu_direction / memory_direction are oversized / undersized / right_sized, or null when the current size is not published. Disk has no direction.

Powered-off VMs and templates are listed, not dropped: check power_state, is_template and actionable (true only for a powered-on non-template VM whose CPU or memory is off its recommendation), and read caveats before recommending a change. Vendor appliances (vCenter, Aria, NSX...) cannot be identified reliably — product_name appears only when the VM publishes a vApp product — so every reduction carries a caveat to check the vendor minimum size first. aria_verdict is the engine's own summary|oversized / undersized statistics; a caveat flags when it disagrees with recommendedSize.

This is not the number the vendor UI's Rightsize page shows — that view presents allocated plus a suggested delta, not the absolute recommended size. Both are correct and they will not match.

Before acting on a recommendation, read recommendation_stable. Each row carries recommendation_range — {window_days: 7, days_with_data, cpu_mhz, memory_kb, diskspace_gb}, each a [daily low, daily high] pair — and recommendation_stable: false when CPU or memory moved by more than 5% of its high over the window (the row is then not actionable and a caveat names the range), null when no history came back. Quote days_with_data with it: the appliance may hold fewer days than the window.

Returns a paginated envelope: items, returned, limit, total (null when the API reports no size), truncated, hint, properties_note, history_note. Check truncated before calling this the complete set. properties_note is null unless the VM property read failed; then power_state, is_template and current sizes are null because they are UNKNOWN (not unpublished) and no row is actionable. history_note is null unless the history read failed; then recommendation_range and recommendation_stable are null (unknown) and actionable is decided without them.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum VMs to evaluate when listing (1–100). Default 50.
targetNoAria target name from config; default when omitted.
resource_idNoOptional VM resource UUID to scope to a single VM.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / limit / description
      Added value: +"Maximum VMs to evaluate when listing (1–100). Default 50."
    • addedInput schema / properties / resource_id / description
      Added value: +"Optional VM resource UUID to scope to a single VM."
    • addedInput schema / properties / target / description
      Added value: +"Aria target name from config; default when omitted."
  2. Changed1 schema field changedv1.8.9
    • changedOutput schema / (root)
      Previous value: -{
-  "properties": {
-    "result": {
-      "items": {
-        "additionalProperties": true,
-        "type": "object"
-      },
-      "title": "Result",
-      "type": "array"
-    }
-  },
-  "required": [
-    "result"
-  ],
-  "title": "list_rightsizing_recommendationsOutput",
-  "type": "object"
-}New value: +null
  3. Addedv1.5.29
  4. Removedv1.5.28
  5. First observedv1.3.2

TDQS

A4.4/5.0
Behavior5/5

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

Annotations already declare readOnly, idempotent, and non-destructive behavior, so the bar is lower. The description goes far beyond that: it discloses that powered-off VMs and templates are included, product_name is unreliable for vendor appliances, recommendation_stable can be null, history reads can fail and null out fields, and that properties_note appears only on partial read failures. It also warns that the API result will not match the vendor UI number. This is exemplary disclosure of behavioral edge cases.

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 description is very long, but the length is justified by the absence of an output schema and the many genuine pitfalls (null semantics, unit conversions, pagination, vendor caveats). It is front-loaded with a clear purpose statement and then systematically addresses interpretation, units, edge cases, and return-envelope fields. It is not concise in absolute terms, but every major section earns its place given the complexity.

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 carries full responsibility for explaining the response envelope: items, returned, limit, total, truncated, hint, properties_note, history_note. It explains null semantics for total, properties_note, history_note, recommendation_range, and recommendation_stableedited. It covers units, direction values, actionable criteria, and vendor caveats. An agent has enough context to call the tool and correctly interpret almost every field without external documentation.

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?

Input schema description coverage is 100%, so the schema already documents limit, target, and resource_id with defaults and meanings. The description adds minor context, such as using list_resources for VM UUIDs and 'one bulk stats call and one bulk properties call cover the whole page,' but it does not add significant semantic meaning beyond the schema. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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 first sentence states a specific verb and resource: 'List VM rightsizing data — recommended CPU/memory/disk size per VM, with units, direction and whether to act.' It further differentiates the tool by noting it reads the only three rightsizing metrics the public API publishes, and explicitly contrasts its output with the vendor UI's Rightsize page. This clearly distinguishes it from sibling alert, anomaly, and capacity tools.

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 gives extensive procedural guidance: read sizing_status before quoting numbers, never treat reclaimable 0 as a zero-size recommendation, check power_state/is_template/actionable, read caveats, and consult recommendation_stable before acting. It also tells the caller to get VM UUIDs from list_resources. However, it does not explicitly name alternative sibling tools or state when this tool should be preferred over them; the guidance is mostly internal to this tool's output interpretation rather than cross-tool routing.

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