Skip to main content
Glama

Author an interactive beat in one call

make_choice_scene
DestructiveIdempotent

Builds an RPG Maker MZ event page script from a step list, compiling dialog, choices, branches, loops, battles, shops, and transfers with validated switches, variables, and assets.

Instructions

Write an event's whole script from a step list: dialog, choice branches (each option can carry its own when gate), if over switches, variables, items, gold and buttons, loop with break, battle with win/escape/lose branches, shop, transfers, audio, screen effects, gameOver. This is the tool for a scene rather than a person: pass a cell to place a new event, or an existing eventId and pageIndex to rewrite that page. The compiler produces the indentation and the branch markers (402/403, 411/412, 413, 601-603) the engine reads, so a body cannot land outside the branch it belongs to — the mistake that otherwise shows up as a choice that always takes the first option. Checked before writing: unknown step names, conditions or commands that name a switch, variable or database row the game does not have, audio and face files the project lacks. One transaction, map rendered back.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNo
yNo
nameNo
whenNoCondition for the page this script goes to
imageNoThe event's graphic. A characterName that is not in img/characters fails the call
mapIdYes
scriptYesThe page's whole script. Each step is an object with exactly one key: `say` (a string, a list of lines, or {lines, speaker?, faceName?, faceIndex?, background?, positionType?}), `scroll` ({lines, fast?, wait?}), `comment`, `choice` ({prompt?, options: [{label, then, when?, lockedMessage?}], cancel?: steps, defaultType?, positionType?, background?}), `if` ({when, then, else?}), `loop` (steps, closed by `break` or `goto`), `break`, `exit`, `label`, `goto`, `switch` ({id, value?}), `selfSwitch` ({letter, value?}), `variable` ({id, set?|add?|multiply?}), `gold` (a number; negative takes), `item`/`weapon`/`armor` ({id, count?, take?}), `heal`, `transfer` ({mapId, x, y, direction?, fade?}), `wait` (frames), `fade` ("out"|"in"), `flash` ({color?, duration?, wait?}), `weather` ({type, power, duration?, wait?}), `se`/`me`/`bgm` (a name or {name, volume?, pitch?, pan?}), `stopBgm`, `stopSe`, `animate` ({target?, animationId, wait?}), `balloon` ({target?, balloonId, wait?}), `moveRoute` ({target?, route: [route steps], repeat?, skippable?, wait?}), `battle` ({troopId, canEscape?, canLose?, win?, escape?, lose?}), `shop` ({goods: [{id, kind?, price?, purchaseOnly?}]}), `menu`, `saveScreen`, `gameOver`, `title`, `commonEvent`, `erase`, `script` (engine code, stored as 355/655) and `raw` (verbatim {code, parameters, indent?}). `script` and `raw` are escape hatches: they come back named in the reply, and a build that leans on them is reporting a shape this layer does not cover yet.
eventIdNoRewrite this event instead of placing a new one
replaceNoWith `name`: rebuild the event of that name instead of adding another (default true)
triggerNo0 action button, 1 player touch, 2 event touch, 3 autorun (fires on entering the map), 4 parallel process. 0 and 1 are checked for a cell the player can stand on; 3 and 4 are not, so an opening cutscene can sit on a wall in the corner the way the editor's own do
pageIndexNoWith eventId: which page to replace (default 0)
priorityTypeNo0 below tiles (default: a zone or a cutscene should not block), 1 same as tiles, 2 above

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A4.6/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: pre-write validation (unknown steps, missing switches/variables/rows, missing audio and face files), automatic indentation and branch-marker emission, and the 'one transaction, map rendered back' atomicity guarantee. The 'rewrite that page' wording also discloses the overwrite that destructiveHint=true implies.

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-loaded with purpose and the place-vs-rewrite decision, then the step catalog, then validation/transaction behavior. The step enumeration is long but each token names a real construct; slightly dense as a single block, but no filler sentences.

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 12-param, no-output-schema mutation tool this covers purpose, modes, validation and atomicity, and notes that `script`/`raw` escape hatches 'come back named in the reply'. It stops short of describing the overall response payload or pagination/limits, but is close to complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema leaves `script` as an opaque array of single-key objects (additionalProperties {}), and the description compensates by enumerating the whole step vocabulary and the shape of key steps (choice options with `when`/`then`, battle win/escape/lose branches, loop closed by break/goto). This is meaning the schema does not carry.

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 ('Write an event's whole script from a step list') and enumerates the exact constructs it authors (dialog, choice branches, if, loop, battle, shop, etc.). It also positions itself against siblings by declaring 'the tool for a scene rather than a person', separating it from make_npc/make_chest.

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 for both modes ('pass a cell to place a new event, or an existing eventId and pageIndex to rewrite that page') and differentiates scene-level authoring from person-level authoring. It does not explicitly name nearby alternatives like add_commands/set_commands/place_event, so the routing is implied rather than spelled out.

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