The RPGMakerUltimate-MCP server provides comprehensive tools to manage and create RPG Maker MV game projects across these areas:
Database Management Create, read, update, delete, and search actors, classes, skills, items, weapons, armors, enemies, states, troops, common events, animations, and tilesets. Includes simplified builders for damage/healing skills, boss enemies, and random encounter troops.
Map Management
Create blank, themed, template-based (106 bundled templates), or procedurally generated maps (Perlin noise, BSP dungeon, cellular automata across 21 themes)
Batch map generation, duplication, validation (detects invalid tile IDs, broken event commands, null references)
Edit tile layers, set display names, organize map tree hierarchy
Connect maps with bidirectional transfer events
Render maps as offline ASCII art with event markers and region IDs
Event Creation
Full CRUD for map events and low-level event command insertion
High-level builders for NPCs (multi-page dialogue), treasure chests, teleporters, shops, inns, boss battles, and puzzle switch/door pairs
Bulk populate maps with NPCs, chests, or bosses at random positions
System Settings Get/update game title, switch/variable names, player starting position, and full System.json data.
Project Management
Project summaries, full context digests (tilesets, maps, actors, items, switches, variables, sprites)
Asset scanning to index images and tile metadata
Tile ID categorization (ground, water, wall, roof, decoration) per tileset
Runtime project switching without restarting the server
Image & Vision Analysis
Send project images (tilesets, sprites, screenshots, battlers, faces) to any OpenAI-compatible vision API for AI descriptions
Offline tileset grid analysis and screenshot quadrant color extraction (no API required)
Enables AI-driven analysis of project images (tilesets, screenshots, etc.) using NVIDIA's vision models via the analyze_screenshot tool.
Enables AI-driven analysis of project images (tilesets, screenshots, etc.) using Ollama's vision models via the analyze_screenshot tool.
Enables AI-driven analysis of project images (tilesets, screenshots, etc.) using OpenAI's vision models via the analyze_screenshot tool.
Quick start · What it does · Map generation · Live bridge · Intelligence · Tools
A Model Context Protocol server that lets an AI agent work on a real RPG Maker MV project on disk — database, maps, events, plugins, system — through 13 consolidated tools validated against the actual engine, so what comes out is coherent and playable.
It does three things that are usually missing:
🏗️ Builds | Generates maps that look hand-made, wires events from presets, and edits every database with real IDs instead of invented ones. |
🧠 Understands | Reads the whole project and answers why the door never opens, which map nobody can reach, which skill breaks the game. |
👀 Watches | Runs the game and reports back: exceptions, player position, screenshots — and reloads a map you just edited without losing the save. |
1 — Add it to your MCP client. No clone needed; the package ships an executable.
{
"mcpServers": {
"rpgmaker-mv": {
"command": "npx",
"args": ["-y", "rpgmaker-mv-mcp"],
"env": {
"RPGMAKER_PROJECT_PATH": "C:/path/to/your/RPGMakerMV/project"
}
}
}
}# Claude Code, user scope
claude mcp add rpgmaker --scope user \
--env RPGMAKER_PROJECT_PATH="C:/path/to/project" \
-- npx -y rpgmaker-mv-mcp# From source
git clone https://github.com/DiegoLopez0208/RpgMakerMVUltimate-MCP
cd RpgMakerMVUltimate-MCP
npm install && npm run build
RPGMAKER_PROJECT_PATH=/path/to/your/project npm startMCP clients load tool definitions once at startup, so restart the client after adding or upgrading the server.
2 — Point it at a project. RPGMAKER_PROJECT_PATH is the folder containing data/, js/ and index.html. The server starts without it; call set_project_path at runtime instead if you prefer.
3 — Let the agent look around first.
get_project_context { detail: "full" } → what exists, with real IDs
analyze_project { view: "overview" } → health, counts, unreachable mapsWorks with Claude Desktop, Claude Code, opencode, and any MCP-compatible client.
Related MCP server: RPG Maker MZ MCP Server
flowchart LR
A["🤖 Agent"] -->|"generate_map · manage_map_event"| B["📁 Project on disk"]
B -->|"validate · balance · metrics"| A
B -->|"playtest"| C["🎮 Running game"]
C -->|"exceptions · position · screenshots"| A
A -->|"reload_map"| CThe bottom half of that loop is what the bridge adds. Before it, the agent wrote files and hoped.
Two paths, both behind generate_map. Pick by whether your project uses RTP art.
|
| |
How | Clones a hand-authored map from the 106 bundled RTP templates, closest size first | Lays out a mission graph, then paints it through a tileset profile |
Looks like | Real multi-tile buildings, walls, furniture | Rooms and corridors shaped by what the space is for |
Tilesets | RTP, or close to it | Any — DLC, itch.io, custom |
Guarantees | Same | Same |
{ "mode": "procedural", "theme": "town", "name": "Riverbend", "width": 40, "height": 30 }Themes with a matching template — town, village, dungeon, interior, castle, world and more — clone a real map instead of painting tile noise. Themes without one (beach, swamp, desert…) fall back to Perlin terrain, BSP dungeons and cellular caves. Combat themes auto-wire random encounters from your existing troops; town and village auto-create enterable house interiors with two-way warps.
Themes ·
foresttownvillagecastledungeoncavebeachdesertswampruinsinteriorsnowharborvolcanosewerfortressmagic_forestmagic_interiorspace_interiorspace_exteriorworld
Other modes: blank (empty canvas), themed (simple layout), template (one specific bundled map), batch (many at once), duplicate (copy an existing map).
The bundled templates are raw MV map JSON, so their tile IDs only mean anything on RTP sheets. Change the tileset and the map turns to noise. semantic keeps the layout abstract until the last moment:
manage_system { action: "mine_templates" } # learn from THIS project
generate_map { mode: "semantic", tilesetId: 5, rooms: 6, seed: 42 }Mining reads every map you already made and derives semantic layouts (ground / wall / water / prop / door, multi-tile props kept whole), a tileset profile naming the concrete tile your project uses for each role, and token adjacency counts. Nothing in the project is modified — everything lands in .mcp-cache/.
Generating builds the mission first — entrance → key → locked door → treasure → boss → exit, plus side rooms — as a graph whose edges are the only ways through, then paints it. Because the lock is an edge and the key sits on the entrance side of it, the map is solvable by construction. Autotile shapes are recomputed at the end from the finished neighbourhood, never guessed cell by cell.
The result includes markers naming the cell of every mission role, which is where to put events with manage_map_event.
Pass a mined templateId (e.g. "mined-3") to re-materialise one of your own maps onto a different tileset.
playtest on its own is fire-and-forget: the game opens and nothing comes back. The bridge closes the loop.
manage_system { action: "install_bridge_plugin" } # once per project
manage_system { action: "bridge_start" } # opens ws://127.0.0.1:32123
manage_system { action: "playtest" } # the game connects on its own
manage_system { action: "bridge_telemetry", types: ["exception", "log"] }sequenceDiagram
participant A as 🤖 Agent
participant S as 🖥️ MCP server
participant G as 🎮 Game (nwjs)
A->>S: edit_map
S->>S: atomic write to Map002.json
A->>S: bridge_command reload_map
S->>G: reload_map
G->>G: reserveTransfer + _needsMapReload
G-->>S: reload_complete
A->>S: take_screenshot
S->>G: capture_screenshot
G-->>S: PNG in base64
S-->>A: path for analyze_image📡 Telemetry — exceptions with stack traces, console.error/warn, scene changes, player position, which event command is executing (so a hung event can be pinpointed), FPS and heap. Frames are consumed as you read them unless you pass peek.
♻️ Hot reload — reload_map re-reads the current MapXXX.json and rebuilds the scene without losing party state: it reserves a transfer to the player's own position with _needsMapReload, the engine's own reload seam, rather than rebuilding Spriteset_Map by hand. reload_database re-reads one data file; System.json and Tilesets.json need a fresh playtest and are refused with an explanation.
📸 Screenshots — take_screenshot { name: "collision-proof" } captures the live playtest through the MCP plugin, saves a timestamped PNG under .mcp-cache/screenshots/, and returns its path for inspection or QA evidence. No shell screenshot command is involved. manage_system { action: "bridge_screenshot" } remains as a compatibility alias.
🔒 Security
The plugin returns before anything else runs unless the game is under NW.js and was launched with a
testargument. A deployed build a player double-clicks never reaches the socket code, or evenrequire('fs').It checks every argument rather than only
argv[0]the wayUtils.isOptionValiddoes, becauseplaytestpasses the project path first. So a deployed build deliberately launched with a literaltestargument would get past the guard — and then find no handshake file, and never connect.The server binds
127.0.0.1only, refuses any upgrade carrying a browserOrigin(cross-site WebSocket hijacking), and requires the session token from.mcp-bridge.json— compared in constant time — within 5 seconds or the connection is dropped.The command surface is a fixed allowlist with no
evalprimitive.
analyze_project is read-only and fully offline. It models the whole project once, so an agent can reason about a game it did not build.
View | Answers |
| Call this first. Counts, health summary, maps unreachable from the start |
| Every consistency problem at once — see below |
| Why does this never happen? e.g. "Switch 12 is gated in 3 places but never set ON" |
| Every event, common event and troop that touches a switch/variable/item, with read-write roles |
| The map transfer network and what is reachable |
| One event's logic as a readable tree |
| What plugins the project uses, their parameters and commands |
| A designer's opinion on one map: dead space, clutter, event spread, monotony |
| The same map measured — see below |
| Database entries that are out of line with their peers — see below |
| Command sequences copy-pasted across events, worth extracting into a Common Event |
| Find things by meaning across names, dialogue and descriptions |
| The structured digest the other views are built on |
Broken transfers, missing map files, dangling common-event/item/troop references, duplicate IDs, named-but-unused switches and variables, a bad starting position, unreachable maps — and actor names written into dialogue as \N[id] that do not resolve.
That last one is worth its own sentence: the engine resolves \N[id] at draw time, not from any structural parameter, so a bad id passes every other check and the editor shows nothing wrong. The line just renders in-game with a hole where the name should be, and a player finds it before you do.
Reachability — flood fill from the real entry point. Walkable tiles the player can never get to, and events with no reachable tile beside them, are softlocks rather than style notes.
Dead space — the unreachable share of the rectangle, against a band for expected (interior / dungeon / exterior).
Shape — the walkable area thinned to a one-cell skeleton and read as a graph: endpoints, junctions, cycles, critical path, linearity. Linearity near 1 is a corridor with no choice to make.
Variety — Shannon entropy over 5×5 tile windows: the monotonous-floor problem, measured.
Tension — for maps with random encounters, how many steps the player is from a shop, inn or save point.
A skill dealing 400 damage is fine in a game where everything does, and broken in one where nothing else breaks 60. So each entry is scored on a power metric and compared against the others in its category: damage per MP for skills, gold per point of ATK+MAT for weapons, gold per DEF+MDF for armors, HP per EXP for enemies.
The comparison is leave-one-out — an entry is judged against statistics it had no hand in creating. Included in its own numbers, a badly broken entry drags the mean toward itself until it stops looking unusual at all.
Damage formulas are parsed, never executed (tokenise → shunting-yard → evaluate). One that cannot be read statically is listed under unreadableFormulas rather than scored as zero damage, which would pull every average down and hide the very outliers you were looking for.
Narrow with category, loosen or tighten with thresholdSd (default 2).
query_map { view: "ascii", mapId } — render a map as a character grid with event markers. The cheapest way to see a layout and pick coordinates.
query_map { view: "validate", mapId } — lint one map for invalid tile IDs, broken transfers and missing event terminators.
Tool | Purpose |
| List / get by ID / search any database (actors, classes, skills, items, weapons, armors, enemies, states, troops, tilesets, common events, animations) |
| Create entries, with presets: |
| Partial updates (incl. troops & animations); append commands to common events; add enemies to troops |
| Delete entries with reference-breakage warnings |
| Map tree, full map data, events, single event, lint, offline ASCII render |
| Knowledge-driven, semantic, procedural, blank, themed, template, batch or duplicate |
| Fill tile layers, set display names, organize the map tree, connect two maps, set encounters |
| Create (presets: npc, chest, teleport, door, shop, inn, boss, puzzle_switch), update, convert an NPC into a merchant/inn/sign in place, delete, add commands, bulk-populate |
| Title, switch/variable names, starting position, author a plugin, scaffold an editor-openable project, playtest, open/repair in editor, mine templates, and the live bridge |
| Capture and name a live playtest PNG through the authenticated MCP bridge |
| The read-only intelligence layer above |
| Project digest, asset index, per-tileset tile IDs, bundled-template catalog |
| Switch projects at runtime |
| Optional Vision-AI image analysis, plus offline tileset grid measurement and quadrant colors |
The 101 fine-grained v4 tool names still work as call aliases. Set RPGMV_LEGACY_TOOLS=1 to advertise them too.
Atomic. Every write goes to a temp file and is renamed over the target, so an interrupted call can never leave half-written JSON.
Backed up. Rotated timestamped copies under .mcp-backups/ (last N, RPGMV_BACKUP_KEEP, default 10).
Previewable. Pass dryRun: true to any mutating tool to see exactly what it would write, without touching disk.
⚠️ Close the RPG Maker editor while an agent is working. The editor holds the project in memory and will overwrite changes when it saves.
Variable | Required | Description |
| recommended | The project folder (the one with |
| for playtest | Engine install root, for |
| optional | Loopback port for the live bridge (default |
| optional | Backups kept per file (default |
| optional |
|
| to enable vision | Base URL of an OpenAI-compatible vision endpoint. Unset = vision disabled |
| optional | Bearer token; only sent when set |
| optional | Model name (default |
| optional | Endpoint path (default |
analyze_image { mode: "ai" } sends a project image (tileset, sprite, screenshot, battler) to any OpenAI-compatible endpoint. Nothing is sent anywhere unless you configure it; the grid and colors modes and every other tool work fully offline.
# OpenAI
VISION_API_URL=https://api.openai.com VISION_API_KEY=sk-... VISION_MODEL=gpt-4o npm start
# Ollama (local, no key)
VISION_API_URL=http://localhost:11434 VISION_MODEL=llava npm startWorks with OpenAI, Ollama, LocalAI, NVIDIA NIM, vLLM, LiteLLM, or any OpenAI-compatible proxy.
A portable Agent Skill teaches any model the crash-free workflow — build maps with generate_map, add content with manage_map_event presets, never hand-paint tiles or guess IDs. It lives at skill/rpgmaker-mv-mcp/SKILL.md.
# Claude Code / Claude.ai
npx degit DiegoLopez0208/RpgMakerMVUltimate-MCP/skill/rpgmaker-mv-mcp ~/.claude/skills/rpgmaker-mv-mcp
# opencode
npx degit DiegoLopez0208/RpgMakerMVUltimate-MCP/skill/rpgmaker-mv-mcp ~/.opencode/skills/rpgmaker-mv-mcpAlso listed in awesome-claude-skills.
File | Content |
| Tile ID ranges, autotile formula, sheet descriptions, layer meanings |
| Flag bits, common flags, passage check logic |
| ~140 event command codes with parameter schemas |
| Scope, occasion, hitType, damageType, restriction, and the rest |
| Trait codes 11-64, effect codes 11-45 |
| Full schemas for every MV data type |
|
|
| Index of the 106 bundled reference maps |
| Mined multi-tile object stamps (trees, props) per tileset |
| The 106 RTP reference map JSONs used for template cloning |
Decoration semantics are best-effort in the RTP-template path; rare multi-tile objects may land as single tiles. The mined path keeps multi-tile props whole.
Town and dungeon layouts keep improving — planned: a central plaza or well as a landmark, houses in rows facing roads, fences and yards, richer road networks, more room variety.
mode: "semantic" currently generates dungeon-shaped missions. Town and open-world mission grammars are next, as is using the mined adjacency counts to decorate rather than only to describe.
balance compares like with like inside a category, so a boss will legitimately look like an outlier next to random encounters. Read the flag, not the verdict.
The bridge is Windows/nwjs playtest only and needs its plugin installed in the project.
Vision AI requires your own endpoint.
npm install
npm run build # tsc compile (+ copies knowledge/ into dist/)
npm test # vitest
npm run typecheck
npm run dev # tsx watch modeWhere | What |
| Tool handlers and MCP transport |
| The 13-tool surface and its routing |
| Per-domain CRUD |
| Template cloning and procedural generation |
| Mission graphs and the semantic compiler |
| The loopback WebSocket and the in-game plugin |
| The read-only layer behind |
| Static reference data and bundled maps |
Actively developed, and feedback is very welcome — bug reports, weird maps, missing tools, ideas. Open a GitHub Issue with what you asked the agent to do and what you got; an exported map JSON or a screenshot helps a lot.
MIT · Built for RPG Maker MV
Analyze images related to the project. mode "ai" sends a project image file (tileset, character sheet, map screenshot, battler) to an external OpenAI-compatible Vision API and returns {analysis, model, tokens_used} — NETWORK SIDE EFFECT: the resized JPEG leaves your machine to the endpoint configured via VISION_API_URL / VISION_API_KEY / VISION_MODEL env vars; fails if the path escapes the project, the file is missing, or the API is unreachable/times out (120 s). mode "grid" measures a base64 PNG tileset offline and returns its 48px grid {cols, rows, totalTiles}. mode "colors" returns the average RGB of a base64 PNG's four quadrants offline (a crude what-is-on-screen check). For precise offline map layout, query_map view "ascii" is usually better than any image analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | ai = Vision API on a project file; grid/colors = offline analysis of a provided base64 PNG. Default "ai" | |
| prompt | No | mode "ai": custom analysis question (default: thorough RPG-Maker-specific analysis) | |
| base64PNG | No | modes "grid"/"colors": raw base64 PNG data (no data: URL prefix) | |
| imagePath | No | mode "ai": image path RELATIVE to the project root, e.g. "img/tilesets/Outside.png"; paths outside the project are rejected | |
| resizeMax | No | mode "ai": max width in px before upload (default 1024; lower = fewer tokens) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses network side effects (image sent to external API), required env vars, and failure modes. Annotations already state readOnly, safe, idempotent, open-world; description adds critical behavioral context without contradiction.
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 fairly long but well-structured with clear mode breakdowns. Every sentence provides necessary info; minor verbosity in the 'ai' mode explanation but overall earns its space.
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 complex tool with three modes, network side effects, and offline analysis, the description covers all important aspects: return values, failure modes, environment dependencies, and alternatives. No output schema but return format is described per mode.
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 descriptions cover all 5 parameters, but the description adds significant value by explaining mode-specific usage, defaults (resizeMax=1024), and constraints (base64PNG must be raw). This goes beyond the schema's basic 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 tool analyzes images with three distinct modes (ai, grid, colors), each with specific functionality. It distinguishes itself from sibling tool query_map by noting that query_map's 'ascii' view is better for precise map layout.
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 explicit when-to-use guidance for each mode, including failure conditions (path escapes, missing file, API timeout) and a clear alternative (query_map for map layout). This helps the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only project intelligence: builds (and caches) an in-memory model of the WHOLE project so you can reason about it instead of re-reading files. view selects the lens: "overview" (default) returns game title, entity/map/event counts, a health summary (errors/warnings/info) with the top issues, and any maps unreachable from the start map — the fastest way to understand a project you did not build; "index" returns the structured digest (every map with its event count, common events, and only the NAMED switches/variables); "validate" runs every consistency check (broken transfers to non-existent maps, MapInfos entries whose Map file is missing, events that call missing common events / items / weapons / armors / troops / animations, duplicate database IDs, named-but-unused switches/variables, bad starting position, unreachable maps) returning {issueCount, bySeverity, issues[]}, optionally filtered by severity; "graph" returns the map transfer network (nodes, directed edges) plus reachability from the start map; "usage" answers "what uses X?" — pass kind (switch/variable/common_event/item/weapon/armor/troop/animation/actor/state/map) and id to get every event, common event and troop that references it, with read/write roles for switches/variables; "explain" reasons about one thing — target "switch"/"variable" + id tells you whether it is set, read, gated, a dead write, or never-set (the usual reason a door/event never triggers), and target "map" + id reports incoming transfers, what becomes unreachable if it is deleted, and whether it is the start map; "ast" parses one event page (mapId + eventId, optional page) or a common event (commonEventId) into a logical tree with a readable outline; "plugins" fuses js/plugins.js with each plugin file's @plugindesc/@author/@param/@command/@help header so you can adapt to the project's OWN systems instead of emitting vanilla events (and flags configured plugins whose file is missing); "critique" reviews ONE map (mapId) like a game designer — dead space, empty/cluttered balance, event distribution across quadrants, floor monotony, fragmented walkable regions — returning metrics plus justified, actionable suggestions and a rough score; "refactor" finds command sequences copy-pasted across events/common events and suggests extracting them into a Common Event; "search" ranks the project's human-readable text (map/NPC names, dialogue, item/skill descriptions, notes) against a free-text query like "the blacksmith" or "the dark forest". Nothing is written. Pair with the editor tools to act on what you find.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | views "usage"/"explain": numeric id of the switch/variable/map/entity to inspect | |
| kind | No | view "usage": what kind of entity `id` refers to | |
| page | No | view "ast": which page of the event (0-based, default 0) | |
| view | No | Which lens to apply (default "overview") | |
| limit | No | view "search": max results (default 20) | |
| mapId | No | view "ast": the map holding the event to parse | |
| query | No | view "search": free-text query, e.g. "the blacksmith", "dark forest" | |
| minLen | No | view "refactor": minimum shared command-run length to report (default 4) | |
| target | No | view "explain": what `id` refers to (default "switch") | |
| eventId | No | view "ast": the event on `mapId` to parse | |
| severity | No | view "validate": keep only issues of this severity | |
| commonEventId | No | view "ast": parse this common event instead of a map event |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds details: caching of the model, whole-project scope, and specific behaviors for each view (e.g., validate returns issueCount, bySeverity, issues[]). No contradictions.
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 quite long but well-structured with a front-loaded purpose and a bullet-like listing of views. While every sentence adds value, the length could be reduced without losing clarity. Still, it maintains reasonable conciseness for a complex tool.
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 12 parameters, no output schema, and multiple views, the description covers all behaviors, outputs for each lens, parameter dependencies, and caching. It is fully sufficient for an agent to select and invoke the tool correctly.
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 100% with descriptions for all 12 parameters. The description adds significant extra context by associating parameters with specific views (e.g., 'view=usage expects kind and id'), explaining enum values, and detailing output formats. This goes beyond the 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 tool provides read-only project intelligence, building an in-memory model for reasoning. It enumerates specific lenses (overview, index, validate, etc.), differentiating it from sibling tools like edit_map or manage_map_event which modify the project.
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?
Explicitly states 'Read-only project intelligence' and 'Nothing is written.' Advises to pair with editor tools for action. This tells the agent when to use (analysis) and when not to (modification), with clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new entry in an RPG Maker MV database with the next free ID; the data file is written immediately. Returns the complete created object including its new id. Two forms: with entity + data it creates a raw entry (omitted fields get engine defaults; data.name is expected); with preset it builds a ready-to-use entry from a recipe — damage_skill {name, mpCost, scope, formula, element?, animationId?}, healing_skill {name, mpCost, scope, formula}, buff_skill {name, mpCost, scope, paramId 0-7, turns}, state_skill {name, mpCost, scope, stateId, chance 0-1}, boss_enemy {name, battlerName?, specialSkillId?, params?}, encounter_troop {name, enemyIds[]}. Presets validate their required fields and fail with a validation error when missing. Class entries: data.params accepts 8 stat seeds [HP,MP,ATK,DEF,MAT,MDF,AGI,LUK] expanded to full level 1-99 curves automatically. Not supported for tilesets/animations (author those in the editor). Referenced IDs (classId, stateId, enemyIds...) are NOT validated — confirm them with query_database first.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Entry fields. Raw entries: same properties as the RPG Maker database (name, note, traits, params...; effects for items/skills, members [{enemyId,x,y}] for troops, trigger/switchId/list for common_events). Presets: the recipe fields listed in the description | |
| entity | No | Which database receives the new entry. Optional when preset is given (the preset implies it) | |
| preset | No | Recipe for common content; see the tool description for each preset's required data fields. Omit for a raw entry |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: immediate file write, return of complete object, preset validation with error on missing fields, automatic curve expansion for class params, and non-validation of referenced IDs. This adds substantial value beyond the annotations, which only mark read/write safety.
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 comprehensive but well-structured: core function and return in first sentence, then forms, presets, special cases, and limitations. While lengthy, each sentence adds necessary detail, and the front-loading of key info aids quick comprehension.
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 complexity (two modes, presets, special handling) and no output schema, the description fully covers return values, validation behavior, unsupported types, and ID validation warnings, providing complete guidance for 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?
With 100% schema coverage, the description still enriches understanding by clarifying raw vs preset usage, listing exact preset required fields, explaining class param expansion, and detailing expected data structures (e.g., effects for items, members for troops). This goes well beyond the schema's basic property 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 tool creates a new entry with the next free ID in an RPG Maker MV database. It distinguishes itself from sibling tools like query_database and delete_database_entry by detailing two creation forms (raw and preset) and specifying the returned object.
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 explains when to use each form: raw entity+data for custom entries, presets for common types. It explicitly excludes tilesets/animations (use the editor) and advises confirming referenced IDs with query_database, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DESTRUCTIVE: delete a database entry by nulling it out in its data file (written immediately; not undoable — re-create it if needed; IDs are never reused). References elsewhere are NOT cleaned up and will break at runtime: actors in the starting party, classes assigned to actors, skills in class learnings/enemy actions, items in chests/shops, enemies in troops, states in skill effects — check and update those first with query_database/update_database_entry. NEVER delete skill 1 (Attack), skill 2 (Guard) or state 1 (KO); the engine uses them directly. Supported entities: actors, classes, skills, items, weapons, armors, enemies, states. Returns the deleted object for reference; fails with an error if the ID does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the entry to delete (never skill 1/2 or state 1) | |
| entity | Yes | Which database contains the entry to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds concrete behavioral details beyond annotations: nulls out in data file, written immediately, not undoable, IDs never reused, and broken references. Annotations only indicate destructive and idempotent, so the description greatly enhances transparency.
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 dense but well-structured, front-loading the critical 'DESTRUCTIVE' label and immediate behaviors. Every sentence provides necessary information, though slightly longer than ideal; still clear and 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?
Despite lacking output schema, the description covers all needed context: purpose, side effects, forbidden IDs, supported entities, and return value. It is complete for a destructive tool with 2 parameters.
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 100% and the schema already describes both parameters, including the prohibition on specific IDs for skills and states. The description restates the constraint but adds no new semantic detail beyond the schema, resulting in a baseline score of 3.
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 verb (delete), the resource (database entry), and specifics about how it works (nulling in data file, immediate, not undoable). It lists supported entities and distinguishes from sibling tools like create, update, and query.
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 explicitly warns about side effects (broken references) and advises to check/update related data with query_database/update_database_entry first. It also specifies forbidden IDs (skill 1/2, state 1), providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Modify existing maps; the affected map files / MapInfos.json are written immediately. action selects the edit: "fill_layer" overwrites an ENTIRE tile layer with one tile ID (destructive, not undoable; layers: 0-1 ground, 2-3 upper, 4 shadow bits 0-15, 5 region IDs 0-255; tileId 0 clears; find valid IDs with get_project_context detail "tileset"); "set_display_names" sets the player-visible displayName of several maps at once (entries whose map file is missing are reported in skipped, not errors); "organize_tree" re-parents maps in the editor tree (purely organizational, gameplay unaffected); "connect" creates a bidirectional pair of transfer events between two maps so the player can walk both ways; "set_encounters" sets the map's random-battle list so enemies appear while walking — encounters is [{troopId, weight?, regionSet?}] (weight default 5; regionSet [] = whole map; troopId must exist) plus optional encounterStep. WITHOUT encounters set, a map has no random battles. Returns a per-action summary. Fails with an error if a referenced map does not exist (except set_display_names, which skips). For event-level work use manage_map_event.
| Name | Required | Description | Default |
|---|---|---|---|
| posA | No | action "connect": transfer event position on map A {x, y, trigger} (trigger 1=walk-on default, 0=action button for doors) | |
| posB | No | action "connect": transfer event position on map B {x, y, trigger} | |
| layer | No | action "fill_layer": layer index 0-5 | |
| mapId | No | action "fill_layer": map to modify | |
| names | No | action "set_display_names": [{mapId, name}] — name is what the player sees on map entry | |
| action | Yes | Which edit to perform; see the tool description | |
| mapIdA | No | action "connect": first map ID | |
| mapIdB | No | action "connect": second map ID | |
| tileId | No | action "fill_layer": tile ID to write into every cell (0 = clear) | |
| folders | No | action "organize_tree": [{mapId, parentId}] — parentId 0 means root level | |
| encounters | No | action "set_encounters": [{troopId, weight?, regionSet?}] random-battle entries; troopId must exist (create via create_database_entry "troops") | |
| encounterStep | No | action "set_encounters": average steps between random battles (default 30) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that fill_layer is destructive and not undoable, writes immediately, and per-action error behavior. Matches annotations: destructiveHint=true, idempotentHint=true. Adds context like layer ranges, tile clearing, and encounter defaults beyond annotations.
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?
Description is moderately sized and front-loaded with main purpose. Each sentence contributes, but could be slightly tighter (e.g., repeating 'action' reference). Still well-structured and readable.
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?
Covers all 5 actions, parameters, side effects, error handling, and links to related tools. No output schema, but 'Returns per-action summary' suffices. Complex tool (12 params, nested) fully addressed.
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 100% with parameter descriptions, but tool description adds critical context (e.g., layer meanings, tile ID source via get_project_context, encounter format). Enriches understanding beyond schema alone.
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?
Tool name 'edit_map' and title 'Edit map' are clear. Description begins with 'Modify existing maps' and enumerates 5 distinct actions, each with specific purpose. Distinguishes from sibling tools like 'manage_map_event' and implicitly from 'generate_map'.
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?
Explicitly states 'For event-level work use manage_map_event' as alternative. Each action's use case is described (e.g., 'organize_tree' is purely organizational, 'set_encounters' affects random battles). Provides conditions like required map existence and exception for set_display_names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new map file (next free map ID, registered in MapInfos.json; both files written immediately). mode selects the generator: "blank" makes an empty map you paint later (edit_map fill_layer); "themed" generates a simple tile layout for a theme using the tileset's real tiles; "procedural" is the full generator — for themes with matching RTP reference templates (town, dungeon, interior, castle, world, etc.) it CLONES a hand-authored template from the 106 bundled maps (real 3D buildings, walls, furniture), auto-picking the closest size; for themes without templates (beach, swamp, etc.) it generates procedurally (Perlin terrain, BSP dungeons, cellular caves). Same seed + params = same map. Pass templateId to force a specific template, or useTemplate:false to force procedural. 21 themes incl. snow, volcano, sewer, space_interior; "batch" generates several procedural maps in one call from batch specs; "duplicate" copies an existing map (transfer events still point at their ORIGINAL destinations — review them); "template" instantiates one of the 106 bundled reference maps by templateId (list them with get_project_context detail "templates"). Returns {mapId, ...} — procedural also returns the seed; batch returns all mapIds keyed for edit_map "connect". Fails with an error on unknown theme/template or unwritable files.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | Which generator to use; see the tool description. Default "procedural" | |
| name | No | Internal map name for the editor tree (required for mode "duplicate") | |
| note | No | Free-form note field for plugin metadata | |
| seed | No | procedural/batch: random seed for reproducible output (omit for random; returned in the result) | |
| batch | No | mode "batch" only: one spec per map [{key, name, theme, width, height, tilesetId, seed, parentId}]; key is echoed back to match returned mapIds | |
| theme | No | Required for themed/procedural. themed: forest, dungeon, town, castle, cave, village, swamp, desert, ruins, interior, beach. procedural adds: snow, harbor, volcano, sewer, fortress, magic_forest, magic_interior, space_interior, space_exterior, world | |
| width | No | Map width in tiles (defaults: blank/themed 17, procedural 30; template uses the template's size) | |
| height | No | Map height in tiles (defaults: blank/themed 13, procedural 25) | |
| bgmName | No | Audio file from audio/bgm/ to autoplay on entry | |
| parentId | No | Map tree folder to nest the new map under (0 = root) | |
| addEvents | No | procedural: also place themed NPCs/chests/bosses/transfers (default true) | |
| tilesetId | No | Tileset to render with. Defaults to the one matching the theme (Outside=2, Inside=3, Dungeon=4, Overworld=1), so you normally omit it — only set it to override. A mismatched tileset renders the map as garbage | |
| encounters | No | procedural combat themes (dungeon/cave/world/fortress/sewer/volcano): auto-populate the map's random encounters from the project's existing troops so enemies appear while walking. Default true (no-op if the project has no troops yet) | |
| keepEvents | No | mode "template" only: also copy the template's events (default true) | |
| templateId | No | mode "template": bundled template ID. mode "procedural": OPTIONAL — force a specific template ID (from get_project_context detail "templates") instead of auto-picking by theme+size | |
| displayName | No | Location name briefly shown to the player on entry | |
| sourceMapId | No | mode "duplicate" only: existing map ID to copy (unchanged by the operation) | |
| useTemplate | No | procedural: when true (default), clone an RTP template for themes that have one (town, dungeon, interior, etc.) instead of generating procedurally. Set false to force procedural generation even when templates exist | |
| enterableHouses | No | procedural town/village only: also auto-generate an interior map per house with a two-way warp (action-button door outside → interior, walk-on mat inside → back to the street). Default true; the new interior map IDs are returned in interiorMapIds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: immediate file writing, cloning of hand-authored templates, auto-picking closest size, reproducibility with same seed and params, transfer events pointing to original destinations in duplicate mode, and failure conditions (unknown theme/template, unwritable files). Annotations (readOnlyHint=false, destructiveHint=false) are consistent and complemented.
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 dense but well-structured, with the core purpose upfront and mode-specific details logically organized. It is slightly long due to the complexity (6 modes, 19 parameters), but every sentence adds value. A minor condensation could improve 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?
Given the tool's complexity (19 parameters, 6 modes, no output schema), the description provides complete context: all modes, parameter interactions, defaults, return values (mapId, seed, interiorMapIds, batch keys), and failure conditions. No gaps are evident.
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 100% schema description coverage, the tool description adds significant context for parameters: defaults (e.g., mode defaults to procedural, width/height defaults per mode), required conditions (e.g., name required for duplicate, theme required for themed/procedural), and warnings (mismatched tileset renders garbage). This exceeds mere schema repetition.
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 tool creates a new map file with a free ID, registers it, and writes immediately. It distinguishes six modes (blank, themed, procedural, batch, duplicate, template) and their specific behaviors, which differentiates it from siblings like edit_map.
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 explicitly explains when to use each mode, e.g., blank for later painting, themed for simple tile layout, procedural for full generator with templates, batch for multiple maps, duplicate for copying, template for instantiating bundled maps. It also mentions alternatives like edit_map for painting layers and get_project_context for listing templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: pre-digested project knowledge — CALL THIS FIRST in a session. detail selects the depth: "full" (default) returns id+name lists for every database, switch/variable names, starting position, and available sprite filenames per img/ folder — everything needed to create content without inventing broken references; "summary" is a cheap health check (entry counts per data file); "assets" scans img/ and Tilesets.json into a complete index (sheet dimensions, autotile kinds, categorized usable tiles, all PNG names); "tileset" returns the categorized usable tile IDs of ONE tileset (ground/water/walls/roof/decoration) for edit_map "fill_layer" — guessing tile IDs produces glitched maps; "templates" lists the 106 bundled reference maps (id, category, theme) usable with generate_map mode "template", optionally filtered by category/theme. Returns one structured object (or array for templates). GOLDEN RULES for good results: (1) build whole maps with generate_map (it stamps real houses/trees and wires encounters) and add content with the manage_map_event presets — do NOT hand-paint tiles or place decorations one tile at a time; (2) never invent tile IDs or sprite/troop/skill IDs — take them from this tool; (3) for enemies to appear, create troops then set encounters (edit_map "set_encounters"), which generate_map does automatically for combat themes.
| Name | Required | Description | Default |
|---|---|---|---|
| theme | No | detail "templates": filter by template theme | |
| detail | No | How much and what kind of context; see the tool description. Default "full" | |
| category | No | detail "templates": filter by template category | |
| tilesetId | No | detail "tileset": which tileset to categorize |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds valuable behavioral context: warns against inventing tile IDs ('guessing tile IDs produces glitched maps'), explains return types, and details what each mode outputs. No contradictions.
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?
Well-structured with clear ordering: main purpose, detail modes, golden rules. Every sentence adds value, though the description is lengthy due to the tool's complexity. Could be slightly tighter, but still efficient.
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?
Completely covers all aspects: explains every detail mode, parameters, return types, and golden rules for correct usage. Even without an output schema, the description makes it clear what to expect. No gaps for an agent to misuse the tool.
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?
Input schema has 100% coverage, but description adds meaning beyond schema: explains what each enum value of 'detail' returns, and for tilesetId, category, theme, it specifies their role in filtering. Schema defers to description for full semantics.
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?
Explicitly states it is 'read-only: pre-digested project knowledge' and advises 'CALL THIS FIRST'. Clearly distinguishes each detail mode (full, summary, assets, tileset, templates) with specific use cases, differentiating it from sibling tools like query_map and generate_map.
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?
Provides explicit when-to-use instructions: 'CALL THIS FIRST'. Golden rules guide proper usage: use generate_map for maps, never invent IDs, set encounters correctly. Details when to use each detail mode (e.g., 'tileset' for edit_map 'fill_layer').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create, modify or remove events on a map; the map file is written immediately. action "create" without preset makes a low-level event at x/y (empty page unless pages given; add behavior later with add_command). action "create" WITH preset builds a complete, ready-to-play event: "npc" (2-page dialogue NPC: {name, dialogues[], characterName?, characterIndex?}), "chest" (one-time loot: {items: [{type: item|weapon|armor, id, amount}]} — IDs not validated, confirm with query_database), "teleport" (one-way walk-on transfer zone: {destMapId, destX, destY, trigger?} — destination not validated), "door" (action-button warp into another map, e.g. a house entrance: {destMapId, destX, destY, characterName?, characterIndex?, trigger?, lockedSwitchId?, lockedMessage?}; with lockedSwitchId it shows a "locked" message until that game switch is ON), "shop" ({goods: [[type 0=item/1=weapon/2=armor, id, priceType 0=standard/1=custom, price]]}), "inn" ({cost?} full-recovery flow with gold check), "boss" ({troopId} one-time battle, game over on loss), "puzzle_switch" ({switchX, switchY, doorX, doorY, gameSwitchId, switchName?, doorName?} creates TWO linked events). action "update" overwrites only fields on an event; action "convert" RE-PURPOSES an existing event in place — keeping its id, position, name and sprite but replacing its behaviour — via kind: "merchant" (a working shop; pass options.goods [[type,id,priceType,price]] or the friendly options.items [{type,id}], plus optional options.greeting), "inn" (options.cost? full-recovery flow with gold check), "sign" (options.text string or string[] read-only message); ideal for "turn this NPC into a merchant" without re-placing it; "delete" removes it permanently (DESTRUCTIVE); "add_command" appends one command before a page's terminator; "populate" scatters N events of a kind (npc/chest/boss) at random positions (walkability not checked — validate with query_map "ascii"). Returns the created/updated event(s) with ids. Fails with an error if the map (or event, for update/delete) does not exist.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | Tile X position (0-based; create/presets except puzzle_switch) | |
| y | No | Tile Y position (0-based) | |
| cost | No | preset "inn": gold charged for a full recovery (default 50) | |
| kind | No | action "convert": what to turn the existing event into | |
| name | No | Event name shown in the editor | |
| opts | No | action "populate": overrides {name, troopId, x, y} | |
| count | No | action "populate": how many events (default 3) | |
| destX | No | preset "teleport"/"door": destination tile X (should be walkable) | |
| destY | No | preset "teleport"/"door": destination tile Y | |
| doorX | No | preset "puzzle_switch": door tile X | |
| doorY | No | preset "puzzle_switch": door tile Y | |
| goods | No | preset "shop": wares [[type, id, priceType, price]] — priceType 1 uses the custom price, 0 the database price | |
| items | No | preset "chest": loot [{type: "item"|"weapon"|"armor", id, amount}] | |
| mapId | Yes | Map the event lives on (always required) | |
| pages | No | action "create" without preset: full event page objects (optional) | |
| action | Yes | What to do; see the tool description. Default "create" | |
| fields | No | action "update": properties to overwrite, e.g. {"x": 5, "y": 9} or {"pages": [...]} (replaces all pages) | |
| preset | No | action "create" only: ready-made event recipe; omit for a low-level empty event | |
| command | No | action "add_command": event command {code, indent, parameters}; e.g. 201=Transfer Player [0, mapId, x, y, dir, fade] | |
| eventId | No | Existing event ID (update/delete/add_command); find it with query_map view "events" | |
| options | No | action "convert": kind-specific settings — merchant {goods|items, greeting?}, inn {cost?}, sign {text} | |
| switchX | No | preset "puzzle_switch": floor-switch tile X | |
| switchY | No | preset "puzzle_switch": floor-switch tile Y | |
| trigger | No | How the event activates: 0=action button, 1=player touch, 2=event touch, 3=autorun, 4=parallel | |
| troopId | No | preset "boss" / populate boss: troop to battle (create it first via create_database_entry preset encounter_troop) | |
| doorName | No | preset "puzzle_switch": editor name for the door event (default "Door") | |
| destMapId | No | preset "teleport"/"door": destination map ID | |
| dialogues | No | preset "npc": dialogue lines, each becomes one text box | |
| eventType | No | action "populate": kind of events to scatter — "npc", "chest" or "boss" | |
| pageIndex | No | action "add_command": which page receives the command (0-based, default 0) | |
| switchName | No | preset "puzzle_switch": editor name for the switch event (default "Switch") | |
| gameSwitchId | No | preset "puzzle_switch": game switch linking switch and door — pick an unused ID via manage_system get switches | |
| characterName | No | Sprite sheet from img/characters/ without extension; list options with get_project_context | |
| lockedMessage | No | preset "door": message shown while locked (default "It's locked.") | |
| characterIndex | No | Which of the 8 characters in the sheet (0-7) | |
| lockedSwitchId | No | preset "door": if set, the door shows lockedMessage until this game switch is ON, then warps |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behaviors beyond annotations: immediate write ('written immediately'), destructive nature of delete ('DESTRUCTIVE'), no validation for IDs or walkability, and side effects of convert (replaces behavior in place). Annotations already indicate destructiveHint=true, but description adds rich context.
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 long but well-structured: grouped by action and preset with clear hierarchy. Every sentence adds value, though some redundancy could be trimmed (e.g., repeating 'action'). Given the complexity (36 params, 6 actions, 8 presets), it is appropriately 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 description covers return values ('Returns the created/updated event(s) with ids') and failure conditions ('Fails with an error if the map... does not exist'). No output schema exists, so return description is minimal but adequate. Could add more on error messages or pagination, but overall complete for the tool's complexity.
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 100% schema coverage, baseline is 3, but the description adds extensive semantics: explaining role of each preset, required fields for nested objects (e.g., items for chest, goods for shop), and behavioral nuances (locked door, puzzle_switch creating two events). It significantly enhances understanding beyond 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 tool's purpose: 'Create, modify or remove events on a map'. It distinguishes multiple actions (create, update, convert, delete, add_command, populate) and presets, providing specific details for each, differentiating it from 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance for each action and preset, including when to use alternatives (e.g., 'add behavior later with add_command'), validation notes (IDs not validated, destination not validated), and prerequisites (map must exist). It also references sibling tools like query_database and get_project_context for further steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read or edit project-wide settings in data/System.json (writes are immediate). action "get" returns the requested section: "full" (everything — large), "switches" or "variables" (name arrays indexed by ID; unnamed entries are empty strings — use these to find free IDs), or "title". action "set_title" changes the game title shown on the title screen. "name_switch"/"name_variable" label a switch/variable by ID — documentation only, runtime values are untouched, but good names keep event logic readable. "set_starting_position" sets where new games begin {mapId, x, y} — NOT validated against existing maps, verify with query_map "infos" first; does not affect saved games. Returns the read section or the updated values.
| Name | Required | Description | Default |
|---|---|---|---|
| x | No | set_starting_position: starting tile X (should be walkable) | |
| y | No | set_starting_position: starting tile Y | |
| id | No | name_switch/name_variable: switch or variable ID to label (1-based) | |
| name | No | name_switch/name_variable: descriptive label, e.g. "BridgeRepaired" | |
| mapId | No | set_starting_position: map where new games start (must exist) | |
| title | No | action "set_title": new game title | |
| action | Yes | What to do; see the tool description. Default "get" | |
| section | No | action "get": which part of System.json to return (default "full") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which indicate not read-only, not destructive, idempotent), the description discloses that writes are immediate, set_starting_position is not validated, and name_switch/name_variable is documentation-only. No contradictions.
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 well-structured with a clear first sentence and subsequent details per action, but slightly verbose. However, every sentence adds value.
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 description covers all actions and parameters comprehensively, including warnings about unvalidated map IDs and no effect on saved games. Lacks error handling details, but acceptable given no output schema.
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 100% schema coverage, the description still adds significant meaning: explains the 'full' section is large, unnamed entries are empty strings (useful for finding free IDs), and set_starting_position requires map validation via another tool.
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 tool reads or edits project-wide settings in data/System.json, lists all actions, and distinguishes itself from sibling tools that handle other database entries, maps, or events.
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 explains when to use each action (e.g., 'get' for reading sections, 'set_starting_position' for starting position), but does not explicitly state when not to use this tool or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: query any RPG Maker MV database (data/*.json). Three forms depending on arguments: no id/query lists every non-null entry of the entity; id fetches one entry (returns null, not an error, if it does not exist); query does a case-insensitive name search (items/weapons/armors/skills also match descriptions). Returns an array (list/search) or a single object/null (id). Use this to discover valid IDs before create/update/delete or before wiring references (class learnings, troop members, chest loot). For maps use query_map; for a digest of everything at once use get_project_context.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | Fetch a single entry by its database ID (1-based). Omit to list or search | |
| query | No | Case-insensitive substring to match against entry names (and descriptions for items/weapons/armors/skills). Ignored when id is given | |
| entity | Yes | Which database to read: actors, classes, skills, items (consumables), weapons, armors, enemies, states (status conditions), troops (enemy formations), tilesets, common_events, animations |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. Description adds key behaviors: returns null for missing id (not error), case-insensitive search, description matching for certain entities. No contradictions.
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?
Concise and well-structured: starts with read-only safety emphasis, then enumerates three usage forms, provides usage guidance, and ends with sibling differentiation. Every sentence adds value without redundancy.
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?
Despite no output schema, description explains return types (array vs single object/null) and covers all three modes. Provides complete context for usage, parameter interactions, and relationship to sibling tools. Fully sufficient for an AI agent.
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?
100% schema coverage with descriptions, but description adds crucial semantics: explains that omitting id and query lists all entries, id returns null on missing, query is case-insensitive and also matches descriptions for items/weapons/armors/skills. Significantly enriches understanding.
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 tool queries RPG Maker MV database files, specifies three forms (list, fetch by id, search), and distinguishes from siblings (query_map, get_project_context). Verb 'query' and resource 'database' are explicit.
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?
Explicitly advises using before create/update/delete operations to discover IDs, and directs to query_map for maps and get_project_context for a full digest. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only: inspect maps. view selects what you get: "infos" lists the map tree from MapInfos.json (ids, names, folder parentIds — no mapId needed); "full" returns one complete MapNNN.json (dimensions, 6-layer tile data, events — can be large); "events" lists a map's events (with query, filters by name, case-insensitive); "event" returns one event by eventId (null if absent); "validate" lints a map (invalid tile IDs per layer, missing page terminators, transfers to map 0, Self Switch OFF where ON was likely meant) returning {issueCount, issues[]}; "ascii" renders the map as a character grid with event markers and a legend — the cheapest way to "see" a layout and pick coordinates, entirely offline. Fails with an error if the map file does not exist. For player-visible images use analyze_image instead.
| Name | Required | Description | Default |
|---|---|---|---|
| view | Yes | What to read; see the tool description for each view | |
| layer | No | view "ascii" only: tile layer to draw, 0=ground (default) or 2=upper decorations | |
| mapId | No | Map ID (required for every view except "infos"); map 1 is Map001.json | |
| query | No | view "events" only: case-insensitive substring filter on event names | |
| eventId | No | Event ID within the map (required for view "event") | |
| showEvents | No | view "ascii" only: overlay event markers (default true) | |
| showRegions | No | view "ascii" only: also return the region-ID layer as a second grid (default false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint; description adds specifics like failure on missing file, offline nature of ascii view, and validation behavior, adding value beyond annotations.
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?
Efficient and front-loaded with 'Read-only: inspect maps.' Each sentence serves a purpose, but the description is somewhat dense; could be slightly shorter.
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 7 parameters, 1 required, and no output schema, the description thoroughly explains each view's return format, failure cases, and even provides a cheap way to 'see' layout via ASCII. Complete for the tool's complexity.
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?
While schema has 100% coverage, the description adds meaning by explaining what each view returns (e.g., 'full' returns dimensions and tile data, 'validate' returns issueCount and issues). This compensates for the lack of output 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 clearly states it is a read-only tool to inspect maps, with specific verbs like 'inspect' and lists each view. It distinguishes itself from siblings like edit_map and generate_map by emphasizing read-only nature.
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?
Provides explicit when-to-use for each view and mentions an alternative tool (analyze_image) for player-visible images. Could be more explicit about when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Switch this server to a DIFFERENT RPG Maker MV project directory for all subsequent tool calls (session-wide side effect; persists until changed again or the server restarts). Validates that the path contains data/System.json and fails with an error otherwise, leaving the previous project active. Returns the new active path. Without this tool, the RPGMAKER_PROJECT_PATH environment variable set at startup applies.
| Name | Required | Description | Default |
|---|---|---|---|
| path | Yes | Absolute path to an RPG Maker MV project root (the folder containing data/System.json and img/) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds behavioral details: session-wide side effect, path validation (checks for data/System.json), error behavior (fails leaving previous active), and return value (new active path). No contradictions.
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?
Three sentences front-load the purpose, then side effect, then return/alternative. No wasted words; every sentence adds value.
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 (one parameter, no output schema), the description covers purpose, side effects, validation, return value, and the alternative (environment variable). No missing critical details.
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 covers 100% of parameters with a clear description. The description adds validation context (must contain data/System.json) and emphasizes absolute path, which enhances understanding 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 clearly states the tool's purpose: switching to a different RPG Maker MV project directory. It specifies the action (switch), the resource (project directory), and distinguishes from the startup environment variable, making it unique among siblings.
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 explains when to use the tool (to change the project directory) and notes the alternative (environment variable at startup). It implies persistence until changed or restart, but doesn't explicitly mention when not to use it or compare with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Partially update an existing database entry: only the keys in fields are overwritten (arrays like traits/learnings/actions are replaced wholesale, not merged); the data file is written immediately and there is no undo, so fetch current values with query_database first if you may revert. Returns the full entry after the update. Fails with an error if the ID does not exist. Special append forms that do not need fields: common_events + appendCommand inserts one event command before the list terminator; troops + addEnemyId adds a member at an auto-computed battle position. Plain troop updates and animations are not supported. Class params in fields accept 8 seeds (expanded to full curves) or 8 arrays of 100 per-level values. Editing tilesets affects every map using them; malformed flags break passability project-wide.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | ID of the entry to modify (must exist; find it with query_database) | |
| entity | Yes | Which database contains the entry | |
| fields | No | Subset of properties to overwrite, e.g. {"name": "Hero", "price": 250}. Not needed when using appendCommand/addEnemyId | |
| addEnemyId | No | troops only: enemy ID to append as a new member at an auto-computed screen position | |
| appendCommand | No | common_events only: one event command {code, indent, parameters} appended before the terminator. Common codes: 101+401=Show Text, 121=Control Switches, 122=Control Variables |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses multiple behavioral traits beyond annotations: partial update with array replacement, immediate write with no undo, error on missing ID, special append operations, class parameter handling, and side effects of editing tilesets. No contradiction with annotations.
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 lengthy but every sentence adds necessary detail. It front-loads the main purpose and then logically covers nuances. Minor room for trimming, but well-structured overall.
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?
Covers return value (full entry after update), error conditions (ID not existing, unsupported updates), and provides sufficient detail for the 5-parameter, nested-object input. No output schema 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 has 100% parameter description coverage, but the description adds meaning: clarifies fields behavior (overwrites only given keys, arrays replaced), explains append operations and their parameters, and adds context for class params (seeds or full curves).
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 it partially updates an existing database entry, specifying that only keys in 'fields' are overwritten and arrays are replaced wholesale. It distinguishes from sibling tools like create_database_entry and delete_database_entry by focusing on update behavior.
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?
Provides explicit guidance: fetch current values with query_database before updating if a revert might be needed. Notes unsupported cases like plain troop updates and animations. However, does not directly compare to alternatives like create_database_entry or delete_database_entry.
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.
v5.12.2analyze_projectmanage_map_event3 fields changedInput schema / properties / action / enumPrevious value: -[
- "create",
- "update",
- "delete",
- "add_command",
- "populate"
-]New value: +[
+ "create",
+ "update",
+ "convert",
+ "delete",
+ "add_command",
+ "populate"
+]Input schema / properties / kindAdded value: +{
+ "description": "action \"convert\": what to turn the existing event into",
+ "enum": [
+ "merchant",
+ "inn",
+ "sign"
+ ],
+ "type": "string"
+}Input schema / properties / optionsAdded value: +{
+ "description": "action \"convert\": kind-specific settings — merchant {goods|items, greeting?}, inn {cost?}, sign {text}",
+ "type": "object"
+}v5.8.1generate_map2 fields changedInput schema / properties / templateId / descriptionPrevious value: -"mode \"template\" only: bundled template ID from get_project_context detail \"templates\""New value: +"mode \"template\": bundled template ID. mode \"procedural\": OPTIONAL — force a specific template ID (from get_project_context detail \"templates\") instead of auto-picking by theme+size"Input schema / properties / useTemplateAdded value: +{
+ "description": "procedural: when true (default), clone an RTP template for themes that have one (town, dungeon, interior, etc.) instead of generating procedurally. Set false to force procedural generation even when templates exist",
+ "type": "boolean"
+}v5.8.0add_common_event_commandadd_enemy_to_troopadd_event_commandanalyze_imageanalyze_screenshotanalyze_tileset_imageconnect_mapscreate_armorcreate_boss_enemycreate_boss_eventcreate_buff_skillcreate_chestcreate_classcreate_common_eventcreate_damage_skillcreate_database_entrycreate_enemycreate_healing_skillcreate_inncreate_itemcreate_mapcreate_map_eventcreate_npccreate_puzzle_switchcreate_random_encounter_troopcreate_shopcreate_skillcreate_statecreate_state_skillcreate_teleport_eventcreate_troopcreate_weapondelete_actordelete_classdelete_database_entrydelete_enemydelete_itemdelete_map_eventdelete_skilldelete_stateduplicate_mapedit_mapfill_map_layergenerate_mapgenerate_map_batchgenerate_map_v3get_all_skillsget_animationget_animationsget_armorsget_classget_classesget_common_eventsget_enemiesget_enemyget_game_titleget_itemsget_mapget_map_eventget_map_eventsget_map_infosget_project_context4 fields changedInput schema / properties / categoryAdded value: +{
+ "description": "detail \"templates\": filter by template category",
+ "type": "string"
+}Input schema / properties / detailAdded value: +{
+ "description": "How much and what kind of context; see the tool description. Default \"full\"",
+ "enum": [
+ "full",
+ "summary",
+ "assets",
+ "tileset",
+ "templates"
+ ],
+ "type": "string"
+}Input schema / properties / themeAdded value: +{
+ "description": "detail \"templates\": filter by template theme",
+ "type": "string"
+}Input schema / properties / tilesetIdAdded value: +{
+ "description": "detail \"tileset\": which tileset to categorize",
+ "type": [
+ "number",
+ "string"
+ ]
+}get_project_summaryget_skillget_skillsget_stateget_statesget_switchesget_systemget_tile_ids_for_tilesetget_tilesetget_tilesetsget_troopget_troopsget_variablesget_weaponsmanage_map_eventmanage_systemorganize_map_treepopulate_map_eventsquery_databasequery_mapread_screenshotrender_map_asciiscan_project_assetssearch_actorssearch_classessearch_enemiessearch_itemssearch_map_eventssearch_skillssearch_statesset_map_display_namesset_project_path1 field changedInput schema / properties / path / descriptionPrevious value: -"Absolute path to the new RPG Maker MV project directory"New value: +"Absolute path to an RPG Maker MV project root (the folder containing data/System.json and img/)"set_switch_nameset_variable_nameupdate_actorupdate_classupdate_common_eventupdate_database_entryupdate_enemyupdate_game_titleupdate_itemupdate_map_eventupdate_skillupdate_starting_positionupdate_stateupdate_tilesetvalidate_mapv1.0.0add_common_event_commandadd_enemy_to_troopadd_event_commandanalyze_screenshotanalyze_tileset_imageconnect_mapscreate_armorcreate_boss_enemycreate_boss_eventcreate_buff_skillcreate_chestcreate_classcreate_common_eventcreate_damage_skillcreate_enemycreate_healing_skillcreate_inncreate_itemcreate_mapcreate_map_eventcreate_npccreate_puzzle_switchcreate_random_encounter_troopcreate_shopcreate_skillcreate_statecreate_state_skillcreate_teleport_eventcreate_troopcreate_weapondelete_actordelete_classdelete_enemydelete_itemdelete_map_eventdelete_skilldelete_stateduplicate_mapfill_map_layergenerate_map_batchgenerate_map_v3get_all_skillsget_animationget_animationsget_armorsget_classget_classesget_common_eventsget_enemiesget_enemyget_game_titleget_itemsget_mapget_map_eventget_map_eventsget_map_infosget_project_contextget_project_summaryget_skillget_skillsget_stateget_statesget_switchesget_systemget_tile_ids_for_tilesetget_tilesetget_tilesetsget_troopget_troopsget_variablesget_weaponsorganize_map_treepopulate_map_eventsread_screenshotrender_map_asciiscan_project_assetssearch_actorssearch_classessearch_enemiessearch_itemssearch_map_eventssearch_skillssearch_statesset_map_display_namesset_project_pathset_switch_nameset_variable_nameupdate_actorupdate_classupdate_common_eventupdate_enemyupdate_game_titleupdate_itemupdate_map_eventupdate_skillupdate_starting_positionupdate_stateupdate_tilesetvalidate_mapTools are largely distinct with clear purposes, but query_database and get_project_context both provide database information, potentially causing minor confusion. Otherwise, each tool targets a specific operation.
All tools follow a consistent verb_noun pattern in snake_case, such as create_database_entry, generate_map, and query_map, making naming predictable and clear.
With 12 tools, the server covers essential RPG Maker MV operations (CRUD for databases, maps, events, system settings) without being overly numerous or sparse.
The toolset provides comprehensive coverage for editing and querying databases, maps, and events. Minor gaps include lack of a direct map deletion tool and limited support for common events, but overall functionality is robust.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to control Unreal E…
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/DiegoLopez0208/RpgMakerMVUltimate-MCP'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
