Skip to main content
Glama
vmware-skills

vmware-aria

by vmware-skills
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

fleet_domain_list

Read-onlyIdempotent

Lists the SDDC/workload domains for a registered VCF integration in VMware Aria Operations. Provide the integration UUID to get domain summaries with status and configuration state, so you can identify live domains.

Instructions

[READ] List the SDDC/workload domains behind one registered VCF integration.

Use this to enumerate the domains of a VCF integration registered in Operations. The integration_id is the UUID shown under Administration -> Integrations -> VCF in the Operations UI; the operator supplies it (this skill does not list VCF integrations). Returns domain summaries (id, name, type, status, configuration_state) in the paginated envelope, where configuration_state is configured / not_configured / removed — a removed domain is not a live one. A 404 means the integration_id is wrong — copy the exact UUID from the Operations Integrations page. Gotcha: if the envelope carries a "note", the appliance answered in a shape this tool did not recognise and an empty items list means UNKNOWN, not "no domains" — do not report the fleet as domain-free in that case.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
limitNoMax domains to return (default 50; None returns all).
targetNoAria/VCF Operations target name from config; default when omitted.
integration_idYesUUID of the registered VCF integration.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.10.0
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / properties / integration_id / description
      Added value: +"UUID of the registered VCF integration."
    • addedInput schema / properties / limit / description
      Added value: +"Max domains to return (default 50; None returns all)."
    • addedInput schema / properties / target / description
      Added value: +"Aria/VCF Operations target name from config; default when omitted."
  2. Addedv1.8.10

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses the paginated return envelope, the exact domain summary fields, the meaning of configuration_state values, the 404 behavior for a wrong integration_id, and the critical 'note' gotcha where an empty list means UNKNOWN rather than no domains. This is rich behavioral disclosure that significantly helps an agent interpret results correctly.

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 dense but every sentence earns its place: intent, source of the required parameter, return fields, error semantics, and the critical empty-list gotcha. The '[READ]' prefix and front-loaded purpose make scanning easy, and there is no redundant 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 returned fields, status values, pagination behavior, and error cases. It also warns about the ambiguous empty-response case, which is exactly the kind of contextual information an agent needs to avoid misreporting results.

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 documents all three parameters with 100% coverage, so the baseline is 3. The description adds valuable context for integration_id by pointing to the exact UI location for the UUID and explaining the 404 meaning, going beyond the schema's 'UUID of the registered VCF integration'.

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 starts with '[READ] List the SDDC/workload domains behind one registered VCF integration', using a specific verb and resource. It clearly distinguishes this tool from siblings like fleet_certificate_list and fleet_password_account_list by scoping it to VCF integration domains, so an agent can select it without ambiguity.

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 explicitly says 'Use this to enumerate the domains of a VCF integration registered in Operations' and explains that the integration_id must be supplied by the operator because 'this skill does not list VCF integrations'. It provides clear context and a practical exclusion, though it does not name alternative tools for when this tool is not appropriate.

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