Compile an Unreal Engine Blueprint to apply pending changes and validate its logic.
Compile a Blueprint to apply all changes.
KB: see knowledge_base/01_BLUEPRINT_FUNDAMENTALS.md#overview Example: compile_blueprint(blueprint_name="/Game/MCP_Test/BP_Example")
| Name | Required | Description | Default |
|---|---|---|---|
| blueprint_name | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. 'Apply all changes' hints at a mutating action, but the description does not clarify whether the asset is saved, whether compilation can leave the blueprint in an error state, or what side effects compiling may have.
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 short, front-loaded, and contains no filler. The KB pointer and example each add some value, though the overall terseness leaves behavioral and selection gaps covered by other dimensions.
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?
The tool is simple with one required parameter and an output schema, so the description does not need to explain return values. However, it lacks alternative routing, behavioral side effects, and explicit parameter semantics, making it minimally viable rather than complete.
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. The example gives a concrete asset path format for blueprint_name, which is useful, but it does not explicitly explain that a full Unreal asset path is expected or how to resolve a short asset name.
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 states a clear verb and resource: compile a Blueprint to apply changes. It is not a tautology, and the example clarifies the input format, but it does not distinguish itself from sibling tools like compile_blueprint_and_report, bp_compile, or save_blueprint.
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?
No guidance is given about when to use this tool versus alternatives. The KB pointer and example help with mechanics, but the description does not explain when compile is appropriate, when to prefer compile_blueprint_and_report, or when a save is also required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.