hmc_delete_logical_unit

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

Beyond the destructiveHint annotation, the description discloses the asynchronous nature of the delete, that it submits a job and returns it, and that one should poll hmc_get_job. It also explains the wait=True blocking behavior and the existence of poll_interval/timeout parameters implicitly. This adds meaningful behavioral context not required by annotations.

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

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

The description is three sentences total, front-loaded with the primary action, then clarifying async behavior and wait option. Every sentence adds value and there is no fluff. It is concise yet informative.

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

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

The description covers the complete workflow: submitting an async job, returning it, polling for status, and optionally waiting for terminal state. It distinguishes from immediate delete tools and references the associated monitoring tool (hmc_get_job). Given the output schema exists, return values do not need explanation, making this sufficiently complete for a delete operation.

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

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

Schema coverage is 0%, so the description carries the burden. It explains that lu_udid is the UDID, cluster_uuid relates to the Cluster/SSP, and wait=True blocks until terminal state. However, poll_interval and timeout_seconds are not explicitly described, leaving the agent to infer their meaning from names. Partial compensation, but not full.

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

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

The description clearly states 'Delete a Logical Unit from a Cluster/SSP by its UDID', using a specific verb and resource. It distinguishes this from sibling delete tools like hmc_delete_lpar or hmc_delete_adapter by naming the logical-unit context (Cluster/SSP) and the UDID identifier.

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

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

The description provides context for when to use this tool: it is asynchronous ('Submits a DeleteLogicalUnit job and returns it') and explicitly contrasts with 'immediate delete tools'. It also mentions polling with hmc_get_job and the wait=True option, giving clear usage guidance without naming alternatives explicitly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.