Skip to main content
Glama

iaas_delete_load_balancer_operation

Delete an IaaS load balancer by ID, with an optional force-delete flag to remove resources when standard deletion cannot complete.

Instructions

Delete operation for load balancer Second day delete operation for load balancer POST /iaas/api/load-balancers/{id}/operations/delete

Input Schema

NameRequiredDescriptionDefault
idYesThe ID of the load balancer. (path)
apiVersionNoThe version of the API in yyyy-MM-dd format (UTC). For versioning information refer to /iaas/api/about
forceDeleteNoControls whether this is a force delete operation. If true, best effort is made for deleting this load balancer. Use with caution as force deleting may cause inconsistencies between the cloud provider and VMware Aria Automation.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

C2.5/5.0
Behavior2/5

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

The description only says 'delete', while the annotations declare destructiveHint=false and idempotentHint=false — deleting a load balancer is inherently destructive, so the text is in tension with the declared safety profile. Nothing is said about asynchronous completion, request tracking, or how forceDelete interacts with cloud-provider inconsistency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short, but the first two lines are near-duplicates ('Delete operation for load balancer' / 'Second day delete operation for load balancer'), and the raw path is redundant with the title. Front-loaded yes, but with wasted repetition and undefined terminology.

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

Completeness2/5

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

For a destructive, non-idempotent, open-world async operation with no output schema, the description should at least say that it returns/queues an operation task and what state the load balancer ends in. Neither the async nature nor the difference from iaas_delete_load_balancer is covered.

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 coverage is 100% (id, apiVersion, forceDelete are all documented, including the force-delete caveat), so the schema already carries parameter meaning. The description contributes nothing about parameters beyond restating the delete intent, which is the expected baseline here.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

It says this is a delete operation for a load balancer and gives the underlying POST path, which conveys a verb and resource. But it never distinguishes itself from the sibling iaas_delete_load_balancer, and 'Second day delete operation' is unexplained jargon that leaves the difference between the two delete tools unclear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this operation versus iaas_delete_load_balancer, iaas_scale_load_balancer, or the other load-balancer operations, and no prerequisites (e.g. read-only mode, quiescing, or existing async task) are given.

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