Skip to main content
Glama

manage_map_event

Destructive

Create, modify, or remove events on a map. Use presets for NPCs, chests, shops, doors, teleports, inns, bosses, and puzzle switches to quickly build interactive gameplay elements.

Instructions

Create, modify or remove events on a map; the map file is written immediately. action "create" without preset makes a low-level event at x/y (empty page unless pages given; add behavior later with add_command). action "create" WITH preset builds a complete, ready-to-play event: "npc" (2-page dialogue NPC: {name, dialogues[], characterName?, characterIndex?}), "chest" (one-time loot: {items: [{type: item|weapon|armor, id, amount}]} — IDs not validated, confirm with query_database), "teleport" (one-way walk-on transfer zone: {destMapId, destX, destY, trigger?} — destination not validated), "door" (action-button warp into another map, e.g. a house entrance: {destMapId, destX, destY, characterName?, characterIndex?, trigger?, lockedSwitchId?, lockedMessage?}; with lockedSwitchId it shows a "locked" message until that game switch is ON), "shop" ({goods: [[type 0=item/1=weapon/2=armor, id, priceType 0=standard/1=custom, price]]}), "inn" ({cost?} full-recovery flow with gold check), "boss" ({troopId} one-time battle, game over on loss), "puzzle_switch" ({switchX, switchY, doorX, doorY, gameSwitchId, switchName?, doorName?} creates TWO linked events). action "update" overwrites only fields on an event; action "convert" RE-PURPOSES an existing event in place — keeping its id, position, name and sprite but replacing its behaviour — via kind: "merchant" (a working shop; pass options.goods [[type,id,priceType,price]] or the friendly options.items [{type,id}], plus optional options.greeting), "inn" (options.cost? full-recovery flow with gold check), "sign" (options.text string or string[] read-only message); ideal for "turn this NPC into a merchant" without re-placing it; "delete" removes it permanently (DESTRUCTIVE); "add_command" appends one command before a page's terminator; "populate" scatters N events of a kind (npc/chest/boss) at random positions (walkability not checked — validate with query_map "ascii"). Returns the created/updated event(s) with ids. Fails with an error if the map (or event, for update/delete) does not exist.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoTile X position (0-based; create/presets except puzzle_switch)
yNoTile Y position (0-based)
costNopreset "inn": gold charged for a full recovery (default 50)
kindNoaction "convert": what to turn the existing event into
nameNoEvent name shown in the editor
optsNoaction "populate": overrides {name, troopId, x, y}
countNoaction "populate": how many events (default 3)
destXNopreset "teleport"/"door": destination tile X (should be walkable)
destYNopreset "teleport"/"door": destination tile Y
doorXNopreset "puzzle_switch": door tile X
doorYNopreset "puzzle_switch": door tile Y
goodsNopreset "shop": wares [[type, id, priceType, price]] — priceType 1 uses the custom price, 0 the database price
itemsNopreset "chest": loot [{type: "item"|"weapon"|"armor", id, amount}]
mapIdYesMap the event lives on (always required)
pagesNoaction "create" without preset: full event page objects (optional)
actionYesWhat to do; see the tool description. Default "create"
fieldsNoaction "update": properties to overwrite, e.g. {"x": 5, "y": 9} or {"pages": [...]} (replaces all pages)
presetNoaction "create" only: ready-made event recipe; omit for a low-level empty event
commandNoaction "add_command": event command {code, indent, parameters}; e.g. 201=Transfer Player [0, mapId, x, y, dir, fade]
eventIdNoExisting event ID (update/delete/add_command); find it with query_map view "events"
optionsNoaction "convert": kind-specific settings — merchant {goods|items, greeting?}, inn {cost?}, sign {text}
switchXNopreset "puzzle_switch": floor-switch tile X
switchYNopreset "puzzle_switch": floor-switch tile Y
triggerNoHow the event activates: 0=action button, 1=player touch, 2=event touch, 3=autorun, 4=parallel
troopIdNopreset "boss" / populate boss: troop to battle (create it first via create_database_entry preset encounter_troop)
doorNameNopreset "puzzle_switch": editor name for the door event (default "Door")
destMapIdNopreset "teleport"/"door": destination map ID
dialoguesNopreset "npc": dialogue lines, each becomes one text box
eventTypeNoaction "populate": kind of events to scatter — "npc", "chest" or "boss"
pageIndexNoaction "add_command": which page receives the command (0-based, default 0)
switchNameNopreset "puzzle_switch": editor name for the switch event (default "Switch")
gameSwitchIdNopreset "puzzle_switch": game switch linking switch and door — pick an unused ID via manage_system get switches
characterNameNoSprite sheet from img/characters/ without extension; list options with get_project_context
lockedMessageNopreset "door": message shown while locked (default "It's locked.")
characterIndexNoWhich of the 8 characters in the sheet (0-7)
lockedSwitchIdNopreset "door": if set, the door shows lockedMessage until this game switch is ON, then warps
Behavior5/5

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

The description discloses behaviors beyond annotations: immediate write ('written immediately'), destructive nature of delete ('DESTRUCTIVE'), no validation for IDs or walkability, and side effects of convert (replaces behavior in place). Annotations already indicate destructiveHint=true, but description adds rich context.

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?

The description is long but well-structured: grouped by action and preset with clear hierarchy. Every sentence adds value, though some redundancy could be trimmed (e.g., repeating 'action'). Given the complexity (36 params, 6 actions, 8 presets), it is appropriately concise.

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?

The description covers return values ('Returns the created/updated event(s) with ids') and failure conditions ('Fails with an error if the map... does not exist'). No output schema exists, so return description is minimal but adequate. Could add more on error messages or pagination, but overall complete for the tool's complexity.

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

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema coverage, baseline is 3, but the description adds extensive semantics: explaining role of each preset, required fields for nested objects (e.g., items for chest, goods for shop), and behavioral nuances (locked door, puzzle_switch creating two events). It significantly enhances understanding beyond schema descriptions.

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 clearly states the tool's purpose: 'Create, modify or remove events on a map'. It distinguishes multiple actions (create, update, convert, delete, add_command, populate) and presets, providing specific details for each, differentiating it from siblings like edit_map or create_database_entry.

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?

The description gives explicit guidance for each action and preset, including when to use alternatives (e.g., 'add behavior later with add_command'), validation notes (IDs not validated, destination not validated), and prerequisites (map must exist). It also references sibling tools like query_database and get_project_context for further steps.

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