Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

findings_list

Read-onlyIdempotent

Review diagnostic findings across the environment filtered by severity, category, or type. Identify misconfigurations and health rule hits with summarized results for operational issue tracking.

Instructions

[READ] List Operations diagnostic findings, optionally filtered.

Use this to review current diagnostic findings (misconfigurations, health rule hits) across the environment. Filters are comma-separated strings; omit a filter to match all. Returns finding summaries (rule_uuid, name, severity, category, finding_type, affected_objects_count) in the paginated envelope. Note: these are general operational findings, NOT compliance benchmark results — for hardening/compliance use vmware-harden.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax findings to return (default 50; None returns all).
targetNoAria/VCF Operations target name from config; default when omitted.
categoriesNoComma-separated category filter.
severitiesNoComma-separated severity filter, e.g. "CRITICAL,WARNING".
finding_typesNoComma-separated findingType filter.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / categories / description
      Added value: +"Comma-separated category filter."
    • addedInput schema / properties / finding_types / description
      Added value: +"Comma-separated findingType filter."
    • addedInput schema / properties / limit / description
      Added value: +"Max findings to return (default 50; None returns all)."
    • addedInput schema / properties / severities / description
      Added value: +"Comma-separated severity filter, e.g. \"CRITICAL,WARNING\"."
    • addedInput schema / properties / target / description
      Added value: +"Aria/VCF Operations target name from config; default when omitted."
  2. Addedv1.8.10

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish readOnly, idempotent, and non-destructive behavior, so the description only needs to add context beyond that. It adds useful behavioral details: filters are comma-separated, omitted filters match all, and results arrive as finding summaries in a paginated envelope. This gives the agent a realistic expectation of output shape without contradicting the 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 compact and front-loaded: the first sentence states the action and resource, the next gives usage context, then filter behavior, return shape, and a useful compliance disclaimer. Every sentence earns its place, and there is no redundant restatement of schema fields.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with no output schema, the description does a good job: it names the returned fields, mentions pagination, and explains filter semantics. The main gap is that the paginated envelope is not further described (e.g., how to request subsequent pages), but the optional limit parameter and schema already cover enough for a first invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already covers 100% of parameters with clear descriptions, so the baseline is 3. The description adds semantic value by explaining the shared filter convention ('comma-separated strings; omit a filter to match all') and states what the returned summaries contain, which helps the agent reason about how the optional filters map to results. This exceeds the baseline.

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 pair — 'List Operations diagnostic findings' — and clarifies the domain by naming example content ('misconfigurations, health rule hits') and the returned summary fields. It also explicitly distinguishes this tool from compliance benchmark results, which prevents confusion with a closely related category. The purpose is unambiguous even without sibling-specific comparison.

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 says clearly when to use the tool ('review current diagnostic findings') and gives an explicit exclusion ('NOT compliance benchmark results') with a routing suggestion to vmware-harden. However, it does not contrast this tool with nearby siblings such as list_alerts, list_anomalies, or investigate_alert, leaving some alternative-selection work to the agent.

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