bp_add_for_loop_with_break_node

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

The description labels graph_name as 'Graph to mutate,' making it clear that this is a write/mutation operation. However, with no annotations available, it does not disclose post-insertion behavior such as whether the node is added unconnected, whether the graph needs recompilation, or what the tool returns, leaving some behavioral detail to inference.

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 front-loaded with the core purpose, then uses compact labeled sections for pins, usage, args, KB, and example. No sentence is filler; the pin list and example earn their place by making the node structure and invocation concrete.

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 single-required-param node-adding tool, the description is nearly self-sufficient: it defines all optional params, gives a decision rule, and provides a complete call example. Since an output schema exists, the lack of explicit return-value prose is not a significant gap; the only real omission is the later wiring workflow for the added node.

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%, but the Args section explains every parameter: blueprint_name as asset name/path, graph_name default EventGraph, index defaults, and node_position as optional [X, Y]. The example reinforces parameter ordering and invocation, so the description substantially compensates for the schema's missing annotations.

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 sentence names the exact operation and resource: adding a ForLoopWithBreak macro node to a Blueprint graph. The pin list and the phrase 'instead of a fixed ForLoop' further disambiguate it from adjacent node-adding tools such as add_blueprint_for_loop_node.

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 explicitly says to use this tool 'when generated loop logic needs an early exit path' and contrasts it with 'a fixed ForLoop,' giving an agent a clear decision rule against the most likely sibling. This is direct, actionable guidance rather than an implied or absent usage note.

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