Skip to main content
Glama
Sign In
RPG Maker MZ Authoring MCP

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create map event

create_map_event

Creates a map event at tile coordinates with one or more configurable pages, returning a validated preview and optionally committing the changes.

Instructions

Create a map event with a new ID (lowest free slot, as the editor does) and one or more pages. Each page: {settings?, blocks?}. Defaults match a blank editor page (action button, below characters, no graphic).

Preview-first: returns a change set (semantic + native diff, validation). Pass apply=true to commit immediately when the preview is clean.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mapId": "<mapId>",
      "x": "<x>",
      "y": "<y>"
    },
    "name": "create_map_event"
  }
}

Input Schema

NameRequiredDescriptionDefault
xYesTile X
yYesTile Y
nameNoEvent name (default "EVxxx")
noteNo
applyNoCommit right after a successful preview (non-destructive operations only; needs --allow-write; warnings also need acknowledgeWarnings). Default false = preview only.
mapIdYesMap ID (from list_maps)
pagesNoPages in order (pageIndex 0 first); default one blank page
allowScriptNotrue ONLY if the user explicitly asked to insert JavaScript (script commands, script conditions/operands, route scripts).
descriptionNoOptional description stored in the transaction log
acknowledgeWarningsNoAccept validation warnings when apply=true. Review them with the user first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior4/5

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

Annotations declare readOnlyHint=false and destructiveHint=false, so the safety profile is partly established. The description adds substantive context beyond that: the operation is preview-by-default, returns semantic and native diffs plus validation, and only commits on an explicit flag. It omits failure modes and how the preview output should be presented to the user, keeping it short of a 5.

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?

Two tight paragraphs: identity and payload first, then the preview/apply contract, with the operative word 'Preview-first' leading the second block. Every sentence carries information. Slight terseness in the page-structure notation costs it a point but there is no filler.

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?

For a 10-parameter mutation tool with no output schema, the description covers the essentials: ID allocation, page structure and defaults, and the preview-versus-commit model. It leaves the --allow-write and allowScript/acknowledgeWarnings preconditions to the schema, which is acceptable but means the full commit prerequisites are not visible from the prose alone.

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

Parameters3/5

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

Schema description coverage is 90%, so the schema already carries most parameter meaning, which sets the baseline at 3. The description does add a little beyond the schema by defining the page shape as {settings?, blocks?} and stating that settings default to a blank editor page layout (action button, below characters, no graphic). That is meaningful but limited given how much the schema already documents.

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 gives a specific verb and resource plus the distinctive semantics: a new event gets the 'lowest free slot' ID the way the editor assigns it, and carries one or more pages. That is far more informative than a bare 'create event'. It stops short of naming how it differs from siblings such as create_event_from_template or create_event_page, so an agent must infer that distinction.

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?

The preview-first contract is spelled out clearly: the default returns a change set, and apply=true commits only when the preview is clean. That is real when-to-use guidance for the apply flow. It gives no explicit guidance on when to prefer this over creating an event from a template or adding a page to an existing event, which is the main remaining gap.

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