Skip to main content
Glama

Add a database row

create_database_entry
Destructive

Claim a blank slot in an RPG Maker MZ database table, mirroring the editor's add button. Creates a new row when none is free and merges the given fields.

Instructions

Claim a row in a database table the way the editor does. MZ keeps these as 1-based arrays in which the row's id is its array index, and it never removes one: a fresh project ships unused slots as complete rows with an empty name, and those names are what keeps an id from being reused under a saved game. So this takes the first blank slot, and only grows the table when none is left — pass no id and it behaves like the editor's add button. The field shape comes from the blank slot itself, else from a blank sibling, else from copyFrom (or the last row, which the reply reports as basedOn because you have just copied a real entry's stats, icon and all). fields is then merged over that, shallowly, exactly as patch_database_entry does. System.json has no rows and MapInfos is the map tree, so those two refuse; use patch_database_entry and create_map. There is no delete: blanking a name is what removal means here, and it is a patch.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoRow to claim (default: the first blank slot, else a new one at the end)
tableYesActors, Classes, Skills, Items, Weapons, Armors, Enemies, Troops, States, Animations, Tilesets or CommonEvents
fieldsNoFields to set on the new row, e.g. {name, iconIndex, description}
copyFromNoCopy this existing row's fields as the starting point

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A4.8/5.0
Behavior5/5

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

With destructiveHint=true and idempotentHint=false already declared, the description goes well beyond them: it explains the 1-based array model, that rows are never removed, that blank-slot names prevent id reuse, that it only grows the table when no blank slot exists, and that `fields` merges shallowly. This is rich behavioral context an agent cannot get from 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.

Conciseness4/5

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

Front-loaded with the core concept and no filler sentences, but the middle is a long run-on covering fallback logic and merge semantics that could be tightened. Informative and structured, yet slightly dense for a single-tool description.

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

Completeness5/5

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

For a complex, mutation-heavy tool with no output schema, it covers the schema model, the default/growth path, the copy/merge behavior, what the reply reports (basedOn), and the refusal cases with alternatives. Nothing an agent needs to invoke it correctly is missing.

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 baseline is 3, but the description adds meaning: it clarifies the default-id path (first blank slot, else append), the `copyFrom`-vs-last-row fallback, and that the merge is shallow 'exactly as patch_database_entry does'. It adds value beyond the schema, though most parameter facts are already documented there.

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?

States a specific verb+resource ('Claim a row in a database table') and immediately frames it against the editor's add button. It explicitly distinguishes itself from siblings patch_database_entry and create_map, including the exact tables each handles. An agent can tell it apart without opening a schema.

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

Usage Guidelines5/5

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

Gives explicit when/when-not: omit `id` to mimic the editor's add button, System.json and MapInfos tables refuse and must use patch_database_entry / create_map, and removal is a patch, not a delete. Alternatives are named with the conditions that select them.

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