Skip to main content
Glama

edit_map

DestructiveIdempotent

Modify RPG Maker maps by filling layers, setting display names, reorganizing the editor tree, connecting maps with bidirectional transfers, or configuring random encounters.

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). For event-level work use manage_map_event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesWhich edit to perform; see the tool description
mapIdNoaction "fill_layer": map to modify
layerNoaction "fill_layer": layer index 0-5
tileIdNoaction "fill_layer": tile ID to write into every cell (0 = clear)
namesNoaction "set_display_names": [{mapId, name}] — name is what the player sees on map entry
foldersNoaction "organize_tree": [{mapId, parentId}] — parentId 0 means root level
mapIdANoaction "connect": first map ID
mapIdBNoaction "connect": second map ID
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}
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)
Behavior5/5

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

Discloses that fill_layer is destructive and not undoable, writes immediately, and per-action error behavior. Matches annotations: destructiveHint=true, idempotentHint=true. Adds context like layer ranges, tile clearing, and encounter defaults beyond annotations.

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?

Description is moderately sized and front-loaded with main purpose. Each sentence contributes, but could be slightly tighter (e.g., repeating 'action' reference). Still well-structured and readable.

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?

Covers all 5 actions, parameters, side effects, error handling, and links to related tools. No output schema, but 'Returns per-action summary' suffices. Complex tool (12 params, nested) fully addressed.

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% with parameter descriptions, but tool description adds critical context (e.g., layer meanings, tile ID source via get_project_context, encounter format). Enriches understanding beyond schema alone.

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?

Tool name 'edit_map' and title 'Edit map' are clear. Description begins with 'Modify existing maps' and enumerates 5 distinct actions, each with specific purpose. Distinguishes from sibling tools like 'manage_map_event' and implicitly from 'generate_map'.

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?

Explicitly states 'For event-level work use manage_map_event' as alternative. Each action's use case is described (e.g., 'organize_tree' is purely organizational, 'set_encounters' affects random battles). Provides conditions like required map existence and exception for set_display_names.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/DiegoLopez0208/RpgMakerMVUltimate-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server