Skip to main content
Glama

scene_import_simulator

Destructive

Imports a simulator save into a new .gil game level, translating Lua, templates, signals, variables, and server rules so simulator content can be played and checked in Genshin.

Instructions

Bring a project of the 千星沙箱模拟器 (miliastra-beyond-simulator, the simulator outside the game for 2D + Lua levels) into a copy of a save, in one call, so that it can be played in the game itself: what passes in a simulator has not passed in the game. save is the simulator's full save (the .json it writes with 导出 → 完整存档; format "qxqy-simulator-save"). Everything it holds is written with the tools of this server: its Lua scripts (the text in the save, or the file beside it), its templates of client controls, its interface with the scripts on the controls that carried them, the rectangles of each device where they differ; the signals its scripts and its server rules name are defined, the variables its rules set are added to the player; and its server rules (when a signal comes from a script: set variables, send signals back) are written as the source of a node graph on the level entity and compiled. Template indices are the save's own after this, so every number in the Lua that was the index of a template in the simulator is put to the new index (only numbers of the Lua itself, never inside a string or a comment). The result says what was written, what could not be (notes: a look of a button the game has no state for, a parameter a rule reads and no script adds; the fill, soft edge and inverted mask of an image come over, and so do signals with several values, typed after what the scripts add), and what scene_check_client finds in the scripts against the finished save. Then playtest_start {mapPath} plays it. Reads the file format only; none of the simulator's code is used. Writes a new .gil in the workspace.

Input Schema

NameRequiredDescriptionDefault
saveYes
mapPathNo
outputNameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Annotations only mark destructiveHint=true; the description adds real behavioral context beyond them: it writes a NEW .gil in the workspace (rather than mutating the input save), remaps template indices in Lua text but never inside strings/comments, and reports a limitations list (missing button states, parameters read by rules but never set). It also discloses what does and does not carry over (image fill/soft edge/inverted mask come over; multi-value signals are typed from scripts).

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 in the first clause, which is good, but the remainder is a dense chain of semicolon-separated clauses and nested parentheticals that is hard to parse in one pass. Some of the enumeration (individual UI-state notes) could be trimmed without losing decision-relevant information.

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 complex import tool with no output schema, the description covers what gets written, what gets reported back, and what to do next, which is most of what an agent needs. The gaps — the meaning of outputName and the role of mapPath for this tool itself — keep it short of complete.

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

Parameters3/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 compensate. It documents `save` thoroughly (full simulator save, the .json written via 导出 → 完整存档, format 'qxqy-simulator-save'), but `mapPath` is only referenced incidentally through playtest_start and `outputName` is never explained at all, leaving two of three parameters opaque.

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 description names a specific verb+resource ('bring a project of the 千星沙箱模拟器 ... into a copy of a save') and disambiguates from siblings by describing an end-to-end import-and-write workflow, clearly distinct from the granular scene_add_* / scene_set_* tools. The parenthetical identifiers (miliastra-beyond-simulator, qxqy-simulator-save) make the target 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 states the condition that motivates the tool ('what passes in a simulator has not passed in the game') and names the follow-up tools (scene_check_client against the finished save, then playtest_start {mapPath}). It does not state when NOT to use it, e.g. whether re-importing over an already-imported save is safe or idempotent.

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