Click on "Install 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 provided; description only states 'Get all items,' implying a read operation but lacks details on permissions, rate limits, or other behavioral traits.
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, concise and front-loaded with no extraneous information.
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?
Minimal description for a simple tool with no parameters and no output schema. Adequate but lacks additional context that could help.
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 in schema, so schema coverage is 100%. Baseline is 3; description adds no param-related information.
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?
Description clearly states verb and resource: 'Get all items from the project.' It distinguishes from sibling tools which operate on different resources (map events, system, variables, 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?
No guidance on when to use this tool versus alternatives. No mention of context or exclusions.
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 provided. Description only states 'Get', implying read-only, but lacks details on side effects, permissions, rate limits, or return format. Minimal disclosure beyond basic intent.
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 is concise and front-loaded, but lacks supporting detail. Not every sentence earns its place; additional context for parameters or behavior is missing.
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, no annotations, and minimal description, the tool is under-specified. An agent would not know parameter types (though implied by names) or expected return value.
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%. Description does not mention parameters or add meaning beyond the schema. Two numeric parameters (mapId, eventId) are defined in schema but not contextualized.
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 a specific event from a map' clearly states the action (get) and resource (event from a map), distinguishing it from sibling tools like search_map_events (search) and get_items (different resource).
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 when to use this tool versus alternatives. Sibling 'search_map_events' exists for searching, but no explicit when to use get_map_event vs search.
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?
No annotations are provided, so the description must disclose behavior. It only states the search action but does not mention safety aspects (e.g., read-only), result limits, or potential side effects. This is insufficient for a search 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?
Single sentence, straight to the point. No extraneous information. However, the brevity may sacrifice clarity for 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?
For a simple tool with two basic parameters, the description covers the core action. However, it omits return behavior, error conditions, and any filtering details, leaving the agent with limited actionable information.
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 0% schema description coverage, the description should elaborate on parameters. It hints that searchTerm is used for name matching but provides no detail on mapId (e.g., its source or constraints). Partial but inadequate compensation.
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 'search' and identifies the resource 'events on a map' with a qualifier 'by name'. It is clear about the basic function but does not distinguish from siblings like get_map_event, which could be for individual event retrieval.
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 such as get_map_event or get_items. Missing context on typical use cases or scenarios where a different tool would be more appropriate.
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?
No annotations exist. The description implies mutation but does not disclose whether the operation is idempotent, requires authorization, or overwrites existing names. Lack of behavioral context beyond the basic verb.
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, which is short but fails to convey necessary information. True conciseness would include key details without verbosity; here it under-specifies the tool's behavior and parameters.
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 lack of annotations, output schema, and parameter descriptions, the context is incomplete. For a mutation tool with two required parameters, more guidance on inputs and effects is needed.
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 no parameter meaning. Both parameters (switchId, name) are left undefined. An agent cannot infer constraints like name format or switchId source.
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 switch name' clearly indicates the action (set) and the resource (switch name). It distinguishes from sibling tools like set_variable_name which operate on different resources. However, it could be more specific about what a switch is.
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 usage guidelines are provided. The description does not specify when to use this tool, prerequisites, or alternatives (e.g., use get_switches to view existing switches).
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?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states 'set', implying mutation, but omits side effects, permissions, or any trait beyond the trivial verb.
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?
Extremely concise at 5 words, but this is under-specification rather than efficient conciseness. Every sentence must earn its place, but this one fails to convey necessary information.
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?
Inadequate for a tool with 2 required parameters and no other support. Missing context about return values, prerequisites, or parameter relationships. Complete picture is absent.
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%, yet the description adds no meaning beyond the parameter names. No explanation of what 'variableId' refers to or constraints on 'name'.
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?
Description is a tautology: 'Set a variable name' merely restates the tool name without specifying what variable or context, and fails to distinguish it from siblings like get_variables or set_switch_name.
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 such as get_variables or set_switch_name. The description provides no context for appropriate usage.
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. Dates show when Glama detected each change.
v1.0.0get_itemsget_map_eventget_switchesget_systemget_variablessearch_map_eventsset_switch_nameset_variable_nameEach 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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
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.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/k4zuki0539/-rpgmaker-mz-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
