Skip to main content
Glama
DiegoLopez0208

RPG Maker MV Copilot MCP

by DiegoLopez0208
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

analyze_project

Read-onlyIdempotent

Inspect an RPG Maker MV project read-only: validate consistency, trace switches and variables, graph map transfers, audit balance, and search dialogue.

Instructions

Read-only project intelligence over an in-memory model of the whole project, cached until data files change. Nothing is written. view selects the lens: "overview" (default) title, counts, a health summary with the top issues, and maps unreachable from the start map; "index" maps with event counts, common events, named switches/variables; "validate" every consistency check (transfers to missing maps, missing map files, references to missing common events/items/weapons/armors/troops/animations, duplicate IDs, unused named switches/variables, bad start position, unreachable maps, autotiles the engine cannot draw, image/audio files missing from img/ and audio/) as {issueCount, bySeverity, issues[]}, filter with severity; "graph" the map transfer network and reachability; "usage" every event, common event and troop that uses kind (switch/variable/common_event/item/weapon/armor/troop/animation/actor/state/map) id, with read/write roles; "explain" target "switch"/"variable" + id: whether it is set, read, gated, a dead write or never set (why a door never opens); target "map" + id: incoming transfers and what becomes unreachable without it; "ast" one event page (mapId, eventId, page?) or common event (commonEventId) as a logical tree with an outline; "plugins" js/plugins.js merged with each plugin's header (@plugindesc/@param/@command/@help), flagging missing files; "critique" a designer's review of one map (mapId) with suggestions and a rough score; "metrics" measurements of one map (mapId): reachability from the real entry (unreachable tiles and events are softlocks), dead space against expected (interior/dungeon/exterior), walkable skeleton (loops, critical path, linearity), tile entropy, and steps to a shop/inn/save when the map has encounters; "balance" each skill/weapon/armor/enemy against its peers (damage per MP, gold per stat point, HP per EXP), leaving each out of its own statistics; category, thresholdSd (default 2); formulas are parsed, never executed, and unreadable ones are listed; "refactor" command sequences copy-pasted across events, to extract into a common event; "search" ranks names, dialogue, descriptions and notes against a free-text query.

Input Schema

NameRequiredDescriptionDefault
idNoviews "usage"/"explain": numeric id of the switch/variable/map/entity to inspect
kindNoview "usage": what kind of entity `id` refers to
pageNoview "ast": which page of the event (0-based, default 0)
viewNoWhich lens to apply (default "overview")
limitNoview "search": max results (default 20)
mapIdNoview "ast": the map holding the event to parse
queryNoview "search": Unicode text matching over names/dialogue/notes, e.g. "the blacksmith". Offline lexical search, no synonym or translation expansion. Check complete, skippedFiles and warnings.
minLenNoview "refactor": minimum shared command-run length to report (default 4)
targetNoview "explain": what `id` refers to (default "switch")
eventIdNoview "ast": the event on `mapId` to parse
categoryNoview "balance": analyse one category instead of all four (default "all")
expectedNoview "metrics": what kind of space this map is meant to be, which sets the dead-space band (default "exterior")
severityNoview "validate": keep only issues of this severity
thresholdSdNoview "balance": how many standard deviations from its peers an entry must sit before it is flagged (default 2; raise to see only the worst)
commonEventIdNoview "ast": parse this common event instead of a map event

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv5.21.0
    • changedInput schema / properties / query / description
      Previous value: -"view \"search\": free-text query, e.g. \"the blacksmith\", \"dark forest\""New value: +"view \"search\": Unicode text matching over names/dialogue/notes, e.g. \"the blacksmith\". Offline lexical search, no synonym or translation expansion. Check complete, skippedFiles and warnings."
  2. Changed4 schema fields changedv5.19.0
    • addedInput schema / properties / category
      Added value: +{
+  "description": "view \"balance\": analyse one category instead of all four (default \"all\")",
+  "enum": [
+    "skills",
+    "weapons",
+    "armors",
+    "enemies",
+    "all"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / expected
      Added value: +{
+  "description": "view \"metrics\": what kind of space this map is meant to be, which sets the dead-space band (default \"exterior\")",
+  "enum": [
+    "interior",
+    "dungeon",
+    "exterior"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / thresholdSd
      Added value: +{
+  "description": "view \"balance\": how many standard deviations from its peers an entry must sit before it is flagged (default 2; raise to see only the worst)",
+  "type": [
+    "number",
+    "string"
+  ]
+}
    • changedInput schema / properties / view / enum
      Previous value: -[
-  "overview",
-  "index",
-  "validate",
-  "graph",
-  "usage",
-  "explain",
-  "ast",
-  "plugins",
-  "critique",
-  "refactor",
-  "search"
-]New value: +[
+  "overview",
+  "index",
+  "validate",
+  "graph",
+  "usage",
+  "explain",
+  "ast",
+  "plugins",
+  "critique",
+  "metrics",
+  "balance",
+  "refactor",
+  "search"
+]
  3. Addedv5.12.2

TDQS

A4.5/5.0
Behavior5/5

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

Annotations already declare read-only, idempotent, and non-destructive behavior, but the description adds valuable context: the in-memory cache invalidates when data files change, formulas are parsed but never executed, unreadable formulas are listed, and search is offline lexical with no synonym expansion. These details exceed the annotation coverage and no annotation contradiction exists.

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?

The description is front-loaded with the core purpose and caching behavior, which is good. However, the remainder is a single dense run-on sentence enumerating thirteen views, which harms scannability and could be better structured with bullets or shorter sentences.

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?

Given no output schema, the description fully explains what each view returns—from validate's {issueCount, bySeverity, issues[]} to ast's logical tree and outline. Annotations cover the safety profile, and the schema covers all 15 parameters, leaving no critical gap for correct invocation.

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 the semantics of each `view` enum value in detail—what 'validate' checks, what 'metrics' measures, what 'balance' compares—adding meaning beyond the schema's terse enum labels and short parameter descriptions.

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 description opens with a precise verb and resource: 'Read-only project intelligence over an in-memory model of the whole project, cached until data files change.' It then enumerates every analysis lens, making the tool's scope unmistakable and clearly distinct from mutating siblings like edit_map or create_database_entry.

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?

The description gives clear guidance on which `view` to choose for each analytical need (e.g., 'validate' for consistency checks, 'metrics' for map measurements), effectively serving as when-to-use guidance for the tool's modes. It does not, however, explicitly name sibling tools or state when not to use this tool versus alternatives like query_map or get_project_context.

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