Skip to main content
Glama
DiegoLopez0208

RPG-MAKER-MV-MCP

by DiegoLopez0208
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

manage_map_event

Destructive

Create, update, convert, or delete RPG Maker MV map events, including NPCs, chests, doors, shops, inns, bosses, and puzzles; map file saves immediately.

Instructions

Create, change or remove map events; the map file is written immediately. action "create" without preset makes a bare event at x/y (empty page unless pages; then use add_command or insert_event_commands). With preset it builds a ready event: "npc" {name, dialogues[], characterName?, characterIndex?}; "chest" one-time loot {items: [{type item|weapon|armor, id, amount}]}; "teleport" walk-on transfer {destMapId, destX, destY, trigger?}; "door" action-button warp {destMapId, destX, destY, characterName?, characterIndex?, trigger?, lockedSwitchId?, lockedMessage?}, locked until that switch is ON; "shop" {goods: [[type 0 item/1 weapon/2 armor, id, priceType 0 standard/1 custom, price]]}; "inn" {cost?}; "boss" {troopId} one-time battle, game over on loss; "puzzle_switch" {switchX, switchY, doorX, doorY, gameSwitchId, switchName?, doorName?} makes two linked events. IDs and destinations are not validated (check with query_database and query_map). "update" overwrites only fields. "convert" keeps an event's id, position, name and sprite but replaces its behaviour via kind: "merchant" (options.goods, or options.items [{type, id}], options.greeting?), "inn" (options.cost?), "sign" (options.text). "delete" removes it (destructive). "add_command" appends one command before a page's end. "populate" scatters N npc/chest/boss events at random positions (walkability not checked; check with query_map "ascii"). Returns the event(s) with ids; fails if the map or event 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

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv5.12.2
    • changedInput schema / properties / action / enum
      Previous value: -[
-  "create",
-  "update",
-  "delete",
-  "add_command",
-  "populate"
-]New value: +[
+  "create",
+  "update",
+  "convert",
+  "delete",
+  "add_command",
+  "populate"
+]
    • addedInput schema / properties / kind
      Added value: +{
+  "description": "action \"convert\": what to turn the existing event into",
+  "enum": [
+    "merchant",
+    "inn",
+    "sign"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / options
      Added value: +{
+  "description": "action \"convert\": kind-specific settings — merchant {goods|items, greeting?}, inn {cost?}, sign {text}",
+  "type": "object"
+}
  2. Addedv5.8.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations cover the safety profile (destructiveHint, non-idempotent), and the description adds substantial context beyond them: the map file is written immediately, IDs/destinations/walkability are not validated, chest and boss are one-time, boss loss causes game over, delete is destructive, and it fails when the map or event doesn't exist. That is exactly the extra layer annotations can't express.

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?

Front-loaded with the action/preset overview, which is good, but it then becomes a single ~340-word paragraph mixing actions, presets, and inline parameter schemas that partly restate the input schema (e.g., the goods and items tuples). Dense and hard to scan for a 36-param tool; tightening would help.

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 6-action, 8-preset, 36-parameter tool with no output schema, the description covers every action, every preset's required inputs, cross-tool dependencies (create_database_entry, manage_system, query_map), the immediate-write side effect, and the return/error contract ("Returns the event(s) with ids; fails if the map or event does not exist"). Nothing an agent needs to invoke it correctly 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 value the schema lacks: it groups which parameters belong to which preset, explains cross-parameter coupling (puzzle_switch links two events via gameSwitchId; door stays locked until lockedSwitchId is ON), and states defaults. It duplicates some field docs (goods/items) rather than adding, keeping it at 4.

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?

Opens with a specific verb triad plus resource ("Create, change or remove map events") and immediately distinguishes its scope from structural siblings like edit_map or insert_event_commands. An agent can tell what this tool owns without opening the schema.

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?

Gives per-action routing: bare create vs preset create, when to fall back to add_command/insert_event_commands for empty pages, when to use convert vs update, and pre-flight checks (query_database/query_map, query_map "ascii" for walkability). No explicit top-level "don't use this for X" exclusions, so it stops short of a 5.

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