Skip to main content
Glama

Edit scene entities

scene_edit
Destructive

Add, update, delete or duplicate entities in Mount & Blade II: Bannerlord scenes, editing scene.xscene files or the live Modding Kit editor with undoable, schema-safe changes.

Instructions

Adds, updates, deletes or duplicates entities. File mode edits scene.xscene of a writable module (formatting preserved, undoable). live=true edits the scene open in the Modding Kit editor through the bridge (then save with Ctrl+S in the editor); live also supports select, focus and snap_to_ground. add: place a prefab (prefab=…) or a mesh (mesh=…, physics=bo_…) or raw <game_entity> XML, count+offset make rows. update: position/move_by, rotation/rotate_by (degrees unless rotation_unit=rad), scale, name (exact for every target unless number_names), add_tags/remove_tags, attributes, script+variables, levels (file mode). Live targets: #handles from scene_entities live (valid until the scene is reopened) or names (child entities included). Siege spawner names are protected: the editor derives their prefab from the name.

Input Schema

NameRequiredDescriptionDefault
xmlNoadd (file mode): a complete <game_entity> element.
liveNoEdit the scene open in the running editor instead of the file (default false).
meshNoadd: meta mesh name (see asset_search kind=mesh).
nameNoName of new entities / new name for update. Siege spawners (BallistaSpawner, MangonelSpawner…) must keep '<prefab>_spawner' names — the editor derives their prefab from the name; other names are refused.
countNoadd/duplicate: number of copies (default 1).
scaleNo[x, y, z] scale (a single number scales uniformly).
sceneNoScene name, Module/scene or path (file mode).
actionYesWhat to do.
levelsNoupdate (file mode): the scene levels the entities belong to, e.g. ["siege"] ([] = every level). Define levels with scene_settings add_levels.
moduleNoModule to look in when the scene name is ambiguous.
offsetNoadd/duplicate: step between copies [dx, dy, dz] (duplicate default [1,0,0]).
parentNoadd (file mode): handle or name of the parent entity.
prefabNoadd: prefab name (see prefab_search).
scriptNoupdate (file mode): script component name whose variables to set (created if missing).
move_byNoupdate: relative move [dx, dy, dz].
physicsNoadd (file mode, with mesh): physics shape such as bo_…
visibleNolive update: show/hide the entities.
add_tagsNoTags to add.
entitiesNoTargets: handles ([12], 12/0 in files; #id numbers live), names, 'guid:{…}' or '@selected' (live).
positionNo[x, y, z] position (add: placement; update: absolute).
rotationNo[x, y, z] euler rotation (degrees unless rotation_unit=rad).
rotate_byNoupdate: relative rotation [dx, dy, dz] (degrees by default).
variablesNoupdate (file mode): script variables, e.g. {"SoundName": "event:/…"}. Values are strings.
attributesNoupdate (file mode): attributes to set on <game_entity>, e.g. {"mobility": "1"}. Values are strings.
remove_tagsNoTags to remove.
number_namesNoAppend _1, _2 … to `name`: default true when add makes several entities (never for siege spawners), false for update (every target gets exactly `name`).
rotation_unitNoUnit of rotation / rotate_by (default deg).
snap_to_groundNolive: drop new/moved entities onto terrain or geometry below.
add_to_selectionNolive select: keep the current selection.
remove_attributesNoupdate (file mode): attributes to remove.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only cover safety (destructive=true, not read-only), but the description adds real behavior the annotations cannot: file edits preserve formatting and are undoable, live edits are not persisted until Ctrl+S, live handle targets are only valid until the scene is reopened, and Siege spawner names are protected/refused. This is exactly the value-add the higher bar looks for.

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?

For 30 parameters and two modes this is tightly compressed, front-loaded with the action list and the file/live split before the per-action detail. The semicolon-chained sentences are dense but every clause carries operational meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given dual-mode complexity, 30 params and no output schema, the description covers mode semantics, target identity (handles/names/#ids), naming protection and the live save workflow. It omits what the tool returns (e.g. handles of newly added entities) and whether undo applies to live as well as file mode, which for a destructive multi-action tool would have closed the loop.

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 goes beyond it by mapping parameters to actions (add: prefab/mesh/xml/count+offset; update: position/move_by, rotation/rotate_by, scale, name, tags, attributes, script+variables, levels; live-only: select, focus, snap_to_ground) and clarifying relative vs absolute and units. It largely restates schema text (degrees unless rotation_unit=rad), so it lands just above baseline.

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?

The description opens with a specific set of verbs (adds, updates, deletes, duplicates) applied to a concrete resource (scene entities), then immediately splits the tool into its two operating modes (file vs live editor bridge). An agent can distinguish this from read-only siblings like scene_entities or scene_info without opening the schema.

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?

It gives an explicit routing rule for the biggest decision — file mode edits scene.xscene of a writable module while live=true edits the scene open in the editor (then save with Ctrl+S) — and cross-references helpers (scene_entities for live #handles, prefab_search, asset_search kind=mesh, scene_settings add_levels). It stops short of stating when *not* to use it (e.g. vs editor_command or delete_object).

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