Skip to main content
Glama
Sign In
RPG Maker MV MCP Server

RPG Maker MV MCP Server

by Xerolo44
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Add dialogue

add_dialogue

Add spoken dialogue to an RPG Maker MV event page in one call. Automatically builds Show Text commands and splits lines into message boxes every four lines.

Instructions

Add spoken dialogue to an event page in one call — builds the Show Text (101) and text-line (401) commands automatically, splitting into multiple message boxes every 4 lines. Inserted before the page's end, like add_event_command.

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": {
      "mapId": "<mapId>",
      "eventId": "<eventId>",
      "lines": "<lines>"
    },
    "name": "add_dialogue"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesYesDialogue lines (a new message box starts every 4 lines)
mapIdYes
eventIdYes
faceNameNoFace image file (e.g. 'Actor1'), empty for none
positionNo0 top, 1 middle, 2 bottom
faceIndexNo
pageIndexNo
backgroundNo0 window, 1 dim, 2 transparent

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A3.7/5.0
Behavior3/5

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

With no annotations, the description carries the full burden; it does disclose real behavior — commands are generated automatically, message boxes split every 4 lines, and content is inserted before the page's end. However it says nothing about whether it requires a changeset/begin_changeset, whether existing dialogue is preserved or overwritten, or what the call returns, which matters for a mutation tool with zero annotation coverage.

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?

A single tight sentence with the resource and the auto-construction behavior front-loaded and zero filler. Every clause — mechanism, splitting rule, insertion point — carries information an agent needs.

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

Completeness3/5

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers the core action and the one non-obvious behavior (4-line splitting) but omits prerequisites, effects on existing commands, and return shape. Adequate to call it, not adequate to call it safely.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 50%: the schema documents lines, faceName, position and background, while faceIndex, pageIndex, mapId and eventId are bare. The description only reinforces the 4-line splitting rule already stated in the schema and never explains face selection, position, background modes, or page selection, so it does not compensate for the coverage gap.

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?

Names a specific verb+resource ('Add spoken dialogue to an event page') and immediately explains the mechanism (auto-builds Show Text 101 and text-line 401 commands). It also distinguishes itself from the lower-level sibling by noting the insertion behavior is 'like add_event_command', so an agent can place it relative to the raw command tool without opening a schema.

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

Usage Guidelines3/5

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

Usage is implied rather than stated: use this instead of hand-writing 101/401 commands. There is no explicit when-not guidance and no routing to alternatives such as build_dialogue_tree, add_event_command, or update_event, which all plausibly overlap. An agent can infer intent but must guess at boundaries.

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