Skip to main content
Glama
Sign In
RPG Maker MZ Authoring MCP

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

database update record

database_update_record

Patch selected fields of an RPG Maker MZ database record while leaving other fields untouched. Preview the change set with validation first, then apply to commit.

Instructions

Patch selected fields of a record (patch semantics; other fields untouched). Keys are field paths ("mpCost", "damage.formula" or {"damage": {"formula": ...}}); enums accept labels ("scope": "All Enemies"). For system use id 0 or omit id; system also accepts "switches.", "variables.", "terms.messages.", etc.

Preview-first: returns a change set (normalized + native diff, validation incl. reverse references). Pass apply=true to commit immediately when the preview is clean.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "category": "<category>",
      "patch": "<patch>"
    },
    "name": "database_update_record"
  }
}

Input Schema

NameRequiredDescriptionDefault
idNo
applyNoCommit right after a successful preview (non-destructive operations only; needs --allow-write; warnings also need acknowledgeWarnings). Default false = preview only.
patchYes
categoryYesDatabase category
allowScriptNotrue ONLY if the user explicitly asked to insert JavaScript (script commands, script conditions/operands, route scripts).
descriptionNoOptional description stored in the transaction log
acknowledgeWarningsNoAccept validation warnings when apply=true. Review them with the user first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the safety profile is covered; the description adds real value beyond them by disclosing the preview-first workflow and the contents of the preview (normalized and native diff plus validation including reverse references), which matters because there is no output schema. Write-gating details (--allow-write, acknowledgeWarnings) live in the schema rather than the description, so a small amount of the behavioral burden is left elsewhere.

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?

Two tight paragraphs: the patch-key rules first, then the preview/apply contract, which is the right front-loading order. Heavy parenthetical nesting makes it dense to parse but almost nothing is filler.

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?

For a 7-parameter, nested-payload mutation tool with no output schema, the definition covers the hard parts: key syntax, system-record id quirks, and what the preview returns. It leaves description, allowScript and acknowledgeWarnings to the schema text, which is reasonable since those fields are documented there.

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

Parameters5/5

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

The schema declares patch as a bare object with additionalProperties and no description, and 71% coverage leaves the most complex parameter undocumented structurally. The description compensates fully, showing accepted key-path forms ("mpCost", "damage.formula", or nested {"damage": {"formula": ...}}), that enum fields take labels, and the id special cases (0 or omit for system, plus "switches.<id>", "variables.<id>", "terms.messages.<key>").

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

Purpose4/5

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

The description opens with a specific verb and resource, "Patch selected fields of a record", and immediately qualifies scope with "patch semantics; other fields untouched". That phrase alone separates it from database_create_record / database_delete_record / database_duplicate_record without naming them, though no sibling is explicitly named.

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?

It gives an explicit operating procedure: preview first, inspect the change set, then pass apply=true to commit when the preview is clean. This is clear when-to-use guidance for the tool's own two modes. It does not state when to prefer a different sibling (e.g. a bulk apply tool), but no exclusions are implied either.

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