ACTION_LOOP

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

With no annotations, the description usefully discloses non-obvious behavior: the body’s final next must point back to the loop, the loop node’s own next is the exit path, and counter_var resets to 0 after count mode. It also mentions interpolation and variable-snapshot JSON output, though failure and iteration-limit behavior are left to the schema.

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 compact, front-loaded with the purpose, and devotes nearly every sentence to invocation-critical behavior. The duplicated Chinese full stop and the slightly dense presentation are minor polish issues.

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?

Together with the fully described schema, the description covers the essential information needed to configure and wire this comparatively complex control-flow node, including output behavior despite the absence of an output schema. A small ambiguity remains between “输出：loop_index,” support for a custom counter_var, and the later statement that the result is a variable snapshot JSON.

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%, so the parameters are already well documented. The description adds meaningful lifecycle and structural semantics for body_node and counter_var, especially the required back-edge and post-loop counter reset, rather than merely repeating parameter definitions.

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 opening “计数或条件循环” clearly identifies the tool as a count-based or condition-based workflow loop, and the next sentence explains its body-versus-exit control flow. It does not explicitly differentiate itself from siblings such as ACTION_RETRY or CONDITION_SWITCH.

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 clear usage contexts—counted iteration and conditional iteration—and supplies essential wiring guidance for constructing a loop body. It does not state when not to use a loop or name an alternative for retries or ordinary conditional branching.

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