Skip to main content
Glama

edit_map

DestructiveIdempotent

Edit RPG Maker MV maps in place: paint tiles, fill layers, set encounters, connect maps, rename display names, and organize the tree.

Instructions

Modify existing maps; the affected map files / MapInfos.json are written immediately. action selects the edit: "fill_layer" overwrites an ENTIRE tile layer with one tile ID (destructive, not undoable; layers: 0-1 ground, 2-3 upper, 4 shadow bits 0-15, 5 region IDs 0-255; tileId 0 clears; find valid IDs with get_project_context detail "tileset"); "set_display_names" sets the player-visible displayName of several maps at once (entries whose map file is missing are reported in skipped, not errors); "organize_tree" re-parents maps in the editor tree (purely organizational, gameplay unaffected); "connect" creates a bidirectional pair of transfer events between two maps so the player can walk both ways; "set_encounters" sets the map's random-battle list so enemies appear while walking — encounters is [{troopId, weight?, regionSet?}] (weight default 5; regionSet [] = whole map; troopId must exist) plus optional encounterStep. WITHOUT encounters set, a map has no random battles. Returns a per-action summary. Fails with an error if a referenced map does not exist (except set_display_names, which skips). "paint" writes one tile into cells or a rect of one layer; an autotile is written as its kind and the painted cells and their neighbours get the shapes the editor would give them, so shorelines and walls join up, while the rest of the map keeps its saved shapes. "repair_autotiles" fixes only autotile cells whose shape the engine cannot draw (analyze_project validate reports them as invalid-autotile). For event-level work use manage_map_event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
posANoaction "connect": transfer event position on map A {x, y, trigger} (trigger 1=walk-on default, 0=action button for doors)
posBNoaction "connect": transfer event position on map B {x, y, trigger}
rectNoaction "paint": {x, y, width, height} rectangle to paint (or give cells)
cellsNoaction "paint": [[x, y], ...] cells to paint (or give rect)
layerNoactions "paint", "fill_layer": layer 0-3 tiles, 5 regions (fill_layer also 4)
mapIdNoactions "paint", "repair_autotiles", "fill_layer": map to modify
namesNoaction "set_display_names": [{mapId, name}] — name is what the player sees on map entry
actionYesWhich edit to perform; see the tool description
mapIdANoaction "connect": first map ID
mapIdBNoaction "connect": second map ID
tileIdNoactions "paint", "fill_layer": tile ID (0 = clear); on layer 5 a region id 0-255
foldersNoaction "organize_tree": [{mapId, parentId}] — parentId 0 means root level
encountersNoaction "set_encounters": [{troopId, weight?, regionSet?}] random-battle entries; troopId must exist (create via create_database_entry "troops")
encounterStepNoaction "set_encounters": average steps between random battles (default 30)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changedv5.19.0
    • changedInput schema / properties / action / enum
      Previous value: -[
      -  "fill_layer",
      -  "set_display_names",
      -  "organize_tree",
      -  "connect",
      -  "set_encounters"
      -]New value: +[
      +  "paint",
      +  "repair_autotiles",
      +  "fill_layer",
      +  "set_display_names",
      +  "organize_tree",
      +  "connect",
      +  "set_encounters"
      +]
    • addedInput schema / properties / cells
      Added value: +{
      +  "description": "action \"paint\": [[x, y], ...] cells to paint (or give rect)",
      +  "items": {
      +    "items": {
      +      "type": "integer"
      +    },
      +    "maxItems": 2,
      +    "minItems": 2,
      +    "type": "array"
      +  },
      +  "type": "array"
      +}
    • changedInput schema / properties / layer / description
      Previous value: -"action \"fill_layer\": layer index 0-5"New value: +"actions \"paint\", \"fill_layer\": layer 0-3 tiles, 5 regions (fill_layer also 4)"
    • changedInput schema / properties / mapId / description
      Previous value: -"action \"fill_layer\": map to modify"New value: +"actions \"paint\", \"repair_autotiles\", \"fill_layer\": map to modify"
    • addedInput schema / properties / rect
      Added value: +{
      +  "description": "action \"paint\": {x, y, width, height} rectangle to paint (or give cells)",
      +  "properties": {
      +    "height": {
      +      "type": "integer"
      +    },
      +    "width": {
      +      "type": "integer"
      +    },
      +    "x": {
      +      "type": "integer"
      +    },
      +    "y": {
      +      "type": "integer"
      +    }
      +  },
      +  "type": "object"
      +}
    • changedInput schema / properties / tileId / description
      Previous value: -"action \"fill_layer\": tile ID to write into every cell (0 = clear)"New value: +"actions \"paint\", \"fill_layer\": tile ID (0 = clear); on layer 5 a region id 0-255"
  2. Addedv5.8.0

TDQS

A4.8/5.0
Behavior5/5

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

Goes well beyond the annotations: files are written immediately, fill_layer is destructive and not undoable, missing-map entries are reported in `skipped` rather than erroring for set_display_names, and connect creates bidirectional transfer events. The idempotentHint=true is slightly at odds with event-appending actions like connect, but the description's disclosure quality is high.

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-loads the key mutation warning (immediate write) and then organizes each action as a labeled clause. Dense but every clause carries an action-specific fact; the enumeration could be tighter but little is wasted.

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?

For a 7-action, 14-parameter mutation tool with no output schema, the description covers each action's semantics, error behavior, and return shape (per-action summary). Nothing critical for correct invocation is missing.

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 is 3, but the description adds real meaning: layer numbering (0-1 ground, 2-3 upper, 4 shadow, 5 region 0-255), tileId 0 clears, weight default 5, regionSet [] = whole map, and posA trigger semantics.

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 (Modify) and resource (existing maps) and then enumerates each action with its exact effect. It explicitly differentiates from siblings by routing event-level work to manage_map_event.

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?

Per-action guidance is concrete: it names which action to use for which goal, points to get_project_context detail "tileset" for valid tile IDs, and directs event work to manage_map_event. It also states an exclusion (maps have no random battles without set_encounters).

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