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

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create event from template

create_event_from_template

Create complete RPG Maker MZ map events from templates such as NPC dialogue, treasure chests, doors, quests, switches, and cutscenes, with preview-first validation before applying changes.

Instructions

Create a complete event from a template: npc (dialogue), treasure_chest, door (transfer), quest_npc (multi-stage via a variable), switch_lever, cutscene_trigger. Use list_event_templates for parameters. The result is previewed like any other change.

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>",
      "template": "<template>",
      "x": "<x>",
      "y": "<y>"
    },
    "name": "create_event_from_template"
  }
}

Input Schema

NameRequiredDescriptionDefault
xYes
yYes
nameNo
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)
paramsNo
templateYes
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

A4.3/5.0
Behavior4/5

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

Annotations already declare non-read-only, non-destructive, non-idempotent, closed-world; the description adds real behavior beyond them: the call returns a change set (semantic + native diff, validation) and only commits with apply=true. It doesn't restate the schema's --allow-write / acknowledgeWarnings caveats in prose, but the core preview/commit semantics are clearly disclosed and consistent with the 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?

Two short, front-loaded blocks: what gets created, then how the preview/apply lifecycle works. Dense and waste-free, though the template enumeration is written in a terse list form that takes a moment to parse.

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 a nested free-form object and no output schema, the definition covers the two things an agent most needs: where the parameter set comes from and that the call is preview-first. Remaining gaps (coordinate semantics, name/description effect on the created event) are minor and largely covered by the schema.

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 only 50% and the free-form `params` object has no schema documentation, but the description compensates by naming valid `template` values and pointing to list_event_templates as the source of truth for parameters. It adds little about x/y/name/description, which are self-evident or schema-documented.

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 and resource ('Create a complete event from a template') and immediately enumerates the concrete template families (npc/dialogue, treasure_chest, door/transfer, quest_npc, switch_lever, cutscene_trigger), which makes the tool distinguishable from siblings like create_event_page or create_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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent to list_event_templates to discover the parameter set, and explains the preview-then-apply flow ('Pass apply=true to commit immediately when the preview is clean'). It does not state when to prefer create_event_page/create_map_event over this template path, so no exclusions are given.

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