Skip to main content
Glama

execute_python

Destructive

Run Python code inside the running Unreal Editor using the unreal API to execute scripts, evaluate expressions, and inspect results, outputs, and engine logs for editor automation and debugging.

Instructions

Run Python in the running Unreal Editor, with Unreal's unreal API, for what no tool does: search find_tools first, since most tools are not in a client's list. A script that raises fails the call, with the traceback in command_result.

mode picks how command runs: ExecuteFile (the default) runs a script of any length, ExecuteStatement runs one statement and prints its result, and EvaluateStatement returns one expression's value in command_result, as in {"command": "len(unreal.get_editor_subsystem(unreal.EditorActorSubsystem).get_all_level_actors())", "mode": "EvaluateStatement"}. Scripts share the editor console's globals, so a variable one call defines is there for the next.

output and log_output hold what the script prints and logs through unreal.log; what the engine itself logs during the call is only in engine_log, warnings and errors by default. When a call reports success and nothing happened, read engine_log first, widen it with engine_log_level=Log, or pass log_cursor_before to get_output_log_lines for the unfiltered rest.

"Object has no attribute" is the commonest error, and the field usually exists elsewhere: HitResult's impact_point is only in to_dict(), while Transform.translation is an attribute. Ask the object (dir(x), x.to_dict(), x.get_editor_property(...)) instead of guessing.

During Play-in-Editor, a call in the script that compiles a Blueprint or saves (compile_blueprint, save_asset, save_loaded_asset, save_packages, save_current_level...) does not run: the script gets a RuntimeError there, and the call fails with pie_refused even if the script catches it. The guard does not see a Blueprint edited without a compile, so stop PIE before editing one. Reading the live world during PIE is safe.

One call often answers what a loop would: get_actors_by_class for the actors of a class, get_actor_properties_by_class for their properties with the world that answered, get_properties for one object, get_actor_components, raycast_scene, and watch_pie_property for a value over a PIE session. A script that only enumerates actors gets a hint naming the tool. Python stays the right answer for several classes in one round trip, values correlated in one tick, or anything that mutates.

Returns: { command, python_success, execution_mode, command_result, output, log_output, log_line_count, engine_log, engine_log_count, engine_log_truncated, log_cursor_before, pie_refused?, hint? }

Input Schema

NameRequiredDescriptionDefault
codeNoAlias of `command` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `command`.
modeNoExecution mode: ExecuteFile, ExecuteStatement, or EvaluateStatement (default ExecuteFile). Any other value runs as ExecuteFile; execution_mode in the reply says which ran.
scriptNoAlias of `command` (same value, same meaning). Accepted because sibling tools spell this parameter differently; prefer `command`.
commandNoPython code to run (single or multi-line).
capture_outputNoHas no effect, and is accepted so older calls keep working: the output is always captured, and `mode` decides whether the code runs as a script or as one statement.
engine_log_maxNoMax lines in `engine_log` (default 50, 0 disables, hard cap 4096).
engine_log_levelNoMinimum severity of ENGINE log to return in `engine_log`: Error, Warning (default), Display, Log/All.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv2.7.0
    • changedInput schema / properties / capture_output / description
      Previous value: -"Run as a file and collect captured log (default true)"New value: +"Has no effect, and is accepted so older calls keep working: the output is always captured, and `mode` decides whether the code runs as a script or as one statement."
    • changedInput schema / properties / mode / description
      Previous value: -"Execution mode: ExecuteFile, ExecuteStatement, or EvaluateStatement (default ExecuteFile)"New value: +"Execution mode: ExecuteFile, ExecuteStatement, or EvaluateStatement (default ExecuteFile). Any other value runs as ExecuteFile; execution_mode in the reply says which ran."
  2. 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 already declare destructive/non-idempotent/open-world, but the description adds substantive behavior the annotations cannot convey: exceptions fail the call with the traceback in command_result, the PIE guard raises RuntimeError and fails with pie_refused even if caught, and globals persist across calls. These are exactly the non-obvious traits an agent needs before invoking a script executor.

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?

Dense but front-loaded: purpose, mode, logging, error debugging, PIE guard, then alternatives-in-reverse. It is on the long side and the returns block plus some diagnostic prose could be trimmed, but every section carries actionable information rather than filler.

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, yet the description enumerates the return fields (command_result, engine_log, log_cursor_before, pie_refused, hint) and explains how to chain them (log_cursor_before into get_output_log_lines). For a high-flexibility, destructive executor this covers everything needed to call it correctly.

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 the baseline is 3; the description still adds value by contrasting the three `mode` values with a concrete EvaluateStatement example and by tying engine_log_level to the diagnostic workflow. The aliases (code/script) and capture_output are left to the schema, which is a reasonable division given coverage.

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?

Opens with a specific verb and resource ('Run Python in the running Unreal Editor') and immediately scopes it against siblings ('for what no tool does: search find_tools first'). The domain (Unreal `unreal` API) is stated explicitly, so an agent knows exactly what this tool is and is not for.

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?

Gives explicit routing advice: search find_tools first, use get_actors_by_class / get_properties / raycast_scene / watch_pie_property instead for common enumeration cases, and reserve Python for 'several classes in one round trip, values correlated in one tick, or anything that mutates.' Both when-to-use and when-not-to-use are covered.

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