Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@rpgmaker-mz-mcp Create a healing skill called 'Cure' that costs 10 MP"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A high-quality Model Context Protocol (MCP) server for RPG Maker MZ integration. This server provides comprehensive tools for managing game data, maps, events, and system settings through the MCP protocol.
Actor Management: Create, read, update, and search actors
Item/Equipment Management: Manage items, weapons, armors, and skills
Skill Creation: Create custom skills with natural language (NEW!)
Damage skills, healing skills, buffs, debuffs, status effects
Simplified helpers for common skill types
Full customization support
Map Management: Access and modify map data, tiles, and properties
Event Management: Create, update, and manage map events and commands
System Configuration: Update game settings, variables, switches, and vocabulary
Type Safety: Full TypeScript support with comprehensive type definitions
Error Handling: Robust error handling and validation
Related MCP server: RPG Maker MZ MCP Server
npm install
npm run buildSet the RPG Maker MZ project path as an environment variable:
# Windows
set RPGMAKER_PROJECT_PATH=C:\path\to\your\rpgmaker\project
# macOS/Linux
export RPGMAKER_PROJECT_PATH=/path/to/your/rpgmaker/projectnpm startOr directly:
node dist/index.jsAdd to your Claude Desktop configuration file:
Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
{
"mcpServers": {
"rpgmaker-mz": {
"command": "node",
"args": ["C:/path/to/rpgmaker-mz-mcp/dist/index.js"],
"env": {
"RPGMAKER_PROJECT_PATH": "C:/path/to/your/rpgmaker/project"
}
}
}
}get_actors - Get all actors from the project
get_actor - Get a specific actor by ID
update_actor - Update an actor's properties
create_actor - Create a new actor
search_actors - Search actors by name or nickname
get_items - Get all items from the project
get_weapons - Get all weapons from the project
get_armors - Get all armors from the project
get_skills - Get all skills from the project
update_item - Update an item's properties
search_items - Search items by name or description
get_skill - Get a specific skill by ID
create_skill - Create a custom skill with full control
create_damage_skill - Create a damage-dealing skill (simplified)
create_healing_skill - Create a healing skill (simplified)
create_buff_skill - Create a buff skill (simplified)
create_state_skill - Create a state-inflicting skill (simplified)
update_skill - Update a skill's properties
search_skills - Search skills by name or description
get_map - Get map data by ID
get_map_infos - Get information about all maps
get_map_events - Get all events from a specific map
get_map_event - Get a specific event from a map
update_map_event - Update a map event's properties
create_map_event - Create a new event on a map
search_map_events - Search events on a map by name
add_event_command - Add a command to an event page
get_system - Get system data
get_variables - Get all game variable names
set_variable_name - Set a variable name
get_switches - Get all game switch names
set_switch_name - Set a switch name
get_game_title - Get the game title
update_game_title - Update the game title
update_starting_position - Update the game starting position
Once configured, you can use Claude to interact with your RPG Maker MZ project:
Show me all actors in my RPG Maker MZ projectClaude will use the get_actors tool to retrieve and display all actors.
Update actor 1's name to "Hero" and initial level to 5Claude will use the update_actor tool with the appropriate parameters.
Create a new item called "Health Potion" that restores 50 HPClaude will help you create the item with the proper structure.
Find all events on map 1 that contain "treasure" in their nameClaude will use the search_map_events tool to find matching events.
Change the game title to "My Epic Adventure"Claude will use the update_game_title tool to update the system data.
Create a fire magic skill called "Fireball" that costs 15 MP,
targets a single enemy, and deals "a.mat * 4 - b.mdf * 2" damageClaude will use the create_damage_skill tool to create the skill.
Create a group healing spell called "Mass Heal" that costs 30 MP,
targets all allies, and heals "a.mat * 3 + 100" HPClaude will use the create_healing_skill tool to create the healing skill.
{
id: number;
name: string;
nickname: string;
profile: string;
classId: number;
initialLevel: number;
maxLevel: number;
characterName: string;
characterIndex: number;
faceName: string;
faceIndex: number;
battlerName: string;
traits: Trait[];
equips: number[];
note: string;
}{
id: number;
name: string;
note: string;
pages: EventPage[];
x: number;
y: number;
}{
code: number; // Command code (see RPG Maker MZ documentation)
indent: number; // Indentation level
parameters: any[]; // Command parameters
}101 - Show Text
102 - Show Choices
111 - Conditional Branch
112 - Loop
113 - Break Loop
121 - Control Switches
122 - Control Variables
125 - Change Gold
126 - Change Items
201 - Transfer Player
356 - Plugin Command
For a complete list, refer to the RPG Maker MZ documentation.
npm run buildnpm run devrpgmaker-mz-mcp/
├── src/
│ ├── index.ts # Main MCP server
│ ├── tools/
│ │ ├── actorTools.ts # Actor management functions
│ │ ├── itemTools.ts # Item/equipment management
│ │ ├── mapTools.ts # Map and event management
│ │ └── systemTools.ts # System settings management
│ └── utils/
│ ├── fileHandler.ts # File I/O utilities
│ └── types.ts # TypeScript type definitions
├── dist/ # Compiled JavaScript
├── package.json
├── tsconfig.json
└── README.mdBackup Your Project: Always backup your RPG Maker MZ project before making changes
Close RPG Maker MZ Editor: Close the RPG Maker MZ editor when using this server to avoid conflicts
Validate Changes: Test your game after making changes to ensure everything works correctly
Version Control: Use git or another version control system for your project
This server modifies JSON files directly. Make sure the RPG Maker MZ editor is closed when using it
Some advanced features may require manual editing in the RPG Maker MZ editor
Plugin-specific data structures may not be fully supported
Make sure the RPGMAKER_PROJECT_PATH environment variable points to a valid RPG Maker MZ project directory containing:
game.rmmzproject file
data/ directory with System.json
Make sure the RPG Maker MZ editor is closed
Verify the project path is correct
Check that the JSON files have write permissions
Restart Claude Desktop after updating the configuration file.
Contributions are welcome! Please ensure:
Code follows TypeScript best practices
All functions include proper error handling
Type definitions are updated for new features
Documentation is updated accordingly
MIT
For issues and feature requests, please open an issue on the project repository.
Get all items from the project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get all items from the project' which essentially restates the tool name. It does not disclose return format, potential size, pagination, or any permission requirements, leaving the agent with minimal behavioral insight.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short, front-loaded sentence: 'Get all items from the project'. It is appropriately sized for a zero-parameter tool with no wasted words, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For such a simple tool, the description is functional but minimal. Without an output schema, it does not clarify what 'items' includes (e.g., whether it includes weapons/armor) or what the return structure looks like. Given the many sibling tools, a brief clarification of scope would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and the input schema is empty (coverage 100%). With no parameters, the description does not need to elaborate, and the baseline of 4 applies. Nothing additional is required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get'), resource ('all items'), and scope ('the project'), which clearly states what the tool does. However, it does not explicitly differentiate from sibling tools like get_weapons or get_armors, which may overlap with 'items' depending on the game data model.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives. The sibling search_items exists, but the description does not mention when a full 'get all' is appropriate versus a filtered search, nor does it note any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific event from a map
| Name | Required | Description | Default |
|---|---|---|---|
| mapId | Yes | ||
| eventId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read operation ('get') but does not state what happens if the event is not found, the return format, or whether any side effects occur. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no fluff, but it is under-specified. While brevity can be good, here it omits necessary context, making it arguably incomplete rather than efficiently concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, but the description lacks important context such as the return value, relationship to sibling tools, and any behavioral caveats. Without an output schema or annotations, the description is too sparse to fully support correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has two numeric parameters (mapId, eventId) with no descriptions, and the context signals indicate 0% schema description coverage. The description does not explain the meaning or relationship of these parameters beyond what their names already suggest, failing to compensate for the lack of schema hints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('get') and resource ('specific event from a map'), clearly indicating the tool's function. It does not explicitly distinguish from the sibling tool get_map_events, which likely lists events, so it lacks clear sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as get_map_events, update_map_event, or create_map_event. The description does not mention any prerequisites or contexts where this tool would be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all game switch names
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description only states it gets names. No annotations provided, so the description should disclose behavioral traits (e.g., read-only, authentication, side effects). It lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no waste. Very concise, but could include more detail without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a zero-parameter tool, but lacks contextual details like output format or behavior. No output schema or annotations to supplement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so the schema covers 100%. Baseline is 4 for zero parameters, and the description does not need to add param info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clear verb ('Get') and resource ('all game switch names') define the tool's purpose. It is easily distinguishable from sibling tools like 'get_items' or 'get_map_event'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. It does not mention any prerequisites, conditions, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get system data
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read operation but provides no details about the nature of 'system data', potential side effects, or output format. Annotations are absent, so the description should carry the burden but fails.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, making it concise, but it sacrifices informativeness. It is under-specified, not effectively concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description should explain what the tool returns (e.g., system version, settings). It fails to provide sufficient context for an agent to understand the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With no parameters, the schema already covers 100%. The description adds no semantic value beyond the verb, but the lack of params means no enhanced meaning is needed. Baseline 4 is reduced because the description could have clarified what 'system data' encompasses.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get system data' is vague and does not specify what constitutes 'system data' or how it differs from siblings like get_items or get_variables.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., get_items, get_variables). The description lacks any context about typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all game variable names
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden; it only states 'Get all game variable names' without detailing read-only nature or response format, which is adequate but not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with zero waste, front-loading the key action and resource.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is complete enough for an agent to understand its purpose and use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is 100%. The baseline for zero-parameter tools is 4, and the description adds no parameter-specific information beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all game variable names' clearly states the verb ('get') and resource ('game variable names'), distinguishing it from sibling tools like get_items or get_switches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is straightforward and implies a simple retrieval; no explicit when-not or alternatives are needed due to the tool's simplicity, but there is no exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search events on a map by name
| Name | Required | Description | Default |
|---|---|---|---|
| mapId | Yes | ||
| searchTerm | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavioral traits. It only states the basic search function, omitting return format (e.g., an array of events), whether search is case-sensitive or partial-match, and any rate limits or side effects. This is insufficient for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately conveys the tool's function and scope. It contains no filler or redundant information, making it well-structured and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter search tool with no output schema, the description covers the core action but lacks important contextual details such as the return value shape and any search behavior specifics. Given the absence of annotations and output schema, the description does not fully prepare an agent to use the tool effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description implicitly maps 'on a map' to mapId and 'by name' to searchTerm, adding semantic meaning beyond the bare schema. However, it does not explicitly reference parameter names or provide additional details like match type or required format, so the compensation for low schema coverage is partial.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Search events on a map by name' clearly identifies the action (search), the resource (events on a map), and the scope (by name). This distinguishes it from siblings like get_map_events (which likely lists all events) and search_items (which searches a different resource type).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as get_map_events or get_map_event. It does not mention exclusions, prerequisites, or scenarios where this search is preferred, leaving the agent without decision-making context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a switch name
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| switchId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It does not mention whether the operation overwrites existing names, requires specific permissions, handles invalid switch IDs, or produces any response. This is a significant gap for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no unnecessary words. It is appropriately front-loaded and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple with two parameters, but the description lacks usage guidelines and behavioral details. Given the absence of annotations and output schema, it is minimally adequate but leaves room for ambiguity around side effects and error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description adds minimal meaning beyond the schema. It implies 'name' is the new name but does not clarify the format, constraints, or how 'switchId' identifies the switch. The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Set') and resource ('switch name'), making the tool's purpose obvious. It doesn't explicitly differentiate from sibling tools like set_variable_name, but the resource type provides implicit distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_switches, set_variable_name), nor any prerequisites or conditions. The description only states what it does, leaving the agent to infer context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a variable name
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| variableId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states the action without mentioning side effects, permissions, or whether it's a safe reversible operation. The short phrase implies mutation but offers no depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at one sentence, but it under-specifies the tool. It doesn't earn its place because it merely restates the function name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter setter, the description is minimal but lacks context about the operation's behavior, return value, or relationships to sibling tools. The absence of annotations and output schema makes it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description mentions 'a variable name' without explaining the variableId parameter or naming constraints. The description adds no meaning beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a variable name' essentially restates the tool name verbatim, providing no additional scope or differentiation from siblings like set_switch_name. It conveys the basic action but nothing more.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention that it's for renaming a specific variable by ID, nor any context like verifying the variable exists.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0get_itemsget_map_eventget_switchesget_systemget_variablessearch_map_eventsset_switch_nameset_variable_nameScored across 8 tools
Each tool targets a distinct resource or action: items, map events (get vs search), system data, variables (get names vs set name), switches (get names vs set name). No overlapping purposes.
All tools follow a consistent verb_noun pattern using underscores (get_items, search_map_events, set_variable_name). Verbs are appropriate for the action (get, search, set).
8 tools is reasonable for a focused server that inspects and modifies RPG Maker MZ project metadata. Not excessive or insufficient.
The tool set is significantly incomplete. It only provides read and name-setting for variables and switches, lacks CRUD for items and map events, and omits other common data like actors, classes, skills, and variable/switch values.
Campaign manager for D&D and TTRPG GMs: your AI reads and writes a live typed campaign database.
Discover AI tools for game development — 100+ tools indexed by engine, task, and pricing.
Generate game assets with AI: sprites, 3D models, animations, sound effects, music, and voices.
Savecraft serves real save game data and expert game knowledge to AI assistants.
