Skip to main content
Glama
Redseb
by Redseb

create_npc

Create a complete, placed NPC event on a map with a single call. Provide dialogue text or explicit commands; the tool auto-builds the Show Text sequence, sprite, trigger, and direction.

Instructions

Create a complete, placed NPC event on a map in one call — a graphic + trigger + a talk list. Provide text (built into a Show Text sequence, with optional face/speaker) or an explicit commands array (commands wins if both given). Defaults to a solid, action-button NPC facing down. Warns (never blocks) on an unknown characterName, and on NO graphic at all (an NPC with no characterName is invisible in-game — use create_map_event for an intentionally-invisible trigger). The one-shot "make a talking NPC that says X" primitive.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
xYesX tile position
yYesY tile position
nameYesEvent name (editor label)
textNoDialogue lines shown when the NPC is triggered (built as Show Text)
forceNoWrite even if validation finds structural problems (wrong parameter count, unterminated command list). Off by default: such a write is refused and nothing is written. Advisory warnings never block regardless.
mapIdYesThe ID of the map to place the NPC on
dryRunNoPreview only: return a diff of what would change without writing to disk.
patternNoSprite frame 0–2 (default 1 = idle when a sprite is set)
throughNoLet the player pass through (default false)
triggerNoWhat starts the event (default action_button)
commandsNoExplicit command list (from the build_* tools); overrides `text` if given
faceNameNotext: face image basename (from list_assets("faces"))
priorityNoStacking vs. the player (default same = solid)
directionNoFacing direction (default down)
faceIndexNotext: face index 0–7
speakerNameNotext: MZ name-box speaker name
characterNameNoSprite sheet basename (from list_assets("characters"))
characterIndexNoSprite index 0–7 in the sheet
Behavior4/5

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

No annotations provided, so the description carries the burden. It discloses that unknown characterName or missing graphic only warns, never blocks; that an NPC without characterName is invisible in-game; and that commands wins over text. This is substantial behavioral context, though it does not mention return values or side effects on success.

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?

Four sentences, front-loaded with the core purpose, each sentence adds distinct information (modes, defaults, warnings, alternative). No fluff.

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 tool with no annotations and no output schema, the description covers purpose, modes, defaults, edge cases (invisible NPC), and alternative tools. It lacks only an explicit description of return value or success/failure response, but overall is quite complete.

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?

All 18 parameters have schema descriptions (100% coverage), so baseline is 3. The description adds value by explaining the relationship between `text` and `commands` (commands wins), how `text` is built into Show Text with optional face/speaker, and defaults for trigger, priority, direction. This exceeds baseline.

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?

The description uses a specific verb+resource ('Create a complete, placed NPC event on a map in one call') and clearly distinguishes from sibling create_map_event by noting the invisibility issue and explicitly referencing it for intentionally-invisible triggers. The 'one-shot' primitive characterization further clarifies its scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use versus create_map_event ('use create_map_event for an intentionally-invisible trigger'), and explains the precedence of `commands` over `text` when both are given, plus defaults like action-button trigger and solid priority. This is clear guidance.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Redseb/rpgmaker-mz-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server