Skip to main content
Glama

update_database_entry

DestructiveIdempotent

Partially update an RPG Maker database entry: overwrite specified fields, or append event commands, enemies, or battle pages. Fails if the ID doesn't exist.

Instructions

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; troops + addPage inserts one battle-event page from a compact trigger. Troops and animations also support plain fields updates now (e.g. rename a troop, replace its members/pages, or relabel an animation). 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYesID of the entry to modify (must exist; find it with query_database)
entityYesWhich database contains the entry
fieldsNoSubset of properties to overwrite, e.g. {"name": "Hero", "price": 250}. Not needed when using appendCommand/addEnemyId/addPage
addPageNotroops only: append a battle-event page without resending the others. when (at least one, ANDed): turn [a, b] = turn a + b*X (b 0: only turn a); enemyHpBelow [troopSlot from 0, pct]; actorHpBelow [actorId, pct]; switchId; turnEnd true. span battle|turn|moment (default battle). commands: event commands, e.g. from build_event_commands. position: page index to insert at.
addEnemyIdNotroops only: enemy ID to append as a new member at an auto-computed screen position
appendCommandNocommon_events only: one event command {code, indent, parameters} appended before the terminator. Common codes: 101+401=Show Text, 121=Control Switches, 122=Control Variables

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv5.19.0
    • addedInput schema / properties / addPage
      Added value: +{
      +  "additionalProperties": false,
      +  "description": "troops only: append a battle-event page without resending the others. when (at least one, ANDed): turn [a, b] = turn a + b*X (b 0: only turn a); enemyHpBelow [troopSlot from 0, pct]; actorHpBelow [actorId, pct]; switchId; turnEnd true. span battle|turn|moment (default battle). commands: event commands, e.g. from build_event_commands. position: page index to insert at.",
      +  "properties": {
      +    "commands": {
      +      "items": {
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "position": {
      +      "type": "integer"
      +    },
      +    "span": {
      +      "enum": [
      +        "battle",
      +        "turn",
      +        "moment"
      +      ],
      +      "type": "string"
      +    },
      +    "when": {
      +      "additionalProperties": false,
      +      "properties": {
      +        "actorHpBelow": {
      +          "items": {
      +            "type": "integer"
      +          },
      +          "maxItems": 2,
      +          "minItems": 2,
      +          "type": "array"
      +        },
      +        "enemyHpBelow": {
      +          "items": {
      +            "type": "integer"
      +          },
      +          "maxItems": 2,
      +          "minItems": 2,
      +          "type": "array"
      +        },
      +        "switchId": {
      +          "type": "integer"
      +        },
      +        "turn": {
      +          "items": {
      +            "type": "integer"
      +          },
      +          "maxItems": 2,
      +          "minItems": 2,
      +          "type": "array"
      +        },
      +        "turnEnd": {
      +          "type": "boolean"
      +        }
      +      },
      +      "type": "object"
      +    }
      +  },
      +  "required": [
      +    "when"
      +  ],
      +  "type": "object"
      +}
    • changedInput schema / properties / entity / enum
      Previous value: -[
      -  "actors",
      -  "classes",
      -  "skills",
      -  "items",
      -  "weapons",
      -  "armors",
      -  "enemies",
      -  "states",
      -  "tilesets",
      -  "common_events",
      -  "troops"
      -]New value: +[
      +  "actors",
      +  "classes",
      +  "skills",
      +  "items",
      +  "weapons",
      +  "armors",
      +  "enemies",
      +  "states",
      +  "tilesets",
      +  "common_events",
      +  "troops",
      +  "animations"
      +]
    • changedInput schema / properties / fields / description
      Previous value: -"Subset of properties to overwrite, e.g. {\"name\": \"Hero\", \"price\": 250}. Not needed when using appendCommand/addEnemyId"New value: +"Subset of properties to overwrite, e.g. {\"name\": \"Hero\", \"price\": 250}. Not needed when using appendCommand/addEnemyId/addPage"
  2. Addedv5.8.0

TDQS

A4.4/5.0
Behavior4/5

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

Adds substantial context beyond the annotations: immediate write, no undo, replace-not-merge for arrays, error on nonexistent ID, full-entry return, and cross-cutting side effects (tilesets affect every map; malformed flags break passability project-wide). However, it conflicts mildly with idempotentHint=true, since appendCommand/addEnemyId/addPage are explicitly additive and would duplicate on repeat calls.

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 partial-update and no-undo semantics, and every sentence carries weight for a 6-param, nested-object tool. It is dense to the point of being a wall of text, mixing core behavior with edge cases in one paragraph, which slightly hurts scannability.

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?

Despite no output schema, it states the return ('the full entry after the update') and the failure mode (error if the ID does not exist), and covers all three special append modes plus entity-specific caveats. Nothing an agent needs to call 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 already 100%, so the 3 baseline applies, but the description genuinely adds meaning: that `fields` is unnecessary with the append parameters, that appendCommand picks up build_event_commands output, and that class params accept 8 seeds or 8 arrays of 100 per-level values. This goes beyond restating the schema.

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 precise verb+resource+scope: 'Partially update an existing database entry', with the partial/overwrite semantics spelled out (only keys in `fields` are overwritten; arrays replaced wholesale). An agent can immediately distinguish this from create_database_entry, delete_database_entry, and query_database 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 Guidelines4/5

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

Gives concrete when-to-use guidance ('fetch current values with query_database first if you may revert') and routes the special append workflows by entity ('common_events + appendCommand', 'troops + addEnemyId/addPage'). It never states a when-not-to-use condition (e.g. use create_database_entry for new entries), so it stops short of the top band.

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