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

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

replace event logic

replace_event_logic

Replace a command list's complete logic with new IR or block arrays, previewing semantic and native diffs plus validation before applying. Requires the list revision to reject stale edits.

Instructions

Replace the complete logic of a list with new IR ({irVersion:1, blocks} or a block array). Prefer minimal edits unless a rewrite was requested. Keep raw_command blocks you received to preserve unsupported commands. Requires the list revision.

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": {
      "revision": "<revision>",
      "logic": "<logic>"
    },
    "name": "replace_event_logic"
  }
}

Input Schema

NameRequiredDescriptionDefault
applyNoCommit right after a successful preview (non-destructive operations only; needs --allow-write; warnings also need acknowledgeWarnings). Default false = preview only.
logicYes
mapIdNoMap ID (map event page target)
eventIdNoMap event ID (map event page target)
troopIdNoTroop ID (troop battle page target)
revisionYesRevision token of the command list from get_event_logic / get_event_page (rejects stale block ids)
pageIndexNoZERO-based page index (map event or troop 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
commonEventIdNoCommon event ID (common event target)
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.6/5.0
Behavior5/5

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

Beyond the annotations (which only say non-read-only, non-destructive, non-idempotent), the description discloses the real interaction model: it previews by default and returns a change set with semantic and native diff plus validation, and only commits with apply=true. It also reveals the revision-token requirement and that stale block ids are rejected, which is behavior an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four tight sentences, front-loaded with what the tool does and the payload format, then the editing-policy caveat, then preservation guidance, then the preview/apply workflow. No sentence is padding and the operationally critical preview-first behavior is set off clearly.

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 an 11-parameter mutation tool with no output schema, the description covers the two hardest things an agent needs: what the payload looks like and that the default call is a safe preview returning a diff. The gap is target context — it never says that one of the map/troop/common-event target params must be supplied to identify the list being rewritten, leaving that entirely to 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 91%, so parameter documentation is largely handled by the schema and the baseline would be 3. The description still adds meaning beyond it by explaining the accepted IR shape of 'logic' ({irVersion:1, blocks} or a block array) and the commit semantics of 'apply=true' when the preview is clean. It contributes nothing about the target-selection parameters (mapId/eventId/troopId/pageIndex/commonEventId), which keeps 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?

The description states a specific verb and resource ('Replace the complete logic of a list') and specifies the accepted payload shape ('{irVersion:1, blocks} or a block array'). The word 'complete' plus 'Prefer minimal edits unless a rewrite was requested' implicitly separates it from block-level siblings such as replace_event_block, so an agent can tell the wholesale-rewrite tool from the incremental-edit tools.

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?

It gives clear when-to-use/when-not-to-use guidance: use this only when a rewrite was requested, otherwise prefer minimal edits, and preserve raw_command blocks received earlier. It also explains the preview-first workflow and that apply=true commits. It stops short of naming an explicit alternative tool to use for the minimal-edit case, so it lands at 4 rather than 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