ACTION_DELAY

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

With no annotations, the description carries the full burden. It does add real behavioral value by disclosing that string parameters accept ${var} interpolation and that results come back as a variable-snapshot JSON, but it never says the call blocks execution or how on_error/require change control flow, which are the most consequential behaviors for a delay node.

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?

It is short and front-loads the core purpose plus the sibling routing rule. It loses a point for a stray doubled punctuation ('。。') and for compressing three unrelated facts into one run-on line.

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?

For a four-parameter, zero-required utility with no output schema, the description covers purpose, the size limit alternative, interpolation, and the return shape — enough to call it correctly. The gaps around blocking semantics and require/on_error behavior keep it from a 5.

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 100%, including the 60000 ms cap/truncation and the ms alias, so the schema already documents the parameters. The description only restates the ${var} interpolation support at a general level, adding little beyond the schema; baseline 3 applies.

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 specific verb and resource (pause for a given number of milliseconds) and explicitly names the sibling it is not for long waits (ACTION_WAIT_UNTIL_TIME), so an agent can distinguish it from the other wait/action tools without opening any schema.

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?

It gives an explicit routing rule: waits longer than 60 seconds should use ACTION_WAIT_UNTIL_TIME instead. That is clear alternative-selection guidance, though the description does not discuss when a delay is inappropriate altogether or how it interacts with retry/loop nodes.

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