Skip to main content
Glama
DiegoLopez0208

RPG Maker MV Copilot MCP

by DiegoLopez0208
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create_database_entry

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.

Instructions

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.

Input Schema

NameRequiredDescriptionDefault
dataNoEntry 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. Give `data` or `entries`
entityNoWhich database receives the new entry. Optional when preset is given (the preset implies it)
presetNoRecipe for common content; see the tool description for each preset's required data fields. Omit for a raw entry
entriesNoInstead of `data`: up to 200 data objects, created one after another with the same entity/preset; returns {count, created[]}. A failing entry stops the run and the error names the entries already created

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv5.19.1
    • changedInput schema / properties / data / description
      Previous value: -"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"New value: +"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. Give `data` or `entries`"
    • addedInput schema / properties / entries
      Added value: +{
+  "description": "Instead of `data`: up to 200 data objects, created one after another with the same entity/preset; returns {count, created[]}. A failing entry stops the run and the error names the entries already created",
+  "items": {
+    "type": "object"
+  },
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "data"
-]New value: +[]
  2. Addedv5.8.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already cover write/read and idempotency, but the description adds crucial context: immediate file write, automatic ID assignment, preset validation behavior, class params curve expansion, unsupported entities, and lack of ID validation. It omits permission requirements or rollback behavior on batch failures, but provides rich operational detail beyond the annotations.

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

Conciseness3/5

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

The description is dense and front-loads the core purpose, but the middle section listing all preset fields and edge cases is a long run-on that could be structured better. It remains informative but is not optimally concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (4 params, nested data objects, no output schema), the description covers creation modes, ID behavior, validation, and caveats well. It omits what happens if the file write fails or how to handle large batch failures beyond a simple error note, but is largely complete for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema documents the four parameters well. The description adds significant value by enumerating preset recipe fields, explaining data.name expectations, the 8-stat seed expansion for classes, and the entries batch behavior. It goes beyond the schema's high-level descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states the exact verb and resource ('Create a new entry in an RPG Maker MV database'), specifies the ID assignment behavior ('next free ID'), and explains both creation modes (raw vs preset) in detail. It clearly distinguishes itself from update_database_entry and query_database by defining the creation scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implicitly guides when to use raw vs preset forms and even names query_database as a prerequisite for ID validation ('confirm them with query_database first'). However, it does not explicitly compare against update_database_entry or state when not to use this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools