Skip to main content
Glama

Build a whole map in one call

make_map
DestructiveIdempotent

Creates or updates an RPG Maker MZ map from a paint plan, resolving tile layers and passage flags in one transaction to prevent walkability issues.

Instructions

One intent — "a 26x18 field of grass, with a stone floor and a wall ring and a gap for the door" — as one call. It makes or reuses the map, sets its tileset, resolves the entire paint plan, writes it in one pass, applies the passage flags the plan names, and answers with the rendered map. Before this the high-level layer stopped at content and every build script had to drop to create_map + set_tiles per map, which is where the depth mistakes came from. The plan is resolved to one tile per cell, the last stroke winning, because that is how the engine decides passage: Game_Map.checkPassage reads tile layers 3 down to 0 and returns on the first tile whose flags say something, so a wall left on layer 3 underneath a floor tile still blocks the doorway — the map renders as a room and the player cannot walk out of it. Paint ground first, then what sits on it, and nothing is ever stacked. On a repaint the plan owns the cell's whole stack: every layer it does not name is zeroed, so last run's roof cannot survive under this run's floor. Each tile still lands on the layer its own slot belongs to (A1/A2 → 1, A3 → 2, A4 → 3, A5/B–E → 0); that is set_tiles with layer omitted, so a forest is never buried under the grass again. flags is handed to set_tileset_flags for this map's tileset in the same transaction, so "these ids are walls" is stated where the walls are painted. regions paints layer 5 for make_encounter_zone to roll on. The reply counts the walkable cells the finished terrain leaves, because a map with no walkable cell is not something the engine will report — it is a game that boots and never moves.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fillNoTile id for every cell, under all the paint strokes
findNoReuse the map whose tree name equals this, making it if there is none — the idempotent form for a build script
nameNoThe map's name in the map tree
flagsNo`set_tileset_flags`' own `tiles` entries ({tileId|range, passable, blockFrom, bush, counter, terrainTag, …}), applied to this map's tileset
mapIdNoRe-paint this map instead of making one
paintNoRectangles and cell lists, applied in order over `fill`; later strokes win
widthNoRequired for a new map; ignored on a repaint (resizing means rebuilding the tile array)
dryRunNoReport the plan and write nothing
heightNo
regionsNoPainted on layer 5, on top of whatever tile is there
parentIdNoMap-tree parent for a new map (default 1)
tilesetIdNoRequired for a new map; changing it on a repaint re-reads every tile id against the new flags
propertiesNo`set_map_properties`' own fields: displayName, disableDashing, battlebacks, parallax, bgm/bgs, encounterStep, encounters…
clearRegionsNoErase these region ids from the whole map first

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare idempotentHint and destructiveHint; the description goes well beyond by explaining the one-tile-per-cell, last-stroke-wins resolution, the layer-zeroing on repaint, the passage-flag behavior, the layer assignment per slot, and the transaction enclosing set_tileset_flags. This is rich behavioral disclosure. It docs the dryRun and the idempotent find semantics, though it does not state the destructive nature of repaint explicitly except through the zeroing behavior.

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 description is long and somewhat dense, moving between a scenario story, engine internals, and per-parameter behavior. It is front-loaded with the one-call intent, which is good, but several sentences could be trimmed without losing value, and the engine-internals digression is longer than necessary for tool selection.

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?

Given 14 parameters, nested objects, no output schema, and destructive+idempotent annotations, the description covers the important behavioral and transactional details. It could be more complete on the output (it mentions the reply counts walkable cells), and on permissions, but for a high-level composite tool it is fairly complete.

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 93%, so the schema already documents most parameters. The description adds meaning beyond the schema by explaining the resolution semantics (last stroke wins), paint ordering (ground first, then what sits on it), layer-zeroing on repaint, and how flags/regions/properties map to sibling tools. This is well above the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a concrete verb+resource ('makes or reuses the map, sets its tileset, resolves the paint plan, writes it in one pass, applies passage flags') and distinguishes itself from the low-level alternative ('create_map + set_tiles per map'). It is clear it is a high-level composite tool. It does not explicitly name siblings like create_map as alternatives by name, but it does reference the low-level pattern, which is close enough for a 4.

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?

Usage context is clear: it is the high-level one-call form that replaces dropping to create_map + set_tiles per map, and it names the idempotent form via 'find'. It explains when to prefer this over the lower-level layer. It does not enumerate when-not-to-use, but the alternative framing is strong.

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