Skip to main content
Glama

scene_add_prefab

Destructive

Create reusable prefabs from an asset or an existing scene entity so node graphs can spawn them at runtime at any size, with optional health, mechanism status, or drop settings. Returns a new prefabId.

Instructions

Make a prefab (元件) in a copy of a save, so that a node graph can create that thing at run time wherever it wants and at the size you chose: small coins, a wall that appears when it is bought, markers that follow the player, units that are recruited. Two ways: asset (an object asset id or unique name from scene_search_assets) with a scale; or fromEntity (the name of something already placed in the save, from scene_list_entities) to make a prefab of that very thing, which is how creature prefabs are made: place one creature with createAtStart false, import, then make the prefab from it. scale is a number or [x, y, z], 1 = natural size; with fromEntity it defaults to the entity's own scale. (Created by its bare asset id with f.createPrefab a thing always has its natural size.) Mechanism assets (group 交互机关: chests, levers, doors, the bounce mushroom) have a preset status (预设状态), a built-in animation: the prefab is given the asset's status id, the result names it, and a graph plays it with f.setPresetStatus(entity, statusId, 1n): the chest opens, the lever goes down, the door swings. presetStatusValue is the value it starts at (default 0). presetStatusId registers an id of your own for an asset that is not in the table of verified ones (for most mechanisms of group 交互机关 the id is (asset id - 4000) x 10): an id the asset does not have fails the editor's check before a playtest, and the failure names the prefab (playtest_status gives the text), so a playtest that starts means the id exists. health is the base health of the thing (an object has 10 when it is left out, which one hit of a sword skill breaks; the target dummy of the official attack lesson has 300; on a creature it replaces the base health the placed creature has, which the game multiplies by several for the creature's level: a hilichurl of base 13.6 falls to two or three hits of 50, one of base 40 stood after three): it matters once something can hit the thing, which for an object needs a hurtBox (scene_add_components); verified in play on 2026-10-11 (examples/raid: a crate of 100 takes two hits of 50). drop makes the prefab a drop (掉落物): the thing that lies on the ground and gives the character that picks it up an item into its backpack, {item: name or id from scene_add_item, amount, pickupSize: the side of the box around it, in metres, within which the prompt to pick up shows (1 when left out, which asks the player to stand just beside it; 6 was comfortable in examples/raid)}; a graph creates it like any prefab, and a thing with the loot component (scene_add_components) leaves it behind when destroyed. Verified in play on 2026-10-11 (examples/drops): the prompt to pick up (F) shows when the character is about 0.6 m from the drop, not from further than a metre and not while standing on it. A creature created from such a prefab acts like a placed one (verified in play): to send it at something in custom aggro mode, the target has to be its enemy (a wall goes on the players' side with f.modifyEntityFaction first) and the order has to come a moment after it appears, not in its own whenEntityIsCreated. Returns the new prefabId and a new .gil in the workspace; the official save is not touched.

Input Schema

NameRequiredDescriptionDefault
dropNo
nameNo
assetNo
scaleNo
healthNo
mapPathNo
fromEntityNo
outputNameNo
presetStatusIdNo
presetStatusValueNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds the crucial scope caveat that work happens 'in a copy of a save' and 'the official save is not touched', plus the return contract (new prefabId and a new .gil in the workspace) and playtest-verification notes. It does not say why the operation is destructive (existing prefab overwrite? workspace file replacement?), so it stops short of fully covering the destructive hint.

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?

The purpose is front-loaded, but the body is a single sprawling run-on riddled with nested parentheses and digressions (the target dummy's 300 health, verification dates). Most facts are substantive, yet the density and lack of segmentation make it hard to scan for the one branch an agent needs.

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 10-parameter, zero-coverage, no-output-schema tool, it covers the mechanism/preset system, health semantics, drop semantics, the return shape and playtest-validation loop. What is missing is any statement of what happens when neither asset nor fromEntity is given, and the roles of name, mapPath and outputName.

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 description coverage is 0%, so the description must carry all meaning — and it does for asset, scale (number or [x,y,z], 1 = natural size, defaults to entity scale with fromEntity), fromEntity, health (with concrete damage examples), presetStatusId/presetStatusValue, and the nested drop object (item, amount, pickupSize). However name, mapPath and outputName are never mentioned, leaving three of ten parameters unexplained anywhere.

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: making a prefab (元件) in a copy of the save so a node graph can instantiate it at run time. It is clearly distinguishable from scene_list_prefabs, scene_update_prefab and scene_import_assets, and even explains the alternative in-graph route (f.createPrefab with a bare asset id).

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?

Explicitly routes between the two creation paths — 'asset (an object asset id or unique name from scene_search_assets)' versus 'fromEntity (the name of something already placed, from scene_list_entities)' — and gives the concrete creature-prefab recipe (place with createAtStart false, import, then prefab from it). It also flags when health matters (needs a hurtBox) and when drop applies (loot component).

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