Skip to main content
Glama
Sign In
RPG Maker MZ Authoring MCP

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Get native page data

get_event_page_native
Read-onlyIdempotent

Retrieve raw native JSON for an event page, common event, or troop page to inspect and debug RPG Maker MZ project data.

Instructions

Raw native JSON of a page / common event / troop page, for debugging.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get_event_page_native"
  }
}

Input Schema

NameRequiredDescriptionDefault
mapIdNoMap ID (map event page)
eventIdNoEvent ID (map event page)
troopIdNoTroop ID (battle event page)
pageIndexNoZERO-based page index (map event or troop page)
commonEventIdNoCommon event ID

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

B3.4/5.0
Behavior3/5

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

Annotations already cover the safety profile fully (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description adds the useful fact that the return is raw/unprocessed native JSON intended for debugging rather than a modeled view, but leaves unstated whether the raw form is stable or safe to round-trip.

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?

A single short sentence, front-loaded with the resource and disclosing the raw/return nature and the debugging intent. No filler, though the terseness leaves real gaps that a second sentence could have closed.

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?

The tool is mechanically simple (no output schema, flat params, all optional), and the description covers the essential 'what you get back'. It falls short on how to select the target page, which is the main thing an agent could get wrong with five all-optional parameters spanning three page types.

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 description coverage is 100% and all five parameters are documented, so the baseline of 3 applies. However, the description gives no hint about the mode-selection semantics: nothing says the caller picks one of map/event, troop, or common-event identification, and with zero required parameters an agent must deduce valid combinations from the schema alone.

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+resource: returns 'Raw native JSON of a page / common event / troop page'. The word 'Raw' plus 'for debugging' implies a low-level dump, which distinguishes it implicitly from the structured get_event_page sibling. It doesn't explicitly name that sibling, so the differentiation is left partly to inference.

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?

'For debugging' implies a when-to-use context, suggesting inspection of the underlying data rather than modeled access. There is no explicit when-not, no named alternative (e.g. get_event_page for structured content), and no note that this is the fallback when normal reads are insufficient.

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