Skip to main content
Glama
Xerolo44

RPG Maker MV MCP Server

by Xerolo44
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Analyze progression

analyze_progression

Analyzes RPG Maker MV project progression to find reachable and unreachable maps, dead pages, and blocked goals, showing whether a target map, event, or switch can be reached without running the game.

Instructions

Answers 'can the player get from the start map to X, and what can never happen?' for the whole project, without running the game. Model (an over-approximation): starting at System startMapId, a page may run whenever its page conditions could hold, and when it runs ALL of its commands take effect. Switches only ever turn ON, items are never lost, and conditions inside event commands (branches, choices) are ignored. So 'unreachable' (maps, pages, goals) is a proof under the model, while 'reachable' only means 'not ruled out'. It cannot see script commands (355), plugin commands (356), variable-designated transfers or battles, enabled plugins (parameters, notetags) or anything else a plugin does. Each of those, an unreadable map or an unreadable js/plugins.js lowers uncertainty.confidence to 'low'; only trust 'unreachable' and 'dead' results when confidence is 'high'. Returns reachableMaps, unreachableMaps, deadEndMaps (no exit), deadPages (pages that can never run, with the first unmet condition), switches/variables read-but-never-set and set-but-never-read, edges (direct transfers), notes, a plain-language summary and names (map id to name). goal (exactly one of switch, mapId or event) adds a verdict with up to 10 blockedBy reasons. includeGraph adds a Mermaid flowchart of the map transfers. Lists are cut at limit (the summary counts stay exact); truncated is also set when an analysis cap was hit (see notes). Staged changeset data is analysed.

Input Schema

NameRequiredDescriptionDefault
goalNoWhat to check, exactly one key: { switch: n }, { mapId: n } or { event: { mapId, eventId } }.
limitNoMost entries per list in the report.
includeGraphNoAlso return a Mermaid flowchart of the direct map transfers.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.6/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 exceptionally: it spells out the over-approximation model (switches only turn on, items never lost, branches ignored), enumerates exactly what it cannot see (355/356, variable transfers, battles, plugins), and explains how each gap degrades confidence. This is exactly the behavioral context 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.

Conciseness4/5

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

It is dense and long, but front-loads the core question, then the model, then limitations, then outputs — a logical flow where nearly every sentence adds information. Slightly verbose in the limitations enumeration, but no sentence is pure filler.

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?

There is no output schema, yet the description fully enumerates the return surface (reachableMaps, unreachableMaps, deadEndMaps, deadPages with first unmet condition, switch/variable usage, edges, notes, summary, names) plus truncation caveats and staged-changeset behavior. Nothing an agent needs to interpret results 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 100%, so the baseline is 3; the description goes further by explaining that goal (one of switch/mapId/event) yields a verdict with up to 10 blockedBy reasons, that includeGraph emits a Mermaid flowchart, and crucially that limit truncates lists while summary counts stay exact and 'truncated' also flags analysis caps.

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?

The opening sentence gives a precise verb and resource — a static reachability/dead-code proof over the whole project without running the game. It is immediately distinguishable from execution-oriented siblings like simulate_event, playtest_start, and validate_project.

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?

It clearly frames the mode of use ('without running the game') and gives explicit trust rules: only rely on 'unreachable'/'dead' when confidence is 'high', and treat 'reachable' as merely 'not ruled out'. It doesn't name specific sibling alternatives (e.g. simulate_event) as the fallback, so it stops short of 5.

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