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

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

database delete record

database_delete_record
Destructive

Deletes an RPG Maker MZ database record without renumbering IDs: preview references, then clear the slot or truncate the highest ID before applying confirmed changes.

Instructions

DESTRUCTIVE: delete a record without renumbering. mode "clear" (default) replaces it with a blank record in the same slot; "truncate_last" removes the highest ID only. The preview lists every known reference. Apply with apply_changes + confirm.

Preview-first: returns a change set (normalized + native diff, validation incl. reverse references). Destructive: apply only via apply_changes with confirm.

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_delete_record"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYes
modeNo
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.5/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the description's job is to add specifics – and it does: in-place blanking vs. highest-ID truncation, a preview that 'lists every known reference', reverse-reference validation, and the returned change set with normalized and native diffs. It also explains the hard gate that real mutation goes through apply_changes.

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 DESTRUCTIVE banner and mode semantics, which is exactly the right ordering. There is minor redundancy – the apply_changes/confirm rule is stated twice ('Apply with apply_changes + confirm' and again in the closing 'Destructive: apply only via apply_changes with confirm').

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 destructive tool with no output schema, the description supplies the essentials: what gets destroyed, how references are surfaced, what the preview returns, and how application is gated. Additional detail on warning acknowledgement interplay and the 'description' audit-log parameter would have closed the remaining gap.

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 71% and the description meaningfully supplements the weakest point by defining the two 'mode' enum values and their outcomes, plus the preview/apply contract. It says nothing about 'id', 'category', 'allowScript', or 'acknowledgeWarnings', so a small amount of semantic weight is left entirely to 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 specific verb and resource ('delete a record') plus a non-obvious behavioral detail ('without renumbering'), then spells out both modes: 'clear' blanks the slot in place, 'truncate_last' removes the highest ID. An agent can predict exactly what the record slot looks like after each mode without touching 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 workflow: preview first, then 'apply only via apply_changes with confirm', which routes the agent to the sibling that performs the commit. It does not explicitly state when not to use this tool (e.g. update/duplicate alternatives for edits), so it stops short of full when/when-not guidance.

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