Skip to main content
Glama

new_level

Destructive

Loads the Unreal Engine default template map into the editor; does not create an empty level. Refuses while other worlds are resident, and ignores level_name.

Instructions

Loads the ENGINE default template map into the editor. It does NOT create a level and the level is NOT empty (~45 actors: Floor, PlayerStart, DirectionalLight, SkyLight, SkyAtmosphere, fog); level_name is accepted but IGNORED. After this the editor sits on an /Engine map, so a save_level without filename would write over the engine's own .umap. Like load_level it REFUSES to run while other UWorlds are resident in memory, because this is a LoadMap and the engine's world-leak check turns that into a Fatal error that kills the editor process (see force).

Returns: { success: bool, error?: string, refused?: bool, load_attempted?: bool, requested_filename?: string, target_package?: string, resident_world_count?: int, resident_worlds?: [{ package: string, world_name: string, world_type: string, has_world_context: bool, is_load_target: bool }], resident_world_is_load_target?: bool, remedy?: string, data?: { template_package: string, level_name_ignored: bool, requested_level_name?: string, resident_world_count: int, forced_past_resident_worlds: bool, resident_worlds?: [...], level_name?: string, world_name?: string, loaded_package?: string, is_engine_template?: bool, warning?: string, message?: string } }

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoSkip the resident-world preflight and call LoadMap anyway. With resident worlds alive this PROBABLY KILLS THE EDITOR: the engine raises a Fatal error ("World Memory Leaks"), the process dies and every unsaved in-memory edit is lost. Defaults to false.
level_nameNoIGNORED. Accepted for wire compatibility only; the loaded map is always /Engine/Maps/Templates/Template_Default. When you pass one, the response echoes it in requested_level_name and sets level_name_ignored=true.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, readOnlyHint=false), disclosing the ~45-actor template contents, that level_name is ignored, the resident-world refusal and world-leak Fatal error that kills the editor, and that `force` probably kills the process and loses unsaved edits. This is exactly the kind of consequence disclosure a mutation tool with no output schema needs.

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-loads the single most important fact (what it loads and what it does not create), then covers risks and returns. The Returns block is long, but with no output schema it earns its place by documenting the refusal/echo/warning fields.

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 no-output-schema tool with hidden destructive behavior, the description covers what is loaded, the ignored param, the failure/refusal mode, the force danger, and the return shape. Nothing an agent needs to invoke it safely is missing.

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% and both params are already documented in the schema, but the description reinforces the counterintuitive semantics: `level_name` is accepted for wire compatibility yet ignored, and `force` bypasses a preflight that likely kills the editor. It adds emphasis on intent beyond the raw 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 and resource ('Loads the ENGINE default template map into the editor') and immediately distinguishes itself from what an agent might assume ('It does NOT create a level and the level is NOT empty'). It also contrasts itself with load_level and save_level, so an agent can place it against siblings.

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

Usage Guidelines4/5

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

Gives clear context: it behaves like load_level, refuses while other UWorlds are resident, and warns that a save_level without a filename would overwrite the engine's .umap. It stops short of naming an explicit alternative tool to use instead when the preflight fails (only points to `force`), so it is strong but not fully prescriptive.

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