Skip to main content
Glama

compile_blueprint

Destructive

Compiles a Blueprint to regenerate its class and returns the real outcome: error and warning counts plus optional per-node messages. Use it after adding nodes, functions or RPCs and before PIE starts.

Instructions

Compile a Blueprint to regenerate its class and return the real outcome: succeeded is true only with zero errors, with the error and warning counts and, on request, every compiler message tied to its node.

Compile after adding nodes, functions, variables or RPCs, and before anything calls them or Play-in-Editor starts. To look for errors without compiling, use check_blueprint_errors for one Blueprint or find_erroring_blueprints for a folder. It does not save: save_asset writes the result.

blueprint_name takes a short name or, safer, the full path that find_assets_by_name returns, since a short name shared by two assets compiles one of them. Example: {"blueprint_name": "/Game/Blueprints/BP_Door", "return_messages": true}. With return_messages each message carries the node_id and graph that get_graph_nodes and remove_graph_node take. force only matters during Play-in-Editor, where the call is otherwise refused: force=true compiles anyway, with the risk below.

The compile blocks the editor until it ends. Blueprints that depend on this one get their bytecode recompiled, instances of its class are reinstanced, and a garbage collection runs afterwards, so a Blueprint with many dependents costs more and other packages can end up dirty. Undo does not take a compile back: it reverts the graph edit before it, and the class keeps the compiled code until the next compile, so compile again after an undo. During Play-in-Editor the reinstancing leaves a world behind that kills the editor when PIE stops, which is why the call is refused then.

num_errors 0 does not prove the graph works: an unresolved wildcard pin on an array or ForEach node can compile clean and still block PIE, and a "was pruned" warning means consumers read defaults, so read the warnings too.

Returns: { name, compiled, succeeded, num_errors, num_warnings, messages?: [{ severity: 'error'|'warning'|'note', text, node_id, node_title, graph_name }] } -- messages only with return_messages; the node fields are empty for a message tied to no node.

Input Schema

NameRequiredDescriptionDefault
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.
blueprint_nameNoThe Blueprint's short name or its full asset path (e.g. /Game/MyGame/Core/BP_MyActor).
blueprint_pathNoAlias of `blueprint_name` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `blueprint_name`.
return_messagesNoOptional, default false: also return every compiler message, each tied to its node. The outcome fields come back either way.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.8.2
    • changedInput schema / properties / blueprint_name / description
      Previous value: -"Name of the blueprint, or its full asset path (e.g. /Game/MyGame/Core/BP_MyActor). A short name matching two assets compiles ONE of them silently -- pass the full path when in doubt."New value: +"The Blueprint's short name or its full asset path (e.g. /Game/MyGame/Core/BP_MyActor)."
    • changedInput schema / properties / return_messages / description
      Previous value: -"Optional (default false). When true, ALSO returns the per-message compiler results log so callers can see node-anchored errors/warnings. When false/absent the response omits the `messages` array but still reports the REAL compile status."New value: +"Optional, default false: also return every compiler message, each tied to its node. The outcome fields come back either way."
  2. Changed1 schema field changedv2.0.0
    • changedInput schema / properties / blueprint_name / description
      Previous value: -"Name of the blueprint. A short name matching two assets compiles ONE of them silently -- pass the full path when in doubt."New value: +"Name of the blueprint, or its full asset path (e.g. /Game/MyGame/Core/BP_MyActor). A short name matching two assets compiles ONE of them silently -- pass the full path when in doubt."
  3. 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 flag destructive/not-idempotent; the description goes far beyond with blocking-the-editor behavior, dependent recompilation, reinstancing, GC side effects, dirty packages, undo not reverting a compile, PIE refusal, and false-negative cases (wildcard pins, "was pruned"). That is exactly the kind of consequence detail an agent needs before invoking a destructive operation.

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 timing, then parameters, then runtime consequences, then return shape — a sensible order. It is long but dense with useful content; the main waste is the PIE-force caveat appearing both here and nearly verbatim in the force schema description.

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?

No output schema exists, yet the description fully specifies the return fields and when messages appear. For a destructive, editor-blocking compile with 4 optional params, an agent has everything needed: preconditions, side effects, failure modes, and return contract.

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 real value beyond the schema: the ambiguity risk of short names ("a short name shared by two assets compiles one of them"), the preferred full-path form, and what return_messages messages carry (node_id and graph). Force is largely restated rather than extended, keeping this short of a 5.

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?

"Compile a Blueprint to regenerate its class and return the real outcome" names a specific verb, resource, and effect, and the follow-up sentence about succeeded/error counts sharpens it. It is clearly distinguishable from check_blueprint_errors, find_erroring_blueprints, and save_asset, which are named as different operations.

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 when-to-use (after adding nodes/functions/variables/RPCs, before calls or PIE), explicit alternatives for the look-without-compiling case (check_blueprint_errors, find_erroring_blueprints), and explicit boundary versus save_asset ("It does not save"). Exclusion and routing are both stated.

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