Skip to main content
Glama
miracle1814

ue5-automation

by miracle1814
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Local

ue5_build_blueprint

Create a complete Unreal Blueprint in one atomic call, including assets, variables, components, interfaces, events, functions, and connections, with automatic rollback if any step fails.

Instructions

Create a Blueprint from scratch in one atomic call: asset + variables + components + interfaces + events + function nodes + connections + optional compile. If any step fails, assets created by this call are rolled back. spec fields: blueprint_name (or name), package_path, parent_class, variables[{name,type,default_value,category}], components[{name,component_class,properties}], interfaces[str], events[{event_name|name,pos}], functions[{function_name|name, target_class, function_path, defaults:{pin:val}, pos}], connections[{src_node,src_pin,dst_node,dst_pin}], compile_after. Node references accept 32-hex GUIDs (recommended) or titles. | 创建蓝图（原子化：失败回滚已建资产）。

Input Schema

NameRequiredDescriptionDefault
specYesBlueprint build spec (see description for fields) | 蓝图构建规格，字段见描述
session_idNoOptional session/owner for asset lock checks | 可选：会话标识（多 Agent 资产锁）
idempotency_keyNoOptional idempotency key; a repeated key within 10 min replays the prior success | 可选：幂等键（10 分钟内重放上次成功结果）

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv6.5.4
    • addedInput schema / properties / idempotency_key
      Added value: +{
+  "description": "Optional idempotency key; a repeated key within 10 min replays the prior success | 可选：幂等键（10 分钟内重放上次成功结果）",
+  "type": "string"
+}
    • addedInput schema / properties / session_id
      Added value: +{
+  "description": "Optional session/owner for asset lock checks | 可选：会话标识（多 Agent 资产锁）",
+  "type": "string"
+}
  2. Changed1 schema field changedv3.2.1
    • addedInput schema / properties / spec / description
      Added value: +"Blueprint build spec (see description for fields) | 蓝图构建规格，字段见描述"
  3. First observedv3.2.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations present, the description carries the full burden and does well: it discloses atomicity, that assets created by the call are rolled back on any failure, and that compile is optional via compile_after. It omits permissions/lock semantics (only partially hinted by session_id) and gives no indication of cost or runtime for large specs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with purpose and the atomicity guarantee, then a compact field enumeration with no filler sentences. The single dense run-on spec list is efficient for machine reading but not maximally scannable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex nested-spec creation tool with no output schema, it covers the creation contract, rollback behavior, and spec shape thoroughly. The main gap is that it never says what a successful call returns (asset path, node GUIDs for follow-up calls), which matters because node references downstream need GUIDs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema only says 'Blueprint build spec (see description for fields)', so the description is the sole source of meaning and it delivers: full field list with nested structure, alternate accepted names (blueprint_name|name, event_name|name), and the node-reference rule that 32-hex GUIDs are recommended over titles. This goes well beyond what the structured schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Create a Blueprint') and adds the key differentiator 'from scratch in one atomic call', which separates it from siblings like ue5_apply_blueprint_graph and ue5_compile_blueprint. It also enumerates exactly what is created (asset, variables, components, interfaces, events, functions, connections).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The 'from scratch' framing makes the intended context clear: full blueprint creation rather than graph edits on an existing asset. It does not explicitly name alternatives or exclusions (e.g., use ue5_apply_blueprint_graph to modify an existing blueprint), so the agent must infer the boundary rather than being routed by name.

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

Deploy Server

Other Tools