Skip to main content
Glama

Simulate an event

simulate_event

Dry-runs a map event page against a hypothetical game state, returning messages and changes without modifying the project or running the game.

Instructions

Dry-runs one map event page against a hypothetical game state and returns what it would do, without touching the project or running the game. Supported commands: Show Text (101/401), Show Choices (102/402/403/404), Conditional Branch (111/411/412: switch, variable, self switch, gold, item), Loop/Break (112/113/413), Exit Event Processing (115), Common Event (117, nested up to 8 deep), comments, Control Switches (121), Control Variables (122: constant, variable and random operands), Control Self Switch (123), Change Gold (125), Change Items (126), Transfer Player (201, ends the run) and Plugin Command (356, listed in changes as 'plugin: ...'). Battle Processing (301) is not fought: the branch picked by battleResult runs (win, escape or lose; default win) and the others are skipped; a missing branch adds 'battle: no branch' to changes. A Battle Processing without branches (what the editor writes when neither Can Escape nor Continue when Loss is on) is a single command: nothing is skipped and the next command runs. Label (118) and Jump to Label (119) work: a jump goes to the first label of that name in the current command list and counts as a step, so a label loop ends 'stepLimit'; a missing label is listed in unsupported and the run continues. Presentation commands (Set Movement Route 205, animation and balloon 212/213, screen fades, tint, flash and shake 221-225, wait 230, show/move/erase picture 231/232/235, weather 236, play/fade audio 241/242/245/246/249/250/251, 505 route rows) are ignored and only counted in cosmetic, not listed in unsupported; the one exception is the switch ON/OFF steps of a Set Movement Route, which do change the simulated switches (changes: 'switch N → ON (move route)'; only the first 1000 route entries are scanned, each costing one step, and a longer route adds an unsupported note). A battleResult of escape or lose on a battle that cannot be escaped or lost still runs the branch but adds a note to changes. Everything else (script 355, other condition types, game-data operands, party and scene commands, ...) is listed in unsupported with its index and skipped; an unsupported condition follows unknownCondition: stop (default) ends the run with ended 'unsupported', then/else takes that branch. Message text is returned verbatim, control codes unexpanded. Limits: 10000 steps (ended 'stepLimit'), integer variable math (results are floored like the engine, so -7 / 2 gives -4; division or modulo by zero leaves the variable unchanged; a random or variable operand is evaluated once per command). A command that changes several switches or variables adds one changes entry for the whole range. messages, changes and unsupported are each capped at 2000 entries; omitted counts what was dropped (present only then) and finalState stays exact. State inputs default to everything OFF/0/empty: switches and variables are keyed by id, selfSwitches by letter A to D, items by item id. choices lists the answers to Show Choices in the order they are asked (0-based; a missing answer is 0, an out-of-range one takes the cancel branch). page is a 0-based page index; when omitted the highest page whose conditions hold under the supplied state is used (the actor condition counts as met). The random operand is seeded (default seed 0), so runs repeat exactly. Returns {messages, changes, transfers, unsupported, cosmetic, ended, finalState, pageUsed}.

Input Schema

NameRequiredDescriptionDefault
goldNoParty gold (default 0).
pageNo0-based page index; omit to pick the page that would be active under the supplied state.
seedNoSeed for the random operand (default 0).
itemsNoItems held by id, e.g. {"4": 1}.
mapIdYesMap id.
choicesNoAnswers to Show Choices, in the order they are asked.
eventIdYesEvent id on that map.
switchesNoSwitch states by id, e.g. {"12": true}.
variablesNoVariable values by id, e.g. {"3": 10}.
battleResultNoHow every Battle Processing command ends, which decides the branch that runs (default win).
selfSwitchesNoSelf switches of this event, e.g. {"A": true}.
unknownConditionNoWhat to do at a condition that cannot be simulated.stop

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.2/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so extensively: it enumerates supported and unsupported commands, states that the project is not mutated, documents the 10000-step limit, entry caps of 2000 with omitted counts, seeded determinism, and the exact return-object keys. This is unusually complete behavioral disclosure for a simulation tool.

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

Conciseness2/5

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

The content is relevant, but it is delivered as a single dense paragraph of roughly 700 words with no headings, bullets, or grouping, making it hard to scan or reference. The front-loaded purpose sentence is good, but after that the structure collapses into an undifferentiated wall of detail.

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

Completeness5/5

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

Given 12 parameters, nested state objects, no output schema, and no annotations, the description still covers return shape, limits, caps, defaults, and unsupported-command handling. There is no material gap an agent would need to fill before invoking the tool correctly.

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 would be 3, but the description adds real meaning beyond the schema: choices are 0-based with missing answers treated as 0 and out-of-range answers taking the cancel branch, page omission selects the highest satisfied page, the random operand is seeded for repeatability, and state inputs default to OFF/0/empty with documented keying conventions. A few inputs such as gold and items get only passing coverage, but the added semantics are substantial.

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 opening sentence states a specific verb and resource ('Dry-runs one map event page against a hypothetical game state') and crisply distinguishes the operation from siblings by saying it returns what the event would do 'without touching the project or running the game'. An agent can tell this apart from lint_events or playtest_start 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 Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'without touching the project or running the game' implies a safe-inspection use case, which is contextual guidance. However, the description never explicitly says when to choose this over lint_events, simulate_battle, or an actual playtest, and it names no exclusions or alternatives. Usage is implied rather than stated.

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