run_provisioning_workflow

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

Annotations are absent, so the description carries the full burden. It does disclose two behavioral traits: automated step tracing and failure rollback. However, it does not explain what the rollback entails, whether the operation is idempotent, or how results are reported (e.g., task ID, blocking vs async), which are relevant for a provisioning tool.

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 a single, efficient sentence with no fluff. It is front-loaded with the action and key qualifiers, and every phrase ('multi-step', 'VM or LXC container', 'automated step tracing', 'failure rollback') adds value.

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 13 parameters, no annotations, and no output schema, so the description should provide substantial context. It does not explain return behavior, the meaning of 'multi-step' in practical terms, or the relationship between parameters and the provisioning flow. This is insufficient for an agent to correctly invoke the tool beyond basic recognition.

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 description coverage is 0%, and the description adds no parameter-level meaning. It does not mention 'node', 'name', 'resource_type', 'template_id', or any of the 13 parameters, leaving their roles entirely unexplained. The tool name and vague 'provisioning' do not compensate for the lack of parameter semantics.

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 states a clear verb ('Execute') and resource ('multi-step VM or LXC container provisioning'), specifying that it handles both VM and LXC container provisioning. It does not explicitly differentiate from sibling tools like create_vm or create_container, but the 'multi-step' and 'workflow' nature suggests a higher-level operation, which is reasonable.

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?

There is no guidance on when to use this tool versus alternatives such as create_vm or create_container, nor any exclusions or prerequisites. The description does not mention conditions like requiring an existing template or when a multi-step workflow is appropriate.

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