Skip to main content
Glama
Redseb

rpgmaker-mz-mcp

by Redseb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

paint_blueprint

Generate an entire RPG Maker MZ map region from an ASCII blueprint in one call: map glyphs to tiles, multi-layer cells, or A4 walls, then write all validated cells at once.

Instructions

Paint a whole map area from an ASCII blueprint in ONE call and one write. rows are equal-length strings (one glyph per cell); legend maps each glyph to what that cell holds: [[layer, tile], ...] pairs (multi-layer cells, e.g. ground on 0 + fence on 1); a bare string = a catalog tile name on layer 0; { wall: { top, side?, faceHeight?, layer? }, tiles?: [...] } = an A4 wall (or A3 roof) — every cell gets the wall-top kind and the bottom faceHeight (default 1) cell(s) of each vertical run get the wall-side kind (derived as top + 8 kinds = +384 ids unless side is given; a run continuing off the map's bottom edge gets no face); or null = leave the cell untouched. Tiles may be ids or catalog names (exact name, else a unique substring — unknown/ambiguous names are an error). Row lengths, unknown glyphs, names and fit are all validated before anything is written. With clearUpperLayers (default true) each painted cell zeroes the tile layers (0-3) above its lowest specified layer that it does not specify, so stale objects vanish ([] erases the cell). Autotiling is recomputed once per layer, as in paint_tiles. Returns cells painted per layer, cleared count, wall faces made, and a passability overview of the rectangle, judged like the engine's canPass (a step needs the source to allow leaving and the target to allow entry): rows with # = impassable — a cell with no walkable direction (face, water, solid object) or part of a region whose own edge flags refuse entry from the walkable cells around it (an A4 wall-top mass, a stair-less plateau) — and . = walkable ground, plus the impassable [x, y] cells. Stamp multi-tile B/C objects afterwards with place_object.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
rowsYesBlueprint rows, top to bottom; every row the same length, one glyph per cell
mapIdYesThe ID of the map
dryRunNoPreview only: return a diff of what would change without writing to disk.
legendYesGlyph → cell contents (see the tool description for the value forms)
originNo[x, y] map position of the blueprint's top-left cell (default [0, 0])
clearUpperLayersNoZero the tile layers above each cell's lowest specified layer that it does not specify (default true)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.5/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 load and does so: it discloses validation-before-write, the destructive effect of clearUpperLayers (zeroing stale layers, `[]` erases), wall-face derivation rules, off-map edge behavior, and a detailed account of the returned passability data.

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

Conciseness3/5

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

Information-dense and front-loaded with the core idea, but delivered as one massive run-on paragraph mixing parameter syntax, destruction semantics, and return-value detail. It is effective but poorly structured for skimming, and several clauses (e.g. the passability explanation) could be tightened.

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?

No output schema exists, so the description correctly explains the return payload (cells painted per layer, cleared count, wall faces, passability overview with its canPass-derived rules). Combined with full schema coverage, an agent has everything needed to invoke and interpret the call.

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 100%, so the baseline is 3, but the description adds real meaning beyond the schema for `legend` value forms (bare string vs [layer, tile] vs {wall:{...}} vs null, side derived as top + 8 kinds) and the clearUpperLayers/faceHeight defaults. It adds value without fully re-specifying every field.

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?

States a specific verb and resource ('Paint a whole map area from an ASCII blueprint in ONE call and one write') and distinguishes itself from paint_tiles, fill_area, and place_object by naming the latter as the follow-up for multi-tile objects. An agent can tell what this does and where it fits 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 Guidelines4/5

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

Gives clear context: use this for whole-area painting in one write, autotiling behaves 'as in paint_tiles', and multi-tile B/C objects should be stamped afterward with place_object. There is no explicit when-not-to-use or a named alternative for single-tile edits, but the routing guidance is strong.

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