Skip to main content
Glama
twrsm666

rpgmaker-mcp

by twrsm666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Make a project that did not come from the editor bootable

fix_project
DestructiveIdempotent

Adds only missing System.json keys the engine requires, such as advanced.windowOpacity, and restores switches/variables arrays so projects start without a title-screen crash.

Instructions

Write the System.json keys the engine reads without a fallback and this project does not have. An installation ships data/newdata as a third way to start a project besides the editor, and that template has no advanced.windowOpacity: the game stops on the title screen's first window with a stack that names clamp and nothing about the missing key, and a project copied from the template is otherwise indistinguishable. The values come out of your own installation's template — they belong to the engine, so this package does not carry a copy of them; advanced.windowOpacity is the one key the template itself lacks, and 192 is what the editor writes. It also puts switches and variables back into the array shape the engine indexes, and writes only what is genuinely absent, so running it on a project the editor made changes nothing. It does not invent maps, events or a start position: validate_game reports those and set_startup writes them. dryRun answers with the plan alone.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dryRunNoReport what would be written and change nothing
templateNoA System.json to take the missing values from. Default: <install>/data/newdata/data/System.json, found through RMMZ_CORESCRIPT_ROOT

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare idempotentHint=true and destructiveHint=true, so the safety profile is framed. The description adds real value on top: only genuinely absent keys are written, values come from the installation template rather than the package, and dryRun returns a plan. It explains provenance and the write-avoidance behavior the annotations do not.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

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

The description is an undivided run-on narrative of several hundred words for a two-parameter tool. Key facts (dryRun behavior, sibling alternatives) are buried mid-paragraph rather than front-loaded, forcing the agent to extract signal from dense prose.

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?

For a repair tool with no output schema, the description covers what gets written, what does not (maps, events, start position), the no-op case, and what dryRun returns. It is functionally complete, though the density makes it harder to consume than its content warrants.

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 both parameters are documented, setting the baseline at 3. The description still adds meaning: dryRun 'answers with the plan alone' and template values come from your installation, clarifying where the default and the written values originate.

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 states a specific verb+resource: it writes the System.json engine keys a project is missing without a fallback. It also implicitly separates itself from siblings by noting it does not invent maps/events/start position. The core purpose is recoverable but buried in a long narrative, so it takes effort to parse.

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 names alternatives and the selecting condition: validate_game reports missing maps/events/start position and set_startup writes them, while this tool handles only engine keys. It also clarifies that running on an editor-made project changes nothing, which helps an agent decide when it is a no-op.

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