Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

list_rightsizing_recommendations

Read-onlyIdempotent

Get VM rightsizing recommendations for CPU, memory, and disk capacity, then compare them against provisioned sizes to detect over- or under-provisioning and plan resizing.

Instructions

[READ] List VM rightsizing data — recommended CPU/memory/disk size per VM.

Reads the three OnlineCapacityAnalytics recommendedSize metrics, the only rightsizing signal the public API publishes, on both 8.x and 9.x. Compare against the VM's provisioned size to find over/under-provisioning. Get VM UUIDs from list_resources. One bulk stats call covers 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.

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.

Returns a paginated envelope: items, returned, limit, total (null when the API reports no size), truncated, hint. Check truncated before calling this the complete set.

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.5/5.0
Behavior5/5

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

The description goes far beyond the annotations by explaining nuanced behaviors: sizing_status semantics, the reclaimable zero-value caveat, the none_published ambiguity, the difference from the vendor UI calculation, and the paginated envelope with truncation. These details prevent serious misinterpretation and are not inferable from readOnlyHint or idempotentHint.

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?

The description is longer than average but every section earns its place: a one-line summary, metric source, usage pointer, critical sizing_status interpretation rules, a UI comparison warning, and return envelope details. It is front-loaded and uses bullets to keep the caveats scannable.

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 there is no output schema, the description fully compensates by explaining the return envelope fields and the need to check truncated. It also covers the three sizing_status states, how to obtain target VMs, and the API's limitations, making the tool safely callable in a standalone manner.

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 the baseline is 3. The description adds context around resource_id by pointing to list_resources for VM UUIDs and mentions pagination, which relates to limit, but it does not materially expand parameter semantics beyond what the schema already documents.

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 opening line states a specific verb and resource: 'List VM rightsizing data — recommended CPU/memory/disk size per VM.' It further clarifies the exact metrics read and notes this is the only rightsizing signal the public API publishes, which distinguishes it from sibling tools that handle resources, alerts, or capacity.

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 clear context on when to use the tool: to compare recommendations against provisioned size, with UUIDs obtained from list_resources. It also provides explicit operational guidance around sizing_status and warns against treating the API output as matching the vendor UI's Rightsize page, though it does not explicitly enumerate exclusions such as 'use get_resource_metrics instead for raw metrics.'

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

Install Server

Other Tools