Skip to main content
Glama
twrsm666

rpgmaker-mcp

by twrsm666
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

Add a chest that pays out once

make_chest
DestructiveIdempotent

Create an RPG Maker MZ chest event with closed and opened pages, message, loot, self-switch handling, and optional lock condition, since MZ has no chest command.

Instructions

Place a chest: the closed graphic, the line it says, what it gives, and the opened page that replaces it afterwards. MZ has no chest command, so this writes the two pages the engine does read — page 0 hands out the contents and sets self switch A, page 1 is conditioned on self switch A and shows the open chest. Because a self switch is keyed to the event id, copy_event of this chest gives a second chest that is closed again. requires gates the payout with a Conditional Branch rather than a page, so a locked chest stays openable once the key condition arrives instead of silently becoming an unlocked one. The contents are checked before anything is written: an id that is a blank slot, or gold that would make this a tax, fails the call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYes
yYes
nameNo
mapIdYes
soundNoSE played on opening; default Chest1
graphicNoDefaults to the !Chest sheet every MZ project ships, closed at index 0 and open at index 1
messageNoSaid as it is opened, e.g. "Inside is a lantern and 40 gold."
replaceNo
contentsYesWhat the chest gives when opened
requiresNoWhat the player must have or have done first, e.g. {switch: 4} or {item: 3}. A condition is one of {switch: id, value?}, {selfSwitch: "A".."D", value?}, {variable: id, op?: "=="|">="|"<="|">"|"<"|"!=", value: n or {variable: id}} (op defaults to ">="), {item: id}, {weapon: id}, {armor: id}, {gold: n} (at least n), {actor: id, state?|skill?}, {button: "ok", pressed?}, or {code: 111, parameters: [...]} to write the engine's own shape.
lockedMessageNoSaid when `requires` is not met; default "It is locked."

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.2

TDQS

A4.5/5.0
Behavior5/5

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

Annotations only carry idempotentHint and destructiveHint; the description goes well beyond them, disclosing the two-page self-switch architecture, that `requires` is implemented as a Conditional Branch so a locked chest stays openable, and that validation runs before any write (blank slot id or gold-as-tax fails the call). This is rich, non-obvious behavioral context.

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 action, then details; four dense sentences where each carries real information. Slightly heavy on mechanism (self switch, copy_event) that could be trimmed, but nothing is redundant.

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 an 11-param tool with nested objects and no output schema, it covers what gets written, the payout-once behavior, validation failures, and the requires-gating semantics. It omits any statement of what the call returns and does not address the `replace` flag, leaving minor gaps.

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 55% and several properties (x, y, mapId, name, replace) lack descriptions, but the prose compensates by explaining the semantics of `requires`/`lockedMessage` interaction and the `contents` validation, adding meaning beyond the schema for the most complex nested params.

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?

Opens with a concrete verb+resource: 'Place a chest' and enumerates the exact parts it writes (closed graphic, message line, contents, replaced open page). An agent can distinguish it immediately from siblings like place_event, make_npc, or make_shop, which handle different event types.

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?

Explains that MZ has no chest command so this tool is the intended path, and clarifies the copy_event interaction (a copied chest is closed again because self switches key off event id). It never states exclusions or names a sibling alternative for edge cases, so it's strong context without explicit when-not-to-use routing.

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