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

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

remove event block

remove_event_block

Remove an event-logic block by ID, including nested branches, using a required revision token; preview the change set first, then apply to commit.

Instructions

Remove one block (and 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>"
    },
    "name": "remove_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.
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.8/5.0
Behavior4/5

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

Annotations only supply the boolean profile (readOnly=false, destructive=false, idempotent=false), so the description carries the burden and does well: it declares the default is a non-committing preview, that the preview includes semantic + native diff and validation, and that removal is recursive. It stops short of stating permission prerequisites beyond what the apply parameter already documents.

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?

Two tight sentences, front-loaded with the action and scope, followed by the preview-first commit rule. No filler and nothing repeated from the schema.

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 action, side effects, default non-committing behavior, and the shape of the preview response. Minor gaps remain around write-permission gating and warning acknowledgement, though the schema covers those parameters.

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 91%, so most parameters are already documented structurally. The description adds one useful semantic point beyond the schema: that the list revision is mandatory and tied to the block id's validity, but it says nothing about the target-scoping parameters or acknowledgeWarnings behavior.

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?

States a specific verb and resource ('Remove one block ... by id') and clarifies the blast radius by noting nested branches are removed too. It is distinguishable from siblings like move_event_block or replace_event_block, though it never names an alternative explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Explains the preview-then-commit workflow clearly (default returns a change set; pass apply=true to commit), which is real usage guidance. However, it gives no criteria for choosing this over replace_event_block/delete_event_page or for when removal versus restructuring is appropriate.

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