set_node_pin_value

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

With no annotations provided, the description carries the behavioral burden and does a good job: it discloses the mutation, the unconnected-pin precondition, the string-format requirement for value, and concrete literal syntaxes for Boolean, Float, Integer, String, Vector, and Rotator. It could still say what happens if the precondition is violated or whether an existing default is silently overwritten.

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 well-structured: purpose, analogy, value syntax examples, args, optional KB reference, and a call example. It is compact and front-loaded. The minor type inconsistency in the example and the somewhat optional KB pointer prevent a perfect score.

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 5-parameter tool with no schema descriptions, this definition covers requirements, defaults, parameter meaning, type formats, and constraints. Since an output schema exists, not describing return values is acceptable. The main gaps are the behavior when the pin is connected and the inconsistent example value type.

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%, so the Args block is the main semantic source. It usefully explains node_id as 'Node GUID or short object name', value as a string with per-type examples, and graph_name's default. The example's numeric value=0.0 slightly conflicts with the instruction that value is a string, which keeps this from a top score.

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 clearly identifies the operation: set a literal default value on an unconnected pin. It adds meaningful precision by contrasting with connected pins and comparing it to typing into an exposed pin field in the Blueprint editor. However, it does not explicitly differentiate itself from the very similar sibling tool bp_set_pin_default.

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 context: this is for unconnected pins and represents typing a value directly into the exposed pin field. It states the critical precondition that the pin must NOT be connected, which is an implicit when-not-to-use signal. It does not name alternatives or state what to do when the pin is already connected.

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