Skip to main content
Glama

scene_add_item

Destructive

Define a backpack item in a copied save with currency value, icon, stack limit, and optional use graph, enabling shops and graphs to manage quantities.

Instructions

Define an item (道具) in a copy of a save: a thing a character holds in its backpack in numbers (fruit, wood, a key), which a shop can sell or buy. Define a currency first (scene_add_currency gives every character the backpack). value is what one of it is worth in a currency (the currency by name or id); icon is the number of an item icon (90001 an apple, 90015 fowl meat). A graph gives and takes it with f.modifyInventoryItemQuantity(character, itemId, change) and reads f.getInventoryItemQuantity(character, itemId). The events about an item (whenItemIsAddedToInventory, whenItemIsLostFromInventory, whenTheQuantityOfInventoryItemChanges, whenItemsInTheInventoryAreUsed) arrive only in the item's own item graph (useGraphId), not in a graph on the character or the player; only the currency event goes to the holder. The record written is byte for byte the item of the official sample 货币与商店. Verified in play on 2026-10-11 (bought and sold in a shop, counted by a graph). category "consumable" with useGraphId makes it an item the player uses from the backpack: useGraphId is an item graph (scene_add_graph {kind: "item"}, source g.server({id, name, type:'item'}).on('whenItemsInTheInventoryAreUsed', ...)), the record being that of the fowl meat of the official sample 掉落物、道具、背包; evt.itemOwnerEntity is the character that used it and evt.amountToUse how many. The player presses B for the backpack, clicks the item, 使用 and 确认; useCooldownSeconds is how long the item then waits before it can be used again (10 when left out). Verified in play on 2026-10-11 (examples/potion). Equipment is not made; the drop that lies on the ground is scene_add_prefab {drop}. Writes a new .gil in the workspace; the official save is not touched.

Input Schema

NameRequiredDescriptionDefault
iconNo
nameYes
valueNo
mapPathNo
categoryNomaterial
outputNameNo
stackLimitNo
useGraphIdNo
descriptionNo
useCooldownSecondsNo

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?

Beyond the annotations it discloses the write target and blast radius ('Writes a new .gil in the workspace; the official save is not touched') and non-obvious event semantics (item events arrive only in the item's own item graph, not the character's or player's). It does not address what happens on duplicate names or overwriting an existing outputName, which is the main remaining gap.

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?

It is a single run-on block that mixes the core definition, graph-script API signatures, event routing, UI click instructions ('presses B ... clicks the item, 使用 and 确认'), and repeated verification dates. The important content is front-loaded, but splitting the graph/event detail from the definition would make it far more scannable.

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, no-output-schema mutation tool this covers the creation semantics, the currency prerequisite, the consumable/useGraphId path, and the script-facing API. Only the secondary parameters (stackLimit, outputName, mapPath, description) are left to the schema, which is a minor gap given how much context is supplied.

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 0%, so the description must carry the load, and it does for the hard parameters: value (currency by name or id), icon (numeric ids with examples 90001/90015), category ("consumable" activates use), useGraphId (must be an item graph from scene_add_graph), and useCooldownSeconds (default 10). stackLimit, outputName, mapPath, and description still receive no mention, keeping it from a 5.

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 first sentence gives a specific verb and resource ('Define an item (道具) in a copy of a save') and immediately bounds the concept: a thing held in a backpack in numbers, sellable in a shop. It explicitly disambiguates from siblings by naming scene_add_currency, scene_add_prefab {drop}, and stating 'Equipment is not made'.

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?

It gives an explicit prerequisite ordering ('Define a currency first'), names the alternative tool for ground drops (scene_add_prefab {drop}), excludes equipment, and explains the conditional path (category "consumable" with useGraphId) that changes how the item behaves. An agent can choose between item, currency, and prefab without further inference.

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