Loading ToolBench
A TCP-based protocol server for Unreal Engine that enables remote function invocation, blueprint editing, material graph manipulation, Niagara system editing, and widget tree serialization through JSON-RPC style requests.
UCP is a custom TCP protocol for Unreal Engine asset manipulation. Tool definitions are present with descriptions and basic schemas, but fall short of production quality. Descriptions are adequate (100-150 chars avg) but lack LLM-optimized guidance on WHEN to use each tool vs alternatives. Parameter schemas are incomplete: many lack type constraints, enums, or validation rules. No error handling guidance. No tool annotations (readOnlyHint/destructiveHint). Risk classifications are declared but not integrated into responses. Output schemas are undocumented. The 16 tools cluster into 4 asset-type groups (Blueprint, Material, Niagara, Widget) with significant duplication of list/read/write patterns, naming does not clearly distinguish when to use one over another.
Invokes a UFunction on a UObject by path and function name with optional parameters. Supports log capture at configurable verbosity levels and security policy enforcement.
Creates a new Function or Macro section in a Blueprint.
Returns the signature and parameter information for a UFunction without invoking it.
Lists all available sections for a Material or MaterialFunction asset.
Lists all available sections for a Niagara System, Emitter, or Script asset.
Lists all available sections (graphs, properties, variables) for a Blueprint asset.
Lists the WidgetTree section for a Widget Blueprint.
Reads a specific section (EventGraph, Function, Macro, or Variables) from a Blueprint and returns its intermediate representation.
Output schemas undocumented. No tool returns a documented schema, LLMs cannot predict what fields to expect or plan downstream calls. E.g., ReadBlueprintSection returns 'intermediate representation' but structure is opaque.
No tool annotations. Risk classifications (READ_ONLY, WRITE, DESTRUCTIVE, IRREVERSIBLE) are declared but not exposed as readOnlyHint/destructiveHint in tool metadata. LLMs cannot infer safety properties.
Parameter schemas lack type constraints and enums. 'type' param in ReadBlueprintSection accepts 'EventGraph|Function|Macro|Variables' but no enum constraint. 'log_level' in CallUFunction lists values in description, not as enum. LLMs hallucinate invalid values.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 46 | 2026-07-28+ | v2 |
Reads a Material section (Properties, Material, or Composite) and returns its intermediate representation.
Reads a Niagara section (SystemProperties, Emitters, UserParameters, graphs, etc.) and returns its intermediate representation.
Reads the widget tree structure from a Widget Blueprint and returns it as serialized text.
Removes a Function or Macro section from a Blueprint.
Writes changes to a Blueprint section (graph or variables) and returns a diff result showing what was modified.
Writes changes to a Material section and returns a diff result.
Writes changes to a Niagara section and returns a diff result.
Writes changes to a widget tree structure and returns a diff result.
Naming ambiguity across asset types. ListSections, ListMaterialSections, ListNiagaraSections, ListWidgetTreeSections are four separate tools doing the same thing on different asset types. LLMs cannot distinguish which to call without asset-type context. Should be unified or clearly differentiated.
No error handling guidance. Descriptions do not explain what errors can occur, how to recover, or what to try next. E.g., RemoveBlueprintSection does not document 'section not found' or 'in-use' errors.