Skip to main content
Glama

create_blueprint

Create and save a new Unreal Engine Blueprint asset under a chosen parent class, including Function and Macro Libraries, while refusing overwrites and blocking during PIE.

Instructions

Create a new Blueprint asset, optionally as a child of ANY parent class -- native or another Blueprint (pass its "..._C" class or asset path) -- and save it to disk immediately unless PIE is running. Also makes Blueprint Function Libraries and Macro Libraries, which have no Actor parent and which the normal path would reject. It does NOT create interfaces (create_blueprint_interface) nor the framework-class shortcuts (create_game_mode_class_bp, create_player_controller_class_bp, ...). It refuses instead of overwriting when the asset already exists on disk, and it never confirms the parent: read it back with get_blueprint_parent.

Returns: { name: string, path: string, package_path: string, parent_class: string, generated_class: string, blueprint_type: string, already_exists: bool, saved: bool, save_error?: string } -- parent_class here is what was REQUESTED and resolved, not proof the asset carries it: confirm a child's real parent with get_blueprint_parent. saved:false is honest and always carries save_error (PIE was running, or the Blueprint was already resident in memory and left untouched) -- an unsaved Blueprint exists only in the editor and a later compile on it also returns success.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesBlueprint name. Either a bare name (created under 'path' or /Game/Blueprints/) OR a full content path ("/Game/MyGame/Systems/World/BP_Foo"); an object-path form ("/Game/.../BP_Foo.BP_Foo") is also accepted.
pathNoOptional target content folder ("/Game/MyGame/Systems"). Used only when 'name' is a bare name; ignored when 'name' is already a full path.
forceNoOptional. This command is REFUSED while a Play-in-Editor session is running: it either compiles a Blueprint (the reinstancer can retain a world, and CheckForWorldGCLeaks is Fatal -- it KILLS the editor) or writes to disk (Editor.AllowSavingAssetsDuringPIE=0 makes the engine refuse the write, so it would report success without writing a byte). Stop PIE and retry instead; force=true runs it anyway, at your own risk.
asset_pathNoAlias of `path` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `path`.
parent_classNoOptional parent class. Accepts a native name ("Actor", "Pawn", "Character", "StaticMeshActor", "BlueprintFunctionLibrary"), a "/Script/Module.Class" path, a Blueprint generated-class path ("/Game/.../BP_X.BP_X_C"), or a Blueprint asset path ("/Game/.../BP_X"). Defaults to AActor. Passing "BlueprintFunctionLibrary" makes a Function Library.
blueprint_typeNoOptional Blueprint type override: "normal" (default), "function_library" (a UBlueprintFunctionLibrary of static functions; parent_class is ignored/forced), or "macro" (a Macro Library; keeps parent_class or defaults to Actor). Function-library is also auto-detected from parent_class="BlueprintFunctionLibrary".

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only cover the generic readOnly/destructive/idempotent profile; the description adds substantial non-obvious behavior: immediate disk save unless PIE is running, refusal instead of overwrite, no parent confirmation (must verify with get_blueprint_parent), and the honest saved:false + save_error semantics for resident-but-unsaved Blueprints. Nothing contradicts the annotations.

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 the core action and scope, then caveats; every section is relevant. It is on the long side and repeats the parent-verification point twice (in the 'never confirms' clause and again inside the Returns block), and the inline Returns dump is verbose — though justified by the absence of an output schema.

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

Completeness5/5

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

There is no output schema, and the description compensates fully: it enumerates every returned field, flags which ones are unverified (parent_class), and explains failure/save semantics (saved:false always carries save_error). Combined with the PIE and existing-asset rules, an agent has everything needed to call and interpret this tool.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds meaning beyond the schema: it explains that parent_class accepts native names, /Script paths, generated-class paths, and asset paths, that function-library type is auto-detected, and it clarifies that the returned parent_class is 'requested and resolved' rather than verified — a distinction absent from the schema.

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+resource (create a Blueprint asset) and immediately bounds it: child of ANY parent, function/macro libraries supported, interfaces and framework-class shortcuts excluded with named sibling tools (create_blueprint_interface, create_game_mode_class_bp). An agent can distinguish it from the many create_* siblings without opening schemas.

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

Usage Guidelines5/5

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

Explicit routing: does NOT create interfaces (points to create_blueprint_interface) nor framework-class shortcuts (names create_game_mode_class_bp, create_player_controller_class_bp, ...). Also states the refusal-over-overwrite rule and that PIE blocks the operation unless force=true, which is exactly the when/when-not guidance an agent needs.

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