Execute and wait for output (script or template)

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

Annotations already declare destructive=true, openWorld=true, idempotent=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: it blocks and polls until a terminal state, applies a timeout, and returns a filtered view of output rather than raw streaming. It omits that execution is gated behind confirm="YES" and that dry_run defaults to true, which are material for a destructive call, but the schema carries those.

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?

A single tightly-packed sentence with the core behavior front-loaded ('starts an action ... polls until terminal ... returns filtered output'). Every clause adds information and none is redundant with the title.

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?

With a fully-documented 14-parameter schema, an output schema, and rich annotations, the description only needs to convey the composite execution model, which it does. The remaining gap is that the destructive dry_run-then-confirm workflow is nowhere in prose, so an agent reading only the description could misjudge the call's risk profile.

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 100% across all 14 parameters, so the description does not need to re-document them. Its only parameter-adjacent content is the mode routing note, which merely restates the mode enum's own description. Baseline 3 applies since the schema does the heavy lifting.

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?

States a concrete composite action: starts an action (script auto-routed by OS, or a template), polls until terminal, and returns filtered output. That is a specific verb+resource chain that an agent can map to intent. It stops short of naming which sibling it replaces (e.g. action1_run_script plus action1_wait_for_automation), so differentiation is implied rather than explicit.

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?

'One-shot helper' hints that this is the fire-and-block convenience path versus splitting execution and polling across separate tools. However, there is no explicit when-to-use / when-not, no mention of how it relates to action1_run_script, action1_run_powershell, or action1_wait_for_automation, and no preconditions such as the needed confirm token.

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