Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_aria_health

Read-onlyIdempotent

Check Aria Operations platform health per service and get version details. Receive a clear status: healthy, degraded, down, or unknown, along with service breakdowns.

Instructions

[READ] Check Aria Operations platform health, per service, plus its version.

Returns assessment: HEALTHY, DEGRADED (some services OK, some ERROR — the platform still answers), DOWN (no service OK) or UNKNOWN (breakdown unreadable). overall_status is the node's own flag: OFFLINE whenever any one service is not running, so OFFLINE alone is not an outage. Also services (name, health, details; null when unreadable), services_not_ok, healthy, system_time_ms, details, and product_version / product_line ("8.x", "9.x") / release_name — check the line before assuming 9.x-only tools (fleet_*, findings_list, promql_query) exist. A 503 is reported, never raised. If HEALTHY but data looks stale, check list_collector_groups.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoAria target name from config; default when omitted.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / target / description
      Added value: +"Aria target name from config; default when omitted."
  2. Addedv1.5.29
  3. Removedv1.5.28
  4. First observedv1.3.2

TDQS

A4.4/5.0
Behavior5/5

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

Beyond the annotations (readOnly, idempotent), it reveals important behavior: overall_status OFFLINE alone is not an outage, UNKNOWN means breakdown unreadable, a 503 is reported rather than raised, and it distinguishes stale data. This is exactly the non-obvious behavior an agent needs.

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 dense and front-loaded with the main purpose, then return semantics and edge cases. It is longer than a minimal description, but the extra clauses each carry operational value, especially given there is no output schema.

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 fully covers return values and their meanings, version format implications, error behavior, and stale-data follow-up. An agent has enough context to invoke and interpret the result correctly.

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%, and the parameter is self-explanatory ('Aria target name from config; default when omitted'). The tool description adds no parameter-level semantics, so the baseline of 3 applies.

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 specific verb and resource: 'Check Aria Operations platform health, per service, plus its version.' It also defines the four assessment states (HEALTHY, DEGRADED, DOWN, UNKNOWN), which clearly differentiates this platform-wide check from sibling tools such as get_resource_health and get_capacity_overview.

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?

It conveys when to use the tool: as a health/version check before relying on 9.x-only tools, and routes to list_collector_groups when HEALTHY data looks stale. It does not spell out a full when-not-to-use set, but the context is clear.

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