Skip to main content
Glama
Redseb

rpgmaker-mz-mcp

by Redseb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

render_map

Screenshot an RPG Maker MZ map as the game draws it to catch wrong tiles, void areas, odd sprites, or missing images. Returns PNG path plus console and missing-asset errors.

Instructions

Screenshot a map as the game actually draws it: boots the project headless, starts a new game on the map, and saves a PNG. Validators prove structure, not looks — use this to catch wrong wall/autotile kinds, void (unbased transparent tiles), odd sprites or missing images. Default renders the WHOLE map (canvas resized to width×height×48px, player hidden, autorun/parallel events frozen, map-name banner off); pass x+y for a normal 816×624 game-screen view centred on that tile. Returns the PNG path plus problems — console errors, page errors and HTTP 404s (missing assets — a missing image is drawn blank instead of stopping the engine on its load-error retry screen). Read-only. Needs the optional dependency playwright-core and a Chromium from the Playwright cache (npx playwright install chromium-headless-shell) or the RPGMAKER_MCP_CHROMIUM env var.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xNoWith y: render a normal screen view centred on this tile instead of the whole map.
yNo
outNoOutput .png path, or a directory. Default: <os tmpdir>/rpgmaker-mz-mcp/renders.
mapIdYesMap to render.
inlineNoAlso return the PNG(s) as image content in the response (default false: paths only — read the file to view it).
switchesNoSwitch ids to turn ON first, to see event pages of a later story state.
runEventsNoLet autorun/parallel events run before the shot (default false: resting map).
showEventsNoDraw event sprites (default true). false = bare tiles only.
showPlayerNoDraw the player (default: hidden for a whole-map render, shown for a view).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares read-only, explains what the default whole-map render does (canvas resized to width×height×48px, player hidden, autorun/parallel events frozen, banner off), what passing x+y changes, what `problems` surfaces (console/page errors, HTTP 404s, blank-drawn missing images), and the required dependency/env var.

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?

Front-loaded with the core purpose in the first clause, then layered detail. It is dense with em-dash clauses, and the dependency paragraph is a long tail, but nearly every sentence carries information an agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter tool with no annotations and no output schema, the description covers defaults, return values (PNG path + problems), side-effect profile (read-only, frozen events), and prerequisites. Nothing critical for a correct invocation is missing.

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 already 89%, so the baseline is 3, but the description adds real semantics: the interaction of x+y (jointly producing an 816×624 centred view), the whole-map default dimensions, and the practical meaning of switches/runEvents. It goes beyond restating the schema even if some overlap remains.

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?

Opens with a specific verb+resource ('Screenshot a map as the game actually draws it') and immediately scopes it against the validator siblings ('Validators prove structure, not looks'). An agent can distinguish it from validate_project/validate_assets without opening a schema.

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

Usage Guidelines5/5

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

Explicitly states when to reach for it ('to catch wrong wall/autotile kinds, void ... odd sprites or missing images') and contrasts it with the structural validators it complements. It also flags the required runtime dependency and install command, which is genuine usage guidance.

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