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

RPG Maker MZ Authoring MCP

by NixonMSilva
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Compare records

database_compare_records
Read-onlyIdempotent

Compares two records from the same database category to show structural differences, so you can spot mismatched fields before making edits.

Instructions

Structural differences between two records of the same category.

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": {
      "category": "<category>",
      "a": "<a>",
      "b": "<b>"
    },
    "name": "database_compare_records"
  }
}

Input Schema

NameRequiredDescriptionDefault
aYes
bYes
categoryYesDatabase category

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that: no indication of how deep the structural comparison goes (shallow fields vs nested objects), what a no-difference result looks like, or that the result is not persisted anywhere.

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?

It is a single short fragment with no padding, but it is a sentence fragment rather than a front-loaded statement of action, and its brevity comes at the cost of missing information rather than from tight editing.

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

Completeness2/5

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

With no output schema and a low-coverage input schema, the description carries most of the burden for a three-parameter tool, yet it never describes the diff result shape or error conditions. It is enough to guess the intent but not enough to invoke the tool confidently.

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

Parameters2/5

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

Schema description coverage is only 33%: only 'category' is documented in the schema, while 'a' and 'b' are bare integers. The description hints that a and b are record identifiers within the same category, but it does not confirm they are integer record IDs, nor what representation the category enum values refer to, leaving the two undocumented parameters largely unexplained.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('two records of the same category') and the outcome ('structural differences'), so the operation is inferable as a comparison. But it is a noun-phrase fragment with no verb, and it never states that this is a read-only comparison distinct from retrieval siblings like database_get_record or database_search_records.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of alternatives (e.g. why compare instead of fetching both records separately), and no stated preconditions such as both records needing to exist or share the given category. The phrase 'of the same category' implies one precondition but does not say what happens if it is violated.

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