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

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

database duplicate record

database_duplicate_record

Duplicate a database record as a deep copy with a new ID, keeping references to existing classes, skills, and equipment. Preview the change set first, then apply to commit.

Instructions

Duplicate a record (deep copy, new ID = max+1). Referenced records (class, skills, states, equipment...) are NOT duplicated; the copy references the same IDs.

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>",
      "id": "<id>"
    },
    "name": "database_duplicate_record"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
nameNo
applyNoCommit right after a successful preview (non-destructive operations only; needs --allow-write; warnings also need acknowledgeWarnings). Default false = preview only.
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.1/5.0
Behavior4/5

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

Annotations declare non-read-only, non-destructive, non-idempotent; the description is consistent and adds real behavior beyond them: the copy is a deep copy with a max+1 ID, referenced records (class, skills, states, equipment) are NOT duplicated and keep the same IDs, and the first call returns a change set with normalized + native diff and validation including reverse references. It does not mention the write-permission requirement or whether the committed duplicate can be reverted, which keeps it from a 5.

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 short paragraphs, front-loaded with the core action and its copy semantics, then the preview/apply workflow. The parenthetical examples ('class, skills, states, equipment...') earn their place by illustrating the reference-sharing rule. Minor redundancy with the schema's own apply description.

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?

With no output schema, the description correctly compensates by describing the return shape (normalized + native diff, validation including reverse references). For a 7-parameter mutation tool it is nearly complete; it could still say how the new record's ID is surfaced and how this differs operationally from create_record.

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

Parameters3/5

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

Schema coverage is 71%, so the schema already documents most parameters (apply, category, allowScript, acknowledgeWarnings, description). The description reinforces the apply/preview semantics and ties acknowledgeWarnings implicitly to a clean preview, but says nothing about name, description, or allowScript beyond what the schema states. Baseline 3 is appropriate.

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 and resource ('Duplicate a record') and immediately pins down the semantics with '(deep copy, new ID = max+1)', which is exactly what distinguishes it from database_create_record. The follow-up sentence clarifies the non-obvious scope of the copy (referenced records are shared, not cloned), so an agent knows precisely what this operation produces without opening the 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 a clear operating procedure: call without apply to get a preview, then pass apply=true 'when the preview is clean'. That is genuine when-to-do-what guidance for a mutation tool. It stops short of explicitly contrasting with database_create_record or stating prerequisite write permissions, so it is strong but not exhaustive.

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