Skip to main content
Glama
Redseb
by Redseb

set_event_page

Update an RPG Maker MZ event page's graphic, trigger, priority, movement, and flags in a single call, keeping its command list intact. Includes validation and force override.

Instructions

Update an existing event page's graphic and behavior in one call, without rebuilding the whole page or touching its command list: sprite (characterName/characterIndex/direction/pattern or a tileId), trigger, priority, movement (type/speed/frequency/route), and the through/walkAnime/stepAnime/directionFix flags. Graphic fields merge onto the current image; warns (never blocks) on an unknown characterName. Refuses the write if the change would leave the event unreachable (an action-button page with priority below on an impassable tile) — pass force: true to override.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
forceNoWrite even if validation finds structural problems (wrong parameter count, unterminated command list). Off by default: such a write is refused and nothing is written. Advisory warnings never block regardless.
mapIdYesThe ID of the map
dryRunNoPreview only: return a diff of what would change without writing to disk.
indentNo(unused; page-level tool)
tileIdNoUse a tile as the graphic instead of a sprite (0 = none)
eventIdYesThe ID of the event
patternNoSprite animation frame 0–2 (1 = idle)
throughNoLet the player/others pass through the event
triggerNoWhat starts the page
verboseNoEcho the full written record instead of the default summary. Off by default: the response reports identity, counts and command-list shape, which is what you would assert on, and omits the parameters/conditions you would only re-read. Read the full record with the matching get_* tool.
moveTypeNoAutonomous movement (custom uses moveRoute)
priorityNoStacking vs. the player: below/same/above characters (same = solid)
directionNoFacing direction of the sprite
moveRouteNoAutonomous move route (from create_move_route); pairs with moveType "custom"
moveSpeedNoMovement speed 1–6 (4 = normal)
pageIndexYesZero-based page index
stepAnimeNoAnimate in place while stopped
walkAnimeNoAnimate the walk cycle while moving
directionFixNoLock the facing direction
characterNameNoSprite sheet basename (from list_assets("characters")); "" = no sprite
moveFrequencyNoMovement frequency 1–5 (3 = normal)
characterIndexNoSprite index 0–7 in the sheet
Behavior5/5

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

With no annotations provided, the description carries the full burden and does so excellently. It discloses that graphic fields merge onto the current image, warns (never blocks) on unknown characterName, and refuses unreachable-event writes unless force:true is passed. These behaviors are critical for an agent to predict outcomes and avoid failures.

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?

The description is a single dense sentence that is front-loaded with the main purpose and packs all key behavioral details. It is long but every clause contributes, making it appropriately sized for a tool with 22 parameters, though slightly less structured than ideal.

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 complex tool with 22 parameters and no output schema, the description covers the essential behaviors: merge semantics, warnings, refusal conditions, and force override. The response format is partially explained within the verbose parameter schema, so the description is reasonably complete for the context.

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 coverage is 100% and every parameter is described in the input schema. The description adds only high-level grouping (sprite, trigger, priority, movement, flags) and does not introduce meanings beyond what the schema already provides. Baseline 3 applies for high schema coverage.

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 clearly states the tool updates an existing event page's graphic and behavior in one call. It distinguishes itself from siblings by explicitly noting it does not rebuild the whole page or touch the command list, separating it from command-insertion tools like add_event_command and insert_event_commands.

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 description implies when to use this tool (when you want to update graphic/behavior without rebuilding the page) but does not explicitly name alternative tools or state exclusions. Phrases like 'without rebuilding the whole page or touching its command list' provide clear context but lack explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Redseb/rpgmaker-mz-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server