Skip to main content
Glama

scene_build_blocks

Destructive

Create an official .gia asset pack from a list of scene pieces and stage it in the editor's import folder for later game import.

Instructions

Turn a list of pieces into an official asset pack (.gia) and put it in the editor’s import folder. template is a block name from scene_block_catalog or any asset id from scene_search_assets. position is in metres; rotation in degrees per axis. Give size (metres per axis: the piece is stretched to exactly that; blocks default to 1,1,1) or scale (1 = the model’s own size, the default for non-block assets). For blocks position is the centre in x and z and the bottom in y (measured in play: a block at y 0.5 and 1 high has its top at 1.5); other models are anchored at their base. Monsters (group 怪物) are imported alive with their official AI parameters. createAtStart:false places a piece without creating it, so a node graph can create it later by GUID (the editor assigns new GUIDs on import; read them from the save). patrol (monsters only) makes the creature walk a path that already exists in the map while it has no target: templates:[{pathId,waypointIds}] with ids from inspect_level_paths; since the game update of 2026-10-09 the importer drops the template list, so a patrol written here does not reach the game: steer creatures with custom aggro instead. offset [x, y, z] is added to every position: the same list of pieces on ground of another height (a new empty save has its ground at y=0) or as a second copy elsewhere. Returns the pack’s bounds. Nothing changes in the game until scene_import_assets runs. solid false switches the native collision (原生碰撞) of a piece off, for a thing that is to be walked through; left out it is on. A character walks over low things by itself (a fence of 1.56 m, with jumping allowed and no key pressed, 2026-10-12): what keeps a player in is a wall of at least 2.4 m and a class that may not climb.

Input Schema

NameRequiredDescriptionDefault
nameYes
blocksYes
offsetNo
installNo
entityIdStartNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Goes far beyond the annotations: createAtStart:false defers creation to a node graph by GUID, the editor reassigns GUIDs on import, solid:false disables native collision, and patrol is flagged as non-functional since the 2026-10-09 importer change. This is exactly the mutation-side context an agent needs on a destructiveHint=true tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and core parameters are front-loaded, but the text sprawls into a semi-colon chain and ends on a tangent about a 1.56 m fence and a 2.4 m wall that is level-design lore rather than tool semantics. Those sentences do not earn their place in a tool definition.

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?

For a 5-parameter, nested-array mutation tool with no output schema, the description does the heavy lifting and even promises a return value ('the pack's bounds'). The gaps are the unexplained `install` and `entityIdStart` parameters, which an agent cannot infer from the schema alone.

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?

With 0% schema coverage the description carries the load, and it does well: units for position/rotation, the size-vs-scale distinction, the anchor-point difference between blocks and other models, and offset semantics are all explained. However `name`, `install`, and `entityIdStart` get no mention at all, so coverage is incomplete.

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 concrete verb and artifact: 'Turn a list of pieces into an official asset pack (.gia) and put it in the editor's import folder.' That is clearly distinguishable from the import sibling it later names, and the scope of the tool is unambiguous.

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 explicitly routes template lookup to scene_block_catalog or scene_search_assets and states 'Nothing changes in the game until scene_import_assets runs', making the two-step pipeline clear. What is missing is an explicit statement of when NOT to use this (e.g. modifying an existing pack, or a single piece).

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