Skip to main content
Glama

Create event from template

create_event_from_template

Creates a complete, ready-to-use RPG Maker MV map event at a chosen tile from a template such as chest, door, inn, shop, save point, or NPC in one write, validating bounds and occupancy.

Instructions

Creates a complete, ready-to-use map event at (x, y) from a template, in one write. Refuses out-of-bounds tiles, and refuses a tile that already holds an event unless allowStack is true. Graphics default to none: events are INVISIBLE in game until an image is supplied (chest: closedImage/openImage, npc: image; locked_door, inn, shop and save_point never get a graphic and are meant to sit on a tile that already looks right). Templates and their params: chest {reward: {gold?, item?: {type: item|weapon|armor, id, count?}}, message?, closedImage?, openImage?} (two pages: the action button opens it and sets self switch A, then an empty opened page; if only closedImage is given, openImage defaults to the same graphic with direction 8 - the opened-chest frame of the standard chest sheets); locked_door {keyItemId, destination: {mapId, x, y, direction?: 0|2|4|6|8}, lockedMessage?, consumeKey?} (transfers the player if the party holds the key); inn {price, greeting?} (Stay/Leave choice; staying charges gold, fades out, restores the party, fades in); shop {goods: [{type: item|weapon|armor, id, price?}] (1-40; price defaults to the database price), purchaseOnly?}; save_point {} (opens the save screen); npc {lines: string[], face?: {name, index}, image?}. Image = {characterName, characterIndex (0-7), direction?: 2|4|6|8, pattern?: 0|1|2}. Returns { eventId, name, pages }.

Input Schema

NameRequiredDescriptionDefault
xYes
yYes
faceNonpc: face portrait { name, index }
nameNoEvent name; defaults to the template name (Chest, Door, Inn, Shop, Save Point, NPC)
goodsNoshop: 1-40 entries { type: item|weapon|armor, id, price? }; omit price for the database price
imageNonpc: the NPC's character graphic
linesNonpc: lines of dialogue (4 per message box)
mapIdYes
priceNoinn: gold per night (>= 0)
rewardNochest: { gold?: number, item?: {type: item|weapon|armor, id, count?} }, at least one
messageNochest: text shown when opened (default "You found treasure!")
greetingNoinn: text shown first
templateYesWhich template to build; the other fields depend on it
keyItemIdNolocked_door: item id of the key
openImageNochest: graphic after opening (default: closedImage facing up)
allowStackNoAllow placing the event on a tile that already has an event
consumeKeyNolocked_door: remove one key on use
closedImageNochest: graphic before opening
destinationNolocked_door: { mapId, x, y, direction?: 0|2|4|6|8 }
purchaseOnlyNoshop: disable selling
lockedMessageNolocked_door: text when the player has no key (default "It's locked.")

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.6/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses that this is a write, refuses out-of-bounds tiles and stacking unless allowStack is true, explains that graphics default to none making events invisible, and details template-specific side effects (chest pages, locked_door transfers, inn charges). It also states the return shape.

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?

The description is long but justified by 21 parameters and 6 templates. It is front-loaded with the core action and constraints, and every sentence adds information. Still, a dense paragraph could be more scannable as a list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (21 params, nested objects, 6 templates) and no output schema, the description covers constraints, defaults, template behaviors, and return value thoroughly. Nothing critical for correct invocation appears missing.

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 86% (high), so baseline is 3. The description adds value by summarizing template-dependent parameters and defaults (e.g., openImage defaults to closedImage facing up; shop goods 1-40; reward requires at least one). However, much of the template parameter listing duplicates schema descriptions, so it doesn't fully transcend 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 ('Creates'), resource ('map event'), and scope ('at (x, y) from a template, in one write'). This clearly distinguishes it from generic siblings like create_event or update_event by emphasizing the template-based approach.

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?

Provides clear context: use for building standard events (chest, npc, etc.) in a single write. However, it never explicitly names alternatives (e.g., create_event) or states when not to use this tool, leaving that to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.