Skip to main content
Glama

run_external_project_script

Destructive

Spawn an isolated headless Unreal editor to run a Python script against an external project, avoiding /Game package collisions and returning stdout.

Instructions

Spawn a SEPARATE headless UnrealEditor-Cmd.exe to run a python script against an EXTERNAL project and capture its stdout. Needed because another project's /Game packages collide with the live project's (they cannot be loaded side by side), so reading data from content outside this project needs an isolated editor. Give it an existing .uproject OR a module_dir (a minimal engine-only .uproject is cloned in place, with any 'disable_plugins' turned off, then deleted); it launches <uproject> -run=pythonscript -script=<script> -unattended -nullrhi -NoLiveCoding -stdout, blocks until exit or timeout, and returns stdout. HEAVY: spawns a full editor process (tens of seconds) and BLOCKS the editor for the duration -- run with confirmation. The engine binary is resolved from THIS editor's install (FPaths::EngineDir); no path is assumed.

Returns: { exe: string, uproject_used: string, cloned: bool, script: string, params: string, launched: bool, exit_code: int, success: bool, timed_out: bool, duration_seconds: number, stdout: string, stdout_length: int, stdout_file: string, cleaned_up: bool, message: string }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
scriptYesAbsolute path to the .py file to run (the -script argument).
uprojectNoPath to an existing external .uproject to run against (optional; provide this OR module_dir).
extra_argsNoOptional list of extra command-line tokens appended to the launch.
module_dirNoDirectory of a content folder or project whose Content to load; a temporary engine-only .uproject is cloned here and cleaned up (optional; provide this OR uproject).
disable_pluginsNoOptional list of plugin names to disable in the CLONED .uproject (e.g. custom plugins that hang headless startup). Only applies when module_dir is used.
timeout_secondsNoMax seconds to wait before terminating the child (optional, default 300; clamped 30..3600).

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 (destructiveHint=true, non-idempotent, non-read-only) are consistent, and the description goes well beyond them: exact launch command, blocking behavior, tens-of-seconds cost, the clone-then-delete lifecycle of the temporary .uproject, plugin disabling only for clones, and timeout clamping. This is unusually rich disclosure of side effects.

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 purpose and the reason, then the invocation mechanics. Dense but nearly every sentence carries load; the inline command template is long yet clarifies behavior that would otherwise be inferred.

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?

For a heavy, destructive, side-effecting tool with no output schema, the description enumerates the full return shape and covers blocking, timeout, cleanup and engine-path resolution. An agent has everything needed to call it correctly and predictably.

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, but the description adds real semantics: uproject and module_dir are mutually exclusive alternatives, disable_plugins applies only to the cloned project, and timeout is clamped/defaulted. The only gap is it doesn't elaborate on extra_args beyond the launch command line.

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+scope: spawns a separate headless UnrealEditor-Cmd to run a Python script against an EXTERNAL project, capturing stdout. It also distinguishes itself from the in-process siblings (execute_python / execute_python_file) by explaining why an isolated editor process is required.

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 when-to-use (reading content outside this project because /Game packages collide), how to invoke it (existing .uproject OR module_dir), and an explicit operational warning ('HEAVY... BLOCKS the editor -- run with confirmation'). The conditions that select each mode are spelled out.

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