bp_set_pin_default

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

With no annotations, the description carries the full burden. It discloses the key behavioral constraint (unconnected pins only, rejection if connected), provides value formats for various types, and states the return format (JSON string with StructuredResult and output fields). It does not cover all potential failure modes (e.g., invalid value syntax, non-input pins), but it covers the most important behaviors for successful use.

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-organized: purpose, usage, value formats, args, return, KB reference, and example. It is front-loaded with the core purpose. While a bit long, every section earns its place—value formats and the example are not filler. It could be tightened slightly, but the structure is logical and scannable.

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 tool with 5 parameters, no annotations, and an output schema, the description is remarkably complete. It explains all parameters, gives value formats for all supported types, describes return structure, includes a knowledge-base reference and a working example. An agent has everything needed to call it correctly without referring to external docs.

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 description must compensate fully. It does: each parameter is explicitly described in the Args block (blueprint_name, node_id, pin_name, default_value, graph_name), with hints like 'Exact pin name (from bp_inspect_node output)' and formats for default_value. This goes well beyond the bare schema titles, giving the agent everything needed to populate values correctly.

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 starts with a specific verb+resource: 'Set the default/literal value for an unconnected input pin.' It gives concrete examples (Duration on Delay, In String on PrintString) and explicitly contrasts with the sibling tool set_node_pin_value by stating the unconnected-pin restriction, making it unmistakable what this tool does and how it differs.

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 clearly states 'Only works on unconnected input pins' and explains why (if connected, set_node_pin_value will be rejected by UE5). It provides use cases with examples. However, it does not explicitly name an alternative tool for connected pins (set_node_pin_value is mentioned only in the rejection context), leaving the agent to infer that a different tool handles connected pins.

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