Skip to main content
Glama

Make a tile a wall, a ladder, a bush

set_tileset_flags
DestructiveIdempotent

Edit RPG Maker MZ tileset flags to set tile passability, blocking, ladders, bushes, counters, damage, and terrain tags across all maps without the editor.

Instructions

Edit what tiles do, without the editor. MZ keeps this as an 8192-entry flags array per tileset: 0x01/0x02/0x04/0x08 are impassable from Down/Left/Right/Up, 0x10 makes those four override the layers underneath, 0x20 ladder, 0x40 bush, 0x80 counter, 0x100 damage floor, 0x200/0x400/0x800 boat/ship/airship, and bits 12 up are the terrain tag. Passage is per direction, so passable: false is a fence and blockFrom: ["up"] is a ledge you can step onto but not climb back off. One bit has to be handled for you: MZ's 0x10 means "no effect on passage" — Game_Map.checkPassage skips the tile entirely — and much of the stock tileset (the pillars, trees and statues among others) ships with it set, so writing passage bits into one of those tiles without clearing it reports success and blocks nothing. Any passage change therefore clears 0x10 unless you pass overwrite: true on purpose, and the reply says when it did. For an A1-A4 autotile the id a map stores is one of 48 shapes of a base pattern and the engine reads the flags of that stored id, so a change is applied across the whole shape group unless shapes: false says otherwise; the reply reports which ids moved and what each flag became. This reaches every map that uses the tileset at once, which is the point and the danger: dryRun shows the before and after without writing, and validate_game re-checks the maps that now block.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tilesYes
dryRunNoReport what would change and write nothing
tilesetIdYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A4.2/5.0
Behavior5/5

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

Goes well beyond the idempotent/destructive annotations by disclosing non-obvious mechanics: the automatic clearing of 0x10 (with overwrite:true escape), the A1-A4 48-shape group propagation (with shapes:false), the global reach across maps, and what the reply reports. This is exactly the kind of hidden side effect an agent needs.

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?

Front-loads 'Edit what tiles do, without the editor' effectively, but then delivers a single dense paragraph of bit-level detail. Every sentence is informative, yet the wall-of-text format and heavy parenthetical asides hurt scanability for an agent.

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 complex mutation tool with no output schema and low schema coverage, the description supplies the missing pieces: flag semantics, the 0x10 gotcha, shape-group scope, global blast radius, dryRun preview, and follow-up validation. An agent has enough to call it correctly.

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 only 33%, and the description compensates strongly, giving semantic meaning the schema lacks (passable:false as a 'fence' vs blockFrom:['up'] as a 'ledge'), explaining the overwrite/0x10 interaction and the shapes group default. It adds real interpretation beyond the raw bit descriptions.

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+resource: editing tile flag/passability bits in an MZ tileset's 8192-entry flags array, and names concrete effects (wall, ladder, bush). The purpose is unmistakable, though it never names a sibling (e.g., set_tiles or describe_tiles) to draw the boundary explicitly.

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 operational context: use dryRun to preview, validate_game to re-check affected maps, and warns the change reaches every map using the tileset. It does not explicitly state when to choose this over siblings like set_tiles or describe_tiles, so it stops short of full when/when-not guidance.

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