Skip to main content
Glama
Xerolo44

RPG Maker MV MCP Server

by Xerolo44
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Import asset

import_asset

Copies a local image or sound file into a project's img or audio folder, detecting the real format from its file header and only replacing an existing asset when overwrite is enabled.

Instructions

Copy an image or sound file from this computer into the project: //.. source must be an absolute local path to a regular file (no relative paths, network/UNC shares, devices or symbolic links). The type is read from the file's header, never its extension: img/* folders take files with a PNG header (max 32 MiB; only the signature + IHDR is checked, not the whole image), audio/* folders take files whose header is Ogg (OggS) or ISO-BMFF/M4A (ftyp) (max 128 MiB; only the header is checked, not the codec or the full file); the extension (.png, .ogg, .m4a) is chosen from the detected header. name defaults to the source file name without its extension and must be 1-64 characters from A-Z a-z 0-9 space _ ! $ ( ) - (no dots, no path); a '$' prefix on a character sheet means one character per sheet, '!' means no offset. An existing file with the same name (letter case ignored) is only replaced with overwrite: true; the session backup (list_backups / restore_backup) keeps the file as it was before this server session first touched it (until set_project is called again, which starts the snapshots over), so a file that was itself created or changed earlier in the same session has no backup of that intermediate version. Nothing is converted or resized; warnings flag sheet sizes that do not fit the folder's layout, and for audio a missing sibling format (MV's web build needs both .ogg and .m4a). Refused while a changeset is open (binary files cannot be staged): commit or discard it first.

Input Schema

NameRequiredDescriptionDefault
nameNoFile name without extension; defaults to the source's base name
folderYesDestination asset folder, e.g. img/characters or audio/bgm
sourceYesAbsolute path of the file to import, e.g. C:\art\Hero.png or /home/me/art/Hero.png
overwriteNoReplace an existing file with this name

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.5.1

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the whole burden and does so thoroughly: header-based type detection with size caps (32 MiB images, 128 MiB audio) and a note that only the header is checked, not the codec or full file. It also discloses backup/snapshot semantics for the session, the case-insensitive replacement rule, warning behavior for sheet layout mismatches and missing sibling audio formats, and the changeset refusal.

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?

Front-loaded with purpose and destination, and nearly every sentence contributes operational detail. However, it is one dense paragraph that packs type detection, naming rules, overwrite, backup history, warnings, and changeset constraints together; splitting into short scannable blocks would improve it without losing content.

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?

For a 4-parameter mutation tool with no annotations and no output schema, the description covers everything an agent needs to call it correctly: path constraints, header rules and size caps, naming rules, overwrite behavior, rollback path, and the changeset precondition.

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

Parameters5/5

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

Schema coverage is 100%, so the baseline would be 3, but the description adds substantial meaning beyond it: source must be an absolute path to a regular file with no relative paths, UNC shares, devices, or symlinks; name is 1-64 chars from a specific character set with no dots or path separators; and the '$'/'!' prefixes carry character-sheet semantics. The extension is derived from the detected header, not the provided name.

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?

Opens with a concrete verb+resource+destination shape: "Copy an image or sound file from this computer into the project: <project>/<folder>/<name>.<ext>." That clearly separates it from read-only siblings like list_assets, preview_asset, and audit_assets.

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 real preconditions and exclusions: overwrite must be true to replace, nothing is converted, and the tool is refused while a changeset is open (commit or discard first). It also points to list_backups/restore_backup for the recovery path. It does not explicitly name alternatives such as preview_asset or audit_assets for pre-import validation, so it falls just short of a 5.

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