Skip to main content
Glama
Sign In
RPG Maker MZ Authoring MCP

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Map passability grid

get_map_passability
Read-onlyIdempotent

Map where the player can walk using the engine's exact passage rules. Returns an ASCII grid, reachability from an origin, separate walkable areas, and events with active pages to verify paths and triggers.

Instructions

Text map of where the player can walk, using the engine's exact passage rules (directional tile bits, star tiles, wall tops, counters, blocking events). Returns an ASCII grid (2 characters per cell: walls drawn between cells), reachability from an origin (default: player start or the first transfer arrival), the separate walkable areas, and every event with its active page and whether the player can trigger it. Works without image support.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "mapId": "<mapId>"
    },
    "name": "get_map_passability"
  }
}

Input Schema

NameRequiredDescriptionDefault
fromNoReachability origin (default: player start on this map, else the first transfer arrival)
mapIdYes
assumeNoGame state used to pick each event's active page. Default: all switches/self switches OFF, variables 0, no items.
regionNoMap cells to cover (default: whole map)
includeNoDefault ["grid","areas","events"]; "cells" lists ladders, bushes, counters, damage floors, terrain tags and regions
ignoreEventsNoIgnore events (tiles only). Default false: blocking events count as obstacles.
ignoreEventIdsNoEvents that never block (e.g. NPCs that will have moved away)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered elsewhere. The description adds real value by enumerating the returned artifacts (ASCII grid with 2 chars per cell, reachability, separate walkable areas, per-event active page and triggerability) and by stating the assumed game state default (all switches off, variables 0, no items).

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?

Two sentences, front-loaded with the purpose before the return details, and the parenthetical rule list is informative rather than filler. It is dense but every clause carries content; minor tightening of the rule enumeration would make it a 5.

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?

With seven parameters, nested objects, and no output schema, the description does the heavy lifting on return values and defaults, which is the main risk area. The remaining gap is the region/ignore filtering options, which are covered by schema text rather than the description.

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 86%, so parameters are largely self-documenting and the baseline of 3 applies. The description reinforces the origin default and the blocking-event semantics, but leaves region, ignoreEvents, and ignoreEventIds entirely to the schema without adding interpretive meaning.

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 concrete verb+resource (a text map of walkable cells) and pins down the rules used: "the engine's exact passage rules (directional tile bits, star tiles, wall tops, counters, blocking events)." It also implicitly separates itself from the visual sibling by noting it "Works without image support," so an agent can tell it apart from render_map without opening either 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 operating context: reachability is computed from an origin defaulting to player start or first transfer arrival, and it works when images aren't available, which hints at the render_map alternative. It stops short of an explicit "use this instead of X when Y" routing statement or any when-not 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