Skip to main content
Glama

Generate map

generate_map

Generate a dungeon or cave map procedurally in RPG Maker MV, paint it with a tile profile, and place entrance, exit, and chest markers in an existing or new map.

Instructions

Procedurally generate a dungeon (rooms joined by corridors) or a cave (organic, one connected region) and paint it with a tile profile. Give exactly one of mapId (generate into an existing map, using its size and tileset) or create (make a new map and register it in MapInfos.json). An existing map that has any tile or any event is refused unless overwrite is true; overwrite resets every tile layer and removes all events. seed makes the result repeatable; when omitted a random seed is picked, and the seed used is always returned. The profile (floor, wall, optional wallTop, optional weighted decor) defaults to suggestTileProfile, which works from the tileset's data only: the lowest-numbered walkable A2 kind as floor (else the first walkable A5 tile), the lowest-numbered blocking A4 wall kind as wall with the floor-rule A4 kind above it as wall top (else the first blocking A5 or B tile), and no decor. The profile used and the reasoning are returned as profileUsed and profileNotes. Nothing is written when the profile's floor is not walkable, its wall or wall top does not block movement, a sheet has no image, or the painted map is not fully reachable from the entrance. Markers are empty placeholder events at priority 0 (below characters, so they never block the player) named Entrance, Exit and Chest 1..n, placed on floor cells; chests are random floor cells away from the entrance and exit, chosen so that no chest cuts off any part of the map. markers defaults to {entrance: true, exit: true, chests: 0}. The result lists each marker's eventId and position under markers. Afterwards: call render_map_image to look at the result (consider showPassability); wire doors to other maps with connect_maps using the returned entrance and exit coordinates; fill the chest markers with create_event_from_template or the event tools. A marker occupies its tile: delete it with delete_event before placing a door or chest there, or pass allowOverlap (connect_maps) / allowStack (create_event_from_template) to place on top of it. A dungeon needs a map of at least 14x7 (or 7x14) cells; smaller maps are refused with a clear error (caves are reliable from about 13x13, and MV's default 17x13 never failed in testing; 9x9 to 12x12 and thin maps fail for many seeds, so try another seed or a larger map). Limits: decor is best-effort (sparse, only on open floor), and wall faces are a one-row simplification, since many tilesets draw wall sides two or more tiles tall.

Input Schema

NameRequiredDescriptionDefault
kindYes
seedNoSame seed, size and options give the same layout; random when omitted
mapIdNoExisting map to generate into (use instead of `create`)
createNoNew map to create (use instead of `mapId`)
markersNo
profileNoTiles to paint with; defaults to a suggestion from the tileset
overwriteNoAllow replacing a map that already has tiles or events

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.7/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 discloses that overwrite resets every tile layer and deletes all events, enumerates the four conditions under which nothing is written (a transactional guarantee), explains seed determinism and that the seed is always returned, and declares limits (decor is best-effort, wall faces are a one-row simplification).

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?

It is front-loaded (what it does first, then parameters, then workflow, then limits) and nearly every sentence carries unique information. It is nonetheless a dense block of prose with the size-requirement guidance and limits appended as run-on sentences, which hurts scannability.

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, yet the description tells the agent what the result contains (seed, profileUsed, profileNotes, and markers with eventId and position), so return values need no further documentation. For a 7-parameter nested-object generator with no annotations, nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

It adds meaning well beyond the 71%-covered schema: the mutual exclusivity of mapId and create is not encoded in the schema but is stated explicitly, the seed's reproducibility contract is described, the markers default object is restated with the tile-occupancy consequence, and the profile default is fully explained via the suggestTileProfile resolution rules.

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?

The description opens with a precise verb+resource ('Procedurally generate a dungeon … or a cave') and even defines what each kind produces (rooms joined by corridors vs. one organic connected region). It doesn't explicitly contrast itself with siblings like create_map or paint_tiles, so an agent must infer that this is the generative path rather than the manual one, keeping it short of a 5.

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?

It states the exclusive mapId-vs-create choice, the overwrite precondition, the refusal conditions, and then prescribes the follow-up workflow (render_map_image to inspect, connect_maps for doors, create_event_from_template for chests, delete_event/allowOverlap for marker placement). Alternative selection and sequencing are spelled out rather than inferred.

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