RPGMakerUltimate-MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v5.12.2
Disambiguation4/5
Tools are largely distinct with clear purposes, but query_database and get_project_context both provide database information, potentially causing minor confusion. Otherwise, each tool targets a specific operation.
Naming Consistency5/5
All tools follow a consistent verb_noun pattern in snake_case, such as create_database_entry, generate_map, and query_map, making naming predictable and clear.
Tool Count5/5
With 12 tools, the server covers essential RPG Maker MV operations (CRUD for databases, maps, events, system settings) without being overly numerous or sparse.
Completeness4/5
The toolset provides comprehensive coverage for editing and querying databases, maps, and events. Minor gaps include lack of a direct map deletion tool and limited support for common events, but overall functionality is robust.
Average 4.8/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 57 commits in the last 12 weeks
- Last stable release on July 23, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
This repository includes a glama.json configuration file.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
View related servers

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint and idempotentHint; description adds specifics like failure on missing file, offline nature of ascii view, and validation behavior, adding value beyond annotations.
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?
Efficient and front-loaded with 'Read-only: inspect maps.' Each sentence serves a purpose, but the description is somewhat dense; could be slightly shorter.
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 7 parameters, 1 required, and no output schema, the description thoroughly explains each view's return format, failure cases, and even provides a cheap way to 'see' layout via ASCII. Complete for the tool's complexity.
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?
While schema has 100% coverage, the description adds meaning by explaining what each view returns (e.g., 'full' returns dimensions and tile data, 'validate' returns issueCount and issues). This compensates for the lack of output 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?
The description clearly states it is a read-only tool to inspect maps, with specific verbs like 'inspect' and lists each view. It distinguishes itself from siblings like edit_map and generate_map by emphasizing read-only nature.
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 explicit when-to-use for each view and mentions an alternative tool (analyze_image) for player-visible images. Could be more explicit about when not to use, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds concrete behavioral details beyond annotations: nulls out in data file, written immediately, not undoable, IDs never reused, and broken references. Annotations only indicate destructive and idempotent, so the description greatly enhances transparency.
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 dense but well-structured, front-loading the critical 'DESTRUCTIVE' label and immediate behaviors. Every sentence provides necessary information, though slightly longer than ideal; still clear and concise.
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?
Despite lacking output schema, the description covers all needed context: purpose, side effects, forbidden IDs, supported entities, and return value. It is complete for a destructive tool with 2 parameters.
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 100% and the schema already describes both parameters, including the prohibition on specific IDs for skills and states. The description restates the constraint but adds no new semantic detail beyond the schema, resulting in a baseline score of 3.
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 clearly states the verb (delete), the resource (database entry), and specifics about how it works (nulling in data file, immediate, not undoable). It lists supported entities and distinguishes from sibling tools like create, update, and query.
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?
The description explicitly warns about side effects (broken references) and advises to check/update related data with query_database/update_database_entry first. It also specifies forbidden IDs (skill 1/2, state 1), providing clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (which indicate not read-only, not destructive, idempotent), the description discloses that writes are immediate, set_starting_position is not validated, and name_switch/name_variable is documentation-only. No contradictions.
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 well-structured with a clear first sentence and subsequent details per action, but slightly verbose. However, every sentence adds value.
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?
The description covers all actions and parameters comprehensively, including warnings about unvalidated map IDs and no effect on saved games. Lacks error handling details, but acceptable given no output schema.
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?
With 100% schema coverage, the description still adds significant meaning: explains the 'full' section is large, unnamed entries are empty strings (useful for finding free IDs), and set_starting_position requires map validation via another tool.
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 clearly states the tool reads or edits project-wide settings in data/System.json, lists all actions, and distinguishes itself from sibling tools that handle other database entries, maps, or events.
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?
The description explains when to use each action (e.g., 'get' for reading sections, 'set_starting_position' for starting position), but does not explicitly state when not to use this tool or mention alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds details: caching of the model, whole-project scope, and specific behaviors for each view (e.g., validate returns issueCount, bySeverity, issues[]). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is quite long but well-structured with a front-loaded purpose and a bullet-like listing of views. While every sentence adds value, the length could be reduced without losing clarity. Still, it maintains reasonable conciseness for a complex tool.
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 12 parameters, no output schema, and multiple views, the description covers all behaviors, outputs for each lens, parameter dependencies, and caching. It is fully sufficient for an agent to select and invoke the tool correctly.
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 100% with descriptions for all 12 parameters. The description adds significant extra context by associating parameters with specific views (e.g., 'view=usage expects kind and id'), explaining enum values, and detailing output formats. This goes beyond the schema descriptions.
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 clearly states the tool provides read-only project intelligence, building an in-memory model for reasoning. It enumerates specific lenses (overview, index, validate, etc.), differentiating it from sibling tools like edit_map or manage_map_event which modify the project.
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 'Read-only project intelligence' and 'Nothing is written.' Advises to pair with editor tools for action. This tells the agent when to use (analysis) and when not to (modification), with clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide idempotentHint=true, readOnlyHint=false, destructiveHint=false. The description adds behavioral details: session-wide side effect, path validation (checks for data/System.json), error behavior (fails leaving previous active), and return value (new active path). No contradictions.
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?
Three sentences front-load the purpose, then side effect, then return/alternative. No wasted words; every sentence adds value.
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 tool's simplicity (one parameter, no output schema), the description covers purpose, side effects, validation, return value, and the alternative (environment variable). No missing critical details.
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 covers 100% of parameters with a clear description. The description adds validation context (must contain data/System.json) and emphasizes absolute path, which enhances understanding beyond 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?
The description clearly states the tool's purpose: switching to a different RPG Maker MV project directory. It specifies the action (switch), the resource (project directory), and distinguishes from the startup environment variable, making it unique among siblings.
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?
The description explains when to use the tool (to change the project directory) and notes the alternative (environment variable at startup). It implies persistence until changed or restart, but doesn't explicitly mention when not to use it or compare with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses multiple behavioral traits beyond annotations: partial update with array replacement, immediate write with no undo, error on missing ID, special append operations, class parameter handling, and side effects of editing tilesets. No contradiction with annotations.
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 lengthy but every sentence adds necessary detail. It front-loads the main purpose and then logically covers nuances. Minor room for trimming, but well-structured overall.
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?
Covers return value (full entry after update), error conditions (ID not existing, unsupported updates), and provides sufficient detail for the 5-parameter, nested-object input. No output schema needed.
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 has 100% parameter description coverage, but the description adds meaning: clarifies fields behavior (overwrites only given keys, arrays replaced), explains append operations and their parameters, and adds context for class params (seeds or full curves).
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 clearly states it partially updates an existing database entry, specifying that only keys in 'fields' are overwritten and arrays are replaced wholesale. It distinguishes from sibling tools like create_database_entry and delete_database_entry by focusing on update behavior.
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 explicit guidance: fetch current values with query_database before updating if a revert might be needed. Notes unsupported cases like plain troop updates and animations. However, does not directly compare to alternatives like create_database_entry or delete_database_entry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that fill_layer is destructive and not undoable, writes immediately, and per-action error behavior. Matches annotations: destructiveHint=true, idempotentHint=true. Adds context like layer ranges, tile clearing, and encounter defaults beyond annotations.
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?
Description is moderately sized and front-loaded with main purpose. Each sentence contributes, but could be slightly tighter (e.g., repeating 'action' reference). Still well-structured and readable.
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?
Covers all 5 actions, parameters, side effects, error handling, and links to related tools. No output schema, but 'Returns per-action summary' suffices. Complex tool (12 params, nested) fully addressed.
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 100% with parameter descriptions, but tool description adds critical context (e.g., layer meanings, tile ID source via get_project_context, encounter format). Enriches understanding beyond schema alone.
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?
Tool name 'edit_map' and title 'Edit map' are clear. Description begins with 'Modify existing maps' and enumerates 5 distinct actions, each with specific purpose. Distinguishes from sibling tools like 'manage_map_event' and implicitly from 'generate_map'.
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 'For event-level work use manage_map_event' as alternative. Each action's use case is described (e.g., 'organize_tree' is purely organizational, 'set_encounters' affects random battles). Provides conditions like required map existence and exception for set_display_names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses behaviors beyond annotations: immediate write ('written immediately'), destructive nature of delete ('DESTRUCTIVE'), no validation for IDs or walkability, and side effects of convert (replaces behavior in place). Annotations already indicate destructiveHint=true, but description adds rich context.
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 well-structured: grouped by action and preset with clear hierarchy. Every sentence adds value, though some redundancy could be trimmed (e.g., repeating 'action'). Given the complexity (36 params, 6 actions, 8 presets), it is appropriately concise.
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?
The description covers return values ('Returns the created/updated event(s) with ids') and failure conditions ('Fails with an error if the map... does not exist'). No output schema exists, so return description is minimal but adequate. Could add more on error messages or pagination, but overall complete for the tool's complexity.
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?
With 100% schema coverage, baseline is 3, but the description adds extensive semantics: explaining role of each preset, required fields for nested objects (e.g., items for chest, goods for shop), and behavioral nuances (locked door, puzzle_switch creating two events). It significantly enhances understanding beyond schema descriptions.
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 clearly states the tool's purpose: 'Create, modify or remove events on a map'. It distinguishes multiple actions (create, update, convert, delete, add_command, populate) and presets, providing specific details for each, differentiating it from siblings like edit_map or create_database_entry.
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?
The description gives explicit guidance for each action and preset, including when to use alternatives (e.g., 'add behavior later with add_command'), validation notes (IDs not validated, destination not validated), and prerequisites (map must exist). It also references sibling tools like query_database and get_project_context for further steps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses network side effects (image sent to external API), required env vars, and failure modes. Annotations already state readOnly, safe, idempotent, open-world; description adds critical behavioral context without contradiction.
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 fairly long but well-structured with clear mode breakdowns. Every sentence provides necessary info; minor verbosity in the 'ai' mode explanation but overall earns its space.
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 complex tool with three modes, network side effects, and offline analysis, the description covers all important aspects: return values, failure modes, environment dependencies, and alternatives. No output schema but return format is described per mode.
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 descriptions cover all 5 parameters, but the description adds significant value by explaining mode-specific usage, defaults (resizeMax=1024), and constraints (base64PNG must be raw). This goes beyond the schema's basic descriptions.
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 clearly states the tool analyzes images with three distinct modes (ai, grid, colors), each with specific functionality. It distinguishes itself from sibling tool query_map by noting that query_map's 'ascii' view is better for precise map layout.
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?
The description provides explicit when-to-use guidance for each mode, including failure conditions (path escapes, missing file, API timeout) and a clear alternative (query_map for map layout). This helps the agent decide correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors: immediate file write, return of complete object, preset validation with error on missing fields, automatic curve expansion for class params, and non-validation of referenced IDs. This adds substantial value beyond the annotations, which only mark read/write safety.
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 comprehensive but well-structured: core function and return in first sentence, then forms, presets, special cases, and limitations. While lengthy, each sentence adds necessary detail, and the front-loading of key info aids quick comprehension.
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 tool's complexity (two modes, presets, special handling) and no output schema, the description fully covers return values, validation behavior, unsupported types, and ID validation warnings, providing complete guidance for correct invocation.
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?
With 100% schema coverage, the description still enriches understanding by clarifying raw vs preset usage, listing exact preset required fields, explaining class param expansion, and detailing expected data structures (e.g., effects for items, members for troops). This goes well beyond the schema's basic property descriptions.
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 clearly states the tool creates a new entry with the next free ID in an RPG Maker MV database. It distinguishes itself from sibling tools like query_database and delete_database_entry by detailing two creation forms (raw and preset) and specifying the returned object.
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?
The description explains when to use each form: raw entity+data for custom entries, presets for common types. It explicitly excludes tilesets/animations (use the editor) and advises confirming referenced IDs with query_database, providing clear usage context and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behaviors beyond annotations: immediate file writing, cloning of hand-authored templates, auto-picking closest size, reproducibility with same seed and params, transfer events pointing to original destinations in duplicate mode, and failure conditions (unknown theme/template, unwritable files). Annotations (readOnlyHint=false, destructiveHint=false) are consistent and complemented.
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 dense but well-structured, with the core purpose upfront and mode-specific details logically organized. It is slightly long due to the complexity (6 modes, 19 parameters), but every sentence adds value. A minor condensation could improve conciseness.
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 tool's complexity (19 parameters, 6 modes, no output schema), the description provides complete context: all modes, parameter interactions, defaults, return values (mapId, seed, interiorMapIds, batch keys), and failure conditions. No gaps are evident.
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?
With 100% schema description coverage, the tool description adds significant context for parameters: defaults (e.g., mode defaults to procedural, width/height defaults per mode), required conditions (e.g., name required for duplicate, theme required for themed/procedural), and warnings (mismatched tileset renders garbage). This exceeds mere schema repetition.
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 clearly states the tool creates a new map file with a free ID, registers it, and writes immediately. It distinguishes six modes (blank, themed, procedural, batch, duplicate, template) and their specific behaviors, which differentiates it from siblings like edit_map.
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?
The description explicitly explains when to use each mode, e.g., blank for later painting, themed for simple tile layout, procedural for full generator with templates, batch for multiple maps, duplicate for copying, template for instantiating bundled maps. It also mentions alternatives like edit_map for painting layers and get_project_context for listing templates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. Description adds valuable behavioral context: warns against inventing tile IDs ('guessing tile IDs produces glitched maps'), explains return types, and details what each mode outputs. No contradictions.
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?
Well-structured with clear ordering: main purpose, detail modes, golden rules. Every sentence adds value, though the description is lengthy due to the tool's complexity. Could be slightly tighter, but still efficient.
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?
Completely covers all aspects: explains every detail mode, parameters, return types, and golden rules for correct usage. Even without an output schema, the description makes it clear what to expect. No gaps for an agent to misuse the tool.
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?
Input schema has 100% coverage, but description adds meaning beyond schema: explains what each enum value of 'detail' returns, and for tilesetId, category, theme, it specifies their role in filtering. Schema defers to description for full semantics.
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?
Explicitly states it is 'read-only: pre-digested project knowledge' and advises 'CALL THIS FIRST'. Clearly distinguishes each detail mode (full, summary, assets, tileset, templates) with specific use cases, differentiating it from sibling tools like query_map and generate_map.
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?
Provides explicit when-to-use instructions: 'CALL THIS FIRST'. Golden rules guide proper usage: use generate_map for maps, never invent IDs, set encounters correctly. Details when to use each detail mode (e.g., 'tileset' for edit_map 'fill_layer').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only, non-destructive, idempotent. Description adds key behaviors: returns null for missing id (not error), case-insensitive search, description matching for certain entities. No contradictions.
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?
Concise and well-structured: starts with read-only safety emphasis, then enumerates three usage forms, provides usage guidance, and ends with sibling differentiation. Every sentence adds value without redundancy.
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?
Despite no output schema, description explains return types (array vs single object/null) and covers all three modes. Provides complete context for usage, parameter interactions, and relationship to sibling tools. Fully sufficient for an AI agent.
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?
100% schema coverage with descriptions, but description adds crucial semantics: explains that omitting id and query lists all entries, id returns null on missing, query is case-insensitive and also matches descriptions for items/weapons/armors/skills. Significantly enriches understanding.
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 clearly states the tool queries RPG Maker MV database files, specifies three forms (list, fetch by id, search), and distinguishes from siblings (query_map, get_project_context). Verb 'query' and resource 'database' are explicit.
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 advises using before create/update/delete operations to discover IDs, and directs to query_map for maps and get_project_context for a full digest. Provides clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![RpgMakerMVUltimate-MCP MCP server](https://glama.ai/mcp/servers/DiegoLopez0208/RpgMakerMVUltimate-MCP/badges/card.svg)](https://glama.ai/mcp/servers/DiegoLopez0208/RpgMakerMVUltimate-MCP)

Score Badge

Copy to your README.md:

[![RpgMakerMVUltimate-MCP MCP server](https://glama.ai/mcp/servers/DiegoLopez0208/RpgMakerMVUltimate-MCP/badges/score.svg)](https://glama.ai/mcp/servers/DiegoLopez0208/RpgMakerMVUltimate-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/DiegoLopez0208/RpgMakerMVUltimate-MCP'

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