hmc_power_on_vios

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

With no annotations provided, the description carries the full transparency burden. It discloses the asynchronous nature via the 'PowerOn job' reference and explains that wait=True blocks to a terminal state. However, it does not describe side effects, permission requirements, or behavior if the VIOS is already powered on. The job-related note adds some value, but other critical behavioral aspects remain undisclosed.

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 very concise, using two short sentences with no wasted words. It front-loads the purpose and then adds a focused note about the key parameter. A structured list of parameters would be clearer, but the brevity is effective.

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 tool has 4 parameters and no parameter documentation in the schema, so the description needs to cover them all to be complete. It only covers two of the four, leaving poll_interval and timeout_seconds undocumented. Additionally, it does not explain the job flow or expected behavior when wait=False. The presence of an output schema mitigates the need to describe returns, but the missing parameter semantics create a notable completeness gap.

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?

The schema has 0% description coverage, so the description must compensate. It explains vios_name_or_uuid (accepting name or UUID, with a pointer to hmc_vios) and wait (blocking behavior). However, poll_interval and timeout_seconds are left completely unexplained, despite having defaults in the schema. This leaves a significant gap for an agent trying to use the tool correctly.

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 'Power on a VIOS' with a specific verb and resource, and the (PowerOn job) qualifier adds precision. It distinguishes from sibling tools like hmc_power_off_vios and hmc_power_on_lpar by targeting VIOS specifically.

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 gives some usage guidance by explaining how to identify the VIOS ('vios_name_or_uuid: accepts either a PartitionName or a UUID (find it with hmc_vios)') and how to use the wait parameter. However, it does not explicitly state when to use this tool versus alternatives like hmc_power_on_system or hmc_power_off_vios, nor does it mention prerequisites or excluded scenarios.

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