Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersScoreDiscussionsAdmin
Python
Remote

investigate_alert

Read-onlyIdempotent

Resolve an alert to its affected resource in a single call. Retrieve alert details, correlated resource, suggested next action, and warnings without manual chaining.

Instructions

[READ] Resolve one alert to its affected resource in a single call — use this instead of chaining get_alert then get_resource by hand.

Does the whole alert-to-object correlation server-side: fetches the alert, reads its resourceId, fetches that resource, and confirms the resource name and kind before suggesting anything downstream.

Returns five always-present keys: alert (Aria's values verbatim), resource (or null), correlation (both UUIDs labelled, plus confirmed name, kind and a confirmed flag), next_step (which vmware-monitor tool to call next, or null), and warnings (empty on success).

Gotchas: alert_id is the alert UUID from list_alerts, NOT the resource UUID — mixing them up is the most common error here; the correlation block labels each. An unresolvable resource degrades to a warning plus nulls rather than an error, so the alert is never lost. Never match the resource against vCenter inventory unless correlation.confirmed is true.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetNoAria target name from config; default when omitted.
alert_idYesThe alert UUID from list_alerts (not the resource UUID).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / alert_id / description
      Added value: +"The alert UUID from list_alerts (not the resource UUID)."
    • addedInput schema / properties / target / description
      Added value: +"Aria target name from config; default when omitted."
  2. Addedv1.8.9

TDQS

A4.7/5.0
Behavior5/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive, and the description adds significant behavioral context: it performs server-side correlation, returns five always-present keys, degrades unresolvable resources to warnings plus nulls rather than errors, and warns against matching inventory unless confirmed. This goes well beyond the structured annotations.

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 front-loaded with the primary purpose, then structured into what it does, what it returns, and gotchas. It is detailed because the tool has no output schema, but every sentence carries meaningful information and none are filler.

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 compensates by enumerating the five always-present return keys, the null behavior, the next_step guidance, and warning behavior. It covers edge cases and the most common misuse, making the tool self-contained for correct invocation.

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?

The input schema already documents alert_id as "The alert UUID from list_alerts (not the resource UUID)" and covers target with its default, so schema coverage is 100%. The description's gotcha restates this emphasis rather than adding genuinely new parameter 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+resource: "Resolve one alert to its affected resource in a single call." It clearly distinguishes itself from chaining get_alert and get_resource, which are sibling tools, so an agent can tell exactly what this tool does and what it replaces.

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?

It explicitly says to use this tool "instead of chaining get_alert then get_resource by hand," naming the exact alternatives and the condition favoring this tool. The gotchas also instruct where alert_id comes from and when correlation.confirmed must be true before matching against vCenter inventory.

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