Skip to main content
Glama
Redseb

rpgmaker-mz-mcp

by Redseb
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

create_item

Create a new item in an RPG Maker MZ project's Items.json, returning the next unused id and using editor defaults for any omitted fields.

Instructions

Create a new item in data/Items.json. Only name is worth passing; omitted fields use the editor's new-item defaults (Regular Item, consumable, no effects). Allocates and returns the next unused item id. An effect referencing a missing record throws: Add/Remove State (code 21/22) → state, Learn Skill (43) → skill, Common Event (44) → common event.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYesItem name
noteNoNote field
priceNoBuy price (sells for half)
scopeNoTarget scope (0 none, 1 one enemy, 7 one ally, …)
speedNoSpeed correction (positive acts earlier)
damageNoDamage object { type, elementId, formula, variance, critical }
dryRunNoPreview only: return a diff of what would change without writing to disk.
tpGainNoUser TP gained on use
effectsNoEffect objects { code, dataId, value1, value2 }
hitTypeNo0 certain, 1 physical, 2 magical
itypeIdNoItem type: 1 Regular, 2 Key Item, 3 Hidden A, 4 Hidden B
repeatsNoNumber of hits/repeats
occasionNoUsable: 0 always, 1 battle, 2 menu, 3 never
iconIndexNoIcon index (IconSet.png)
consumableNoConsumed on use
animationIdNoAnimation id shown on use
descriptionNoIn-game description text
successRateNoSuccess rate percent

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • addedInput schema / properties / speed
      Added value: +{
+  "description": "Speed correction (positive acts earlier)",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}
  2. First observedv1.2.0

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the write target, default field population, id allocation/return, and throws on effects that reference missing records with specific codes. It omits overwrite/duplicate-name behavior and any mention that dryRun avoids the write, leaving a few behavioral gaps.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three tight sentences, front-loaded with the core action, then defaults, then error semantics. Every sentence earns its place and nothing is padded.

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 18-parameter, nested-object, annotation-free tool it covers the essentials: what it does, what to pass, defaults, return of the new id, and effect error modes. It leaves dryRun's preview semantics to the schema, which is acceptable but slightly under-explained given the complexity.

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 100%, so the baseline is 3, but the description adds real meaning: it tells the caller only name matters and that itypeId, consumable, and effects default to Regular Item / consumable / none. That maps directly to specific parameters beyond the schema text.

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?

States a specific verb and resource plus the exact target file (data/Items.json), which is enough to tell it apart from create_weapon/create_armor. It never explicitly names those siblings as alternatives, so differentiation is inferential rather than stated.

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 clear invocation context: 'Only name is worth passing' and that omitted fields fall back to editor defaults (Regular Item, consumable, no effects). It does not, however, say when to choose this over the other create_* database tools.

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