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 block

replace_event_block

Replace an event block and all nested branches by ID with a preview-first change set, then commit after validation.

Instructions

Replace one block (including all of its nested branches) by id. 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>",
      "blockId": "<blockId>",
      "block": "<block>"
    },
    "name": "replace_event_block"
  }
}

Input Schema

NameRequiredDescriptionDefault
applyNoCommit right after a successful preview (non-destructive operations only; needs --allow-write; warnings also need acknowledgeWarnings). Default false = preview only.
blockYesOne Event IR block
mapIdNoMap ID (map event page target)
blockIdYes
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

A3.9/5.0
Behavior4/5

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

Beyond the annotations (readOnlyHint=false, destructiveHint=false, idempotentHint=false), the description discloses the consequential behavior that nested branches are affected, that a revision token guards against stale block ids, that the default response is a change set containing semantic and native diffs plus validation, and that apply=true commits. It does not restate permission requirements (--allow-write, allowScript) that the annotations do not cover, but the preview-first model is well explained.

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 paragraphs, front-loaded with the mutating scope before the preview/apply workflow. There is mild overlap between 'Preview-first: returns a change set' and 'Pass apply=true to commit', but no filler sentences or restated name/title.

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 12-parameter mutation tool with a nested block object and no output schema, the description covers the essentials an agent needs to call it safely: required revision, preview-by-default, and the commit switch. Target-selection parameters (mapId, eventId, troopId, commonEventId, pageIndex) and the allowScript caveat are left entirely to the 92%-covered schema, which is acceptable but leaves the description slightly thin on context selection.

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 92%, so the schema already carries nearly all parameter meaning, including the apply flag's commit semantics and the revision token's stale-id rejection. The description's mention of the revision requirement and apply=true largely duplicates that, adding little syntax or format detail beyond it. Baseline 3 is appropriate when the schema does the heavy lifting.

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 states a specific verb and resource ('Replace one block ... by id') and immediately qualifies the scope with 'including all of its nested branches', which is the key semantic difference from a leaf-level edit. It does not name a sibling (e.g. replace_event_logic, insert_event_blocks, move_event_block) to contrast with, so it stops short of full differentiation.

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 operational guidance: the call is preview-first by default, and apply=true commits 'when the preview is clean', plus the prerequisite 'Requires the list revision'. What is missing is explicit routing to alternatives — nothing tells the agent when to prefer replace_event_logic, insert_event_blocks, or the standalone preview/apply sibling tools.

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