RPG Maker MZ/MV MCP Server

by garuh143

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation3/5
The five different skill creation tools (create_skill plus four specialized variants) create significant overlap and potential confusion about which to use. While other tools are well-differentiated by resource type and action, the skill creation redundancy and the similarity between 'create_map_event' and 'add_event_command' (which targets event pages, not events) could cause misselection.
Naming Consistency4/5
Tools follow a consistent snake_case convention with clear verb_noun patterns. Verbs are well-chosen and semantically distinct (create vs add vs update vs set vs paint). The only minor issue is the mix of singular and plural nouns (get_actor vs get_actors), though this follows a predictable pattern for list vs single-item retrieval.
Tool Count3/5
With 37 tools, the surface is quite heavy and pushes beyond the ideal range for an MCP server. While RPG Maker is a complex domain requiring coverage of actors, skills, maps, and events, the count is inflated by redundant skill creation shortcuts and very granular operations. The breadth risks overwhelming agent context windows.
Completeness3/5
The surface covers major game elements (actors, skills, maps, events) with reasonable CRUD operations, but has notable gaps: items lack a create operation despite having update, armors and weapons are read-only, and there's no apparent delete functionality for any resource. Missing game systems like enemies, troops, and classes limit full game authoring capability.
Average 2.7/5 across 37 of 37 tools scored. Lowest: 1.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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.
Add a glama.json file to provide metadata about your server.
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.
Add related servers to improve discoverability.

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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, the description omits idempotency guarantees, error handling (e.g., duplicate names), side effects, or return value structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, the description is brief, but this reflects under-specification rather than efficient information density. It front-loads nothing useful for parameter interpretation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Grossly inadequate for a 14-parameter object creation tool with no output schema. The description omits the domain model (RPG character system), parameter relationships (e.g., initialLevel vs maxLevel constraints), and return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description fails to compensate. Critical game-specific parameters (battlerName, faceIndex, characterIndex, classId) receive no explanation. The description adds zero semantic value beyond the bare schema property names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new actor' is a tautology that restates the function name without defining what an 'actor' represents in this game development context (playable character). It fails to distinguish from siblings like update_actor or search_actors.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use create_actor versus update_actor, or prerequisites for creation. No mention of whether actors can be duplicated or if unique constraints apply.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but fails to deliver. While 'Update' implies mutation, the description does not clarify if this change is persistent, if it affects active game sessions, requires specific permissions, or what happens to the previous starting position. It provides minimal behavioral context beyond the operation type.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
While brief at only four words, this represents under-specification rather than appropriate conciseness. The single sentence does not earn its place by providing actionable guidance, leaving the agent with insufficient information to invoke the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with three undocumented parameters, no annotations, and no output schema, the three-word description is completely inadequate. It lacks explanation of the coordinate system, map reference semantics, return values, or side effects—essential information given the complete absence of structured metadata.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for its three parameters (mapId, x, y), and the description completely fails to compensate for this gap. It does not explain that x and y represent coordinates, what coordinate system is used, or that mapId refers to a specific game map. The agent is given no semantic information to correctly populate these required fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update the game starting position' essentially restates the tool name with spaces added, constituting a tautology. While it identifies the verb (Update) and resource (game starting position), it fails to distinguish this tool from sibling update tools like update_actor or update_map_event, and does not clarify what 'starting position' means in the context of the game system.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives such as update_actor or create_map. There are no prerequisites mentioned, no warnings about side effects, and no indication of when this update is appropriate versus other state modifications.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies a write operation via 'Set' but fails to specify idempotency, error handling (what if switchId is invalid?), return values, or whether this creates a new switch or renames an existing one.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
At three words, the description is technically brief, but this represents under-specification rather than efficient communication. There is no structural prioritization of information because there is virtually no information present.
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?
Given the lack of output schema, annotations, and parameter descriptions, the description provides insufficient context. For a simple two-parameter mutation tool, the single phrase fails to establish domain context (e.g., that switches are boolean game states) or operational expectations.
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 0%, requiring the description to compensate for undocumented parameters. While 'Set a switch name' loosely maps to the 'name' parameter and implies a target switch, it provides no details on 'switchId' semantics, name constraints, or validation rules.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a switch name' is tautological, merely restating the tool name with slight grammatical variation. While it confirms the domain (switches vs. variables), it fails to distinguish from the sibling tool 'set_variable_name' or clarify what constitutes a 'switch' in this context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives, prerequisites (e.g., does the switch need to exist first?), or side effects. The description lacks any conditional logic or workflow positioning.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, requiring the description to carry the full burden of behavioral disclosure. It fails to mention whether the operation is destructive, what happens if the variableId doesn't exist, or whether the change is persisted immediately. No side effects, error modes, or permission requirements are documented.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three words, but this represents under-specification rather than efficient conciseness. As noted in the calibration examples, extremely brief descriptions that merely restate the name fail to 'earn their place' by providing actionable information to the agent.
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?
Given zero schema coverage, no annotations, and no output schema, the description is inadequate for a 2-parameter mutation tool. It should at minimum clarify that variableId refers to an existing game variable and that this operation modifies metadata (the display name) rather than the variable's value.
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?
With 0% schema description coverage, the description must compensate by documenting both variableId (which variable to rename) and name (the new name). While 'variable name' loosely hints at the name parameter, it provides no explanation of variableId's role as an identifier, nor format constraints for either parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Set a variable name' is essentially a tautology that restates the tool name with spaces added. While it identifies the resource (variable name), it fails to distinguish from siblings like set_switch_name or clarify scope beyond what the function name already provides.
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?
No explicit guidelines are provided for when to use this tool versus alternatives (e.g., set_switch_name) or prerequisites (such as verifying the variable exists via get_variables). The description implies usage through the verb 'Set' but offers no actionable decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. While 'Update' implies mutation, the description lacks critical details: whether updates are partial or full replacement, what happens if the itemId doesn't exist, whether the operation is idempotent, or what properties are valid within the 'updates' object.
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 extremely brief at four words. While not verbose, it is under-specified rather than efficiently structured. In this case, greater length would be necessary to document the behavioral contract and parameter semantics that are currently missing.
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?
For an update operation with a schemaless 'updates' object parameter and no output schema or annotations, the description is inadequate. It must explain valid update fields, error conditions, and return value structure, none of which are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description completely fails to compensate. Neither parameter (itemId, updates) is explained. The description doesn't clarify that itemId expects a numeric identifier, nor what structure/keys are expected in the nested 'updates' object, leaving the caller to guess at valid property names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Update an item's properties' is essentially a tautology that restates the tool name (update_item) with minimal elaboration. While it identifies the resource type as 'item', it fails to distinguish from sibling update tools (update_actor, update_skill, etc.) or define what an 'item' represents in this game system context.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines are provided. There is no mention of prerequisites (e.g., whether the item must exist), when to prefer this over create_ methods, error handling behavior for invalid itemIds, or how to use the generic 'updates' object.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. 'Update' implies mutation but fails to specify if this is a partial update ( PATCH-like) or full replacement, whether omitted properties are preserved, or what the return value indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely brief (5 words), but this represents under-specification rather than efficient communication. Given the complexity (nested object parameter, mutation behavior), the length is inadequate and front-loads no useful constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Completely inadequate for tool complexity. Mutation operation with no annotations, no output schema, undocumented parameters, and a flexible 'updates' object requires detailed explanation of valid update paths, which is entirely absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage with 3 parameters including a nested 'updates' object. Description adds zero semantic value—fails to explain what valid properties exist within the updates object, what mapId/eventId reference, or expected data formats.
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?
States the verb (Update) and resource (map event's properties), providing basic clarity. However, it lacks specificity regarding which properties can be modified and does not differentiate from sibling tools like create_map_event or get_map_event.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides no guidance on when to use this tool versus alternatives (e.g., create_map_event for new events). No mention of prerequisites, idempotency, or side effects.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Create' implies a mutation operation, the description provides no details about side effects (what happens if coordinates x/y are already occupied), idempotency, whether the operation is reversible, or the structure/contents expected in the 'pages' array.
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 a single sentence of appropriate length, avoiding redundancy. However, it suffers from under-specification rather than true conciseness—every word earns its place, but there are too few words to adequately describe a 6-parameter tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool complexity (6 parameters with nested objects), game-specific domain terminology (events, pages), and complete absence of schema descriptions or output schema, the description is entirely inadequate. It fails to explain the domain model, parameter relationships, or return behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, requiring the description to compensate by explaining parameter semantics. The description mentions no parameters at all, leaving critical parameters like 'pages' (array type with unknown structure), 'note', and coordinate system (x/y) completely undocumented.
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 states a clear verb ('Create') and resource ('event on a map'), providing basic purpose identification. However, it fails to distinguish from sibling tools like 'create_map' (which creates the map itself) or clarify what constitutes an 'event' in this game development context, leaving ambiguity regarding the tool's specific scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description does not indicate when to use this tool versus alternatives like 'update_map_event' (for existing events) or 'add_event_command', nor does it mention prerequisites such as requiring an existing mapId.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but discloses no behavioral traits. It does not state whether this operation is destructive, what happens if the position parameter is excluded (likely appends to end), or the expected format of the command code integers.
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?
While not verbose, the single 6-word sentence is inappropriately brief for a tool with nested objects and zero schema documentation. It is front-loaded but underspecified for the complexity level.
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?
Given the high complexity (5 parameters, nested command object, mutation operation, no output schema), the description is grossly incomplete. It fails to explain the domain model (RPG Maker-style event commands), return values, or error conditions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate by explaining the 5 parameters, especially the nested 'command' object structure (code, indent, parameters) and the 'position' insertion point. It mentions none of these, leaving all parameters effectively undocumented.
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?
States the basic action (add) and target (command on event page), providing minimal viable clarity. However, it fails to differentiate from sibling 'update_map_event' or explain what constitutes a 'command' in this game development context.
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?
Provides no guidance on when to use this tool versus 'update_map_event' or 'create_map_event'. Does not mention prerequisites (e.g., requiring an existing event page) or insertion behavior when the optional 'position' parameter is omitted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of disclosure. While 'Get' implies a read-only operation, the description fails to specify what data structure is returned, whether this requires authentication, or if there are side effects. For a tool with zero parameters, this lack of behavioral context is a significant gap.
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 appropriately brief at three words, avoiding bloat. However, this brevity manifests as under-specification rather than efficient information density. The single sentence fails to earn its place by providing actionable detail.
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?
Given the simplicity (zero parameters) and lack of output schema, the description should at minimum explain what constitutes 'system data' in this API context (likely game system settings given the RPG Maker-like sibling tools). It provides no such context, leaving the agent uncertain about the tool's utility.
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?
The input schema has zero properties. According to the rubric, 0 parameters establishes a baseline score of 4. There are no parameters requiring semantic clarification beyond what the empty schema already conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get system data' is nearly tautological, restating the tool name with minimal elaboration. While it uses a specific verb ('Get'), it fails to define what 'system' refers to in this game development context (e.g., game configuration vs. system variables), nor does it differentiate from sibling 'get_' tools like get_actor or get_map.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance provided on when to use this tool versus alternatives. Given siblings like get_game_title, get_switches, and get_variables exist, the description should clarify what specific system-level data this retrieves that those other tools don't cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry full disclosure burden. It fails to mention that this is a destructive overwrite operation, whether the change is immediate, or what authentication/permissions are required.
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?
While the description is brief (4 words), it is too terse to be useful and represents under-specification rather than efficient communication. The single sentence exists but fails to earn its place by adding value beyond the tool name.
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?
For a mutation tool with no output schema and no annotations, the description provides insufficient context. It does not explain side effects, return values, or the nature of the state change being performed.
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 0%, and the description does not compensate by explaining the 'title' parameter (e.g., whether it is the new title, max length constraints, or formatting requirements).
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 states the basic action ('Update') and resource ('game title'), but it is extremely minimal and borders on restating the tool name. It lacks specificity about what aspect of the title is being updated or any scope limitations.
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?
No guidance provided on when to use this tool versus the read-only alternative (get_game_title), or any prerequisites for invoking this mutation operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure but reveals nothing about side effects, validation rules, idempotency, or return values. The term '(simplified)' hints at behavioral differences from other tools but provides no specifics.
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 extremely brief with zero redundancy. However, given the tool's complexity (5 parameters, no annotations, no output schema), it may be too concise to be 'appropriately sized' for the information burden required.
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?
For a creation tool with multiple parameters and no output schema or annotations, the description is inadequate. It lacks explanation of what the tool returns, what '(simplified)' implies, how it differs from create_skill, and any error conditions or side effects.
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% (all 5 parameters are documented with types and descriptions, including helpful examples for healFormula and scope values). Since the schema is self-documenting, the description adds no additional parameter semantics, warranting the baseline score of 3.
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?
The description clearly identifies the action ('Create') and resource type ('healing skill'), distinguishing it from sibling tools like create_damage_skill and create_buff_skill. However, the '(simplified)' qualifier is vague and unexplained, leaving ambiguity about its relationship to the generic create_skill tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidance is provided. The description fails to indicate when to use this tool versus the generic create_skill or other specialized skill creators, and mentions no prerequisites or constraints for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to indicate whether this is a cached read, expensive database lookup, or safe operation. It also omits what format the game title is returned in.
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 extremely concise at only four words with zero redundancy. While appropriately sized for a simple getter tool, it sacrifices necessary context that would have earned a higher score in other dimensions.
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 a parameter-less tool with no output schema, the description is minimally viable but contains clear gaps. It does not explain what the game title represents in the system, nor does it describe the return value format, which would be useful given the lack of output schema.
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?
The input schema contains zero parameters. According to the scoring guidelines, zero parameters establishes a baseline score of 4, as there are no parameter semantics to describe beyond what the empty schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get the game title' is a tautology that restates the tool name. While it technically uses a verb and resource, it fails to distinguish from the sibling tool update_game_title or clarify the scope of what 'game title' refers to (e.g., window title vs. internal project name).
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?
Provides no guidance on when to use this tool versus alternatives. It fails to mention the complementary update_game_title sibling or any prerequisites for retrieving the title.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure. It states nothing about the read-only/idempotent nature, what the return structure contains (tile data? events?), or error handling behavior for non-existent IDs.
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?
Extremely brief at five words with no redundancy. While efficient, it may be overly terse given the lack of annotations and output schema, leaving significant interpretive burden on the agent.
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?
Lacks output schema documentation, which is critical for understanding what 'map data' includes (e.g., tilesets, events, dimensions). Given the complex sibling ecosystem (30+ tools), the description inadequately clarifies this tool's specific niche.
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% for the single parameter, so the structured definition already documents 'mapId' adequately. The description adds no additional semantic context (e.g., where to obtain valid IDs, format constraints), warranting the baseline score.
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?
States the basic verb ('Get'), resource ('map data'), and lookup method ('by ID'), which is minimally sufficient. However, it fails to distinguish from siblings like `get_map_infos` (which likely returns metadata/lists) or clarify what constitutes 'map data' in this domain.
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?
Provides no guidance on when to use this versus `get_map_infos`, `get_map_events`, or `paint_map`. No mention of prerequisites (e.g., valid ID range) or error conditions (e.g., invalid mapId).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, placing full burden on the description. While 'Get' implies read-only behavior, the description does not disclose error behavior (e.g., what happens if the event ID is not found), authentication requirements, or idempotency.
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 single sentence contains no wasted words, but the description is underspecified for the complexity of the context. It lacks front-loaded critical information needed to differentiate from siblings and compensate for missing schema documentation.
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?
Given zero schema descriptions, no annotations, no output schema, and numerous sibling tools with similar names, the description provides insufficient context for an agent to confidently select and invoke this tool without additional trial and error.
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 0% for both parameters. The description provides minimal compensation: 'from a map' loosely implies mapId and 'specific event' implies eventId, but fails to define valid ID formats, ranges, or the hierarchical relationship between map and event.
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?
The description uses a specific verb ('Get') and resource ('event from a map') clearly identifying the operation. However, it fails to distinguish from sibling tool 'get_map_events' (plural), which likely returns a list versus this singular retrieval.
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?
No guidance provided on when to use this tool versus alternatives like 'get_map_events', 'search_map_events', or 'update_map_event'. The agent must infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description fails to disclose mutation behavior details: whether updates are partial (merging) or complete replacement, error handling for invalid actorIds, or whether the operation is idempotent. The term 'Update' implies mutation but lacks safety 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 a single, efficient sentence with no redundant words. However, given the complexity of nested object updates and mutation behavior, it is under-specified rather than optimally concise.
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?
For a mutation tool with nested object parameters and no output schema, the description is incomplete. It omits what properties are valid within the updates object, whether partial updates are supported, and what error conditions to expect.
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%, with both actorId and updates parameters adequately described in the schema. The description adds no additional parameter semantics, but the schema carries the load appropriately.
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 states the tool updates an actor's properties, which is clear but generic. It does not differentiate from sibling update tools (update_item, update_skill, etc.) or specify what constitutes 'properties' in this context.
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?
No guidance provided on when to use this versus create_actor (for new actors) or get_actor (to check current state). No mention of prerequisites like verifying actor existence before updating.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States 'Create' but omits critical mutation details: persistence model, ID generation, collision handling (duplicate names), or side effects. No disclosure of default values for optional parameters.
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?
Single sentence is efficient and front-loaded, though arguably undersized for an 11-parameter mutation tool with complex nested objects. No redundant information.
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?
With 100% schema coverage, basic parameter documentation is satisfied. However, lacks ecosystem context: doesn't explain relationship to stypeId system, damage formula syntax, or how created skills integrate with actors/items. No output schema compounds the gap.
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 has 100% description coverage with detailed examples (damage formulas, scope IDs), so baseline is 3. Description adds 'custom properties' which loosely maps to the flexible schema, but provides no additional syntax guidance, value ranges, or cross-parameter relationships beyond schema.
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?
States verb (Create) and resource (skill) clearly, but fails to distinguish from specialized siblings (create_damage_skill, create_healing_skill, etc.) that likely cover common use cases. 'Custom properties' is vague given the domain-specific parameters available.
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?
Provides no guidance on when to use this generic tool versus the specialized skill creators (create_buff_skill, create_state_skill, etc.). No mention of prerequisites, uniqueness constraints, or failure conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fails to disclose critical behavioral traits such as whether the search supports partial matching, case sensitivity, or what fields are searched. It also omits what the tool returns.
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 consists of a single efficient sentence with no redundant words, earning high marks for brevity. However, given the complete lack of schema documentation, this extreme conciseness results in under-specification.
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?
Considering the tool has two undocumented parameters (0% schema coverage), no annotations, and no output schema, the description fails to provide sufficient context regarding parameter usage or return behavior, leaving significant gaps in the agent's understanding.
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?
The schema has 0% description coverage. While the description implies that mapId refers to the map and searchTerm refers to the event name, it does not explicitly document parameter semantics, valid formats, or whether the search term requires exact matches.
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?
The description uses a specific verb 'Search' and identifies the resource as 'events on a map', specifying the search criterion 'by name'. It implicitly distinguishes from create_map_event and update_map_event, though it could better clarify when to use this versus get_map_events.
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?
The description provides no explicit guidance on when to prefer this tool over get_map_events or get_map_event, nor does it mention prerequisites such as requiring a valid mapId or the format of the searchTerm.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions '(simplified)' but fails to explain what is simplified—whether certain parameters are auto-generated, if this creates fewer database entries, or how it differs from the full create_skill tool. No mention of return values, side effects, or error conditions.
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 single sentence is efficiently structured with the verb front-loaded and zero redundancy. However, given the tool's complexity (6 parameters) and rich sibling context, it is inappropriately brief rather than appropriately concise.
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?
For a creation tool with 6 parameters, no output schema, and zero annotations, the description is incomplete. It fails to explain the return value, what 'simplified' entails, or how it relates to the 4 other skill creation siblings (create_skill, create_healing_skill, etc.).
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%, with clear documentation for scope values and damage formula syntax. The description adds no parameter-specific guidance, but the schema adequately documents semantics, making this the baseline score.
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?
The description states a clear verb ('Create') and resource ('damage-dealing skill'), and distinguishes from siblings like create_healing_skill or create_buff_skill. However, it underutilizes the '(simplified)' tag to explain how this differs from the generic create_skill sibling.
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?
No explicit guidance on when to use this versus create_skill or other skill creation tools. The '(simplified)' qualifier hints at a distinction but fails to specify the criteria for selection (e.g., 'use when you don't need animation or complex effects').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While 'Create' implies a write operation, the description omits whether this returns the created skill ID/object, whether it modifies existing data, or what 'simplified' implies about the creation behavior.
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?
Extremely concise single sentence with no redundant words. While brief to the point of under-specification, it efficiently conveys the core purpose without filler content.
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?
With 100% input schema coverage, the parameter documentation is adequately handled structurally. However, lacking an output schema and annotations, the description should ideally disclose return values or success indicators, which keeps it at minimum viable completeness rather than thorough.
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%, with all 6 parameters including 'buffType' and 'scope' enums documented in the schema. The description adds no additional parameter context, so it meets the baseline score for complete schema coverage.
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 action ('Create') and resource type ('buff skill'), distinguishing it from generic skill creation tools. However, the parenthetical '(simplified)' is unexplained and doesn't clarify when to use this versus siblings like 'create_skill' or 'create_damage_skill'.
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?
Provides no guidance on when to use this tool versus alternatives like 'create_skill' or 'create_state_skill'. No mention of prerequisites, constraints, or specific use cases that warrant the 'simplified' approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention that this is a mutating operation, whether it is idempotent, what the return value or success indicators are, or any side effects of skill creation.
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 extremely concise (6 words) and front-loaded with the action verb. However, given the tool's complexity (6 parameters, no annotations, no output schema), this brevity may be insufficient for agent decision-making.
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?
Despite having well-documented parameters, the description lacks necessary context given the absence of annotations and output schema. For a resource-creation tool, it should disclose what constitutes successful creation, any persistence guarantees, or error conditions.
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?
With 100% schema description coverage, the schema adequately documents all parameters (including helpful enum-like mappings for stateId and scope). The description adds no additional parameter semantics, but none are needed given the comprehensive schema documentation.
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?
The description clearly states the verb (Create) and resource (state-inflicting skill) with specific examples (poison, sleep) that distinguish it from sibling tools like create_damage_skill or create_healing_skill. However, it does not explicitly differentiate from the generic create_skill sibling.
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?
The description provides no explicit guidance on when to use this tool versus alternatives like create_skill (generic) or create_buff_skill. While the examples imply the domain (status effects), there are no when/when-not statements or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. 'Get' implies read-only, but description doesn't confirm safety, idempotency, or error behavior (null vs exception when actor missing). No mention of return structure.
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?
Extremely concise single sentence with no filler. However, given lack of annotations and output schema, slightly more content (error handling, sibling differentiation) would improve utility without violating conciseness.
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?
Adequate for a simple single-parameter read operation with full schema coverage. Gaps remain regarding error handling and output format given no output schema exists, but core invocation path is documented.
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 has 100% coverage with clear description of 'actorId'. Description adds no additional parameter context (e.g., ID format, valid ranges), but baseline 3 is appropriate given complete schema documentation.
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?
Clear verb ('Get'), resource ('actor'), and scope ('by ID'). Implicitly distinguishes from sibling 'get_actors' by specifying 'specific' and ID-based lookup, though it doesn't explicitly name sibling alternatives.
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?
No guidance on when to use this versus 'get_actors' (plural fetch) or 'search_actors' (filtered query). Missing guidance on error cases (e.g., invalid ID not found).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden but offers minimal behavioral context. While 'Get' implies read-only, there is no confirmation of safety, no mention of idempotency, error conditions (e.g., empty project), or pagination behavior for potentially large datasets.
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 single sentence is appropriately front-loaded and efficient with no wasted words. However, it is under-informative rather than optimally concise, lacking necessary context for the domain.
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?
Given the absence of an output schema and annotations, and the moderate complexity suggested by numerous siblings, the description is minimally adequate but has clear gaps. It fails to define the 'item' entity type or describe the return structure.
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?
The tool has zero parameters, which per evaluation rules establishes a baseline of 4. The description implies no filtering is needed (consistent with 'all items'), matching the empty input schema.
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 states the basic action (get) and resource (items) but lacks domain-specific clarity. Given siblings like get_weapons, get_armors, and search_items, it fails to specify that 'items' refers to a specific entity category (e.g., consumable items distinct from equipment) or distinguish its 'get all' scope from the filtering behavior of search_items.
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?
No guidance provided on when to use this versus search_items, nor any prerequisites or conditions. An agent cannot determine from the description alone whether to retrieve all items with this tool or search with the sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description fails to disclose whether this is idempotent, whether it returns deleted events, expected response size/performance implications for large maps, or the data format returned.
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 single sentence is efficiently structured with no redundant words. However, given the lack of annotations and schema descriptions, the extreme brevity leaves critical gaps that additional sentences should fill.
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?
Given the domain complexity implied by siblings (game development with actors, skills, states), the description inadequately explains what an 'event' represents in this context, what properties are returned, or how map events relate to the game systems. No output schema exists to compensate.
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?
With 0% schema description coverage, the description partially compensates by referencing 'a specific map,' giving semantic context to the 'mapId' parameter. However, it fails to explicitly document that 'mapId' is the required identifier parameter or describe its expected format/value range.
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?
The description uses a specific verb ('Get') and resource ('all events from a specific map'), clearly indicating this retrieves multiple events. The use of 'all' helpfully distinguishes this from the sibling tool 'get_map_event' (singular), though it doesn't explicitly contrast with 'search_map_events'.
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?
No guidance is provided on when to use this tool versus alternatives like 'get_map_event' (for single event retrieval) or 'search_map_events' (for filtered queries). No prerequisites or error conditions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. States read operation ('Get') but fails to disclose error behavior (404 vs null), response structure, or whether this retrieves from cache or database.
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?
Extremely concise at 6 words. Front-loaded with verb. No redundant text, though brevity comes at cost of missing behavioral context. Every word earns its place.
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?
Adequate for simple getter with 1 parameter, but gaps remain: no output schema exists, so description should hint at return structure or skill attributes. Domain context (game development) is implied by siblings but not stated.
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 has 100% coverage describing skillId, so baseline is 3. Description adds no additional parameter semantics (valid ID ranges, format, examples) but doesn't need to compensate given complete schema documentation.
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?
Clear verb (get) + resource (skill) + scope (specific by ID). Distinguishes from sibling get_skills (list) and search_skills (filtered query), though could clarify this is a game/RPG skill given context of create_damage_skill siblings.
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?
No explicit when-to-use guidance or comparison to alternatives. Lacks guidance on when to use search_skills vs get_skills vs get_skill, or error handling if ID doesn't exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It fails to disclose matching behavior (partial vs exact, case sensitivity), return format, pagination limits, or what happens when no matches are found. No mention of whether this is a read-only operation (implied by 'search' but not stated).
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?
Single sentence with zero redundancy. However, extreme brevity contributes to under-specification; with no annotations or schema descriptions, the description could accommodate more detail without violating conciseness principles.
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 a single-parameter search tool, it meets minimum viability by identifying the resource and search scope. However, lacks return value documentation (critical since no output schema exists) and behavioral constraints expected in a game development context (RPG Maker-like toolset).
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 has 0% description coverage. Description compensates partially by indicating searchTerm matches against both 'name' and 'description' fields, but lacks details on expected format, wildcards, or exact matching semantics.
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 specific action (Search) and resource (items) and searchable fields (name or description), which distinguishes it from sibling getters like get_items (likely by ID) and other search functions like search_actors or search_skills.
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?
Provides no guidance on when to use this versus get_items, update_item, or other item-related tools. No mention of prerequisites or when-not-to-use scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. While 'Update' implies mutation, the description fails to specify whether this performs a partial update (merging properties) or full replacement, what happens if the skillId doesn't exist, or whether the operation is idempotent.
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 single-sentence description is appropriately brief and front-loaded with the action verb. While minimal, it does not contain redundant or wasteful language—every word serves the purpose statement, even if underspecified for the tool's complexity.
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?
Given this is a mutation tool with nested object parameters and no output schema or annotations, the description is incomplete. It lacks critical operational context such as valid property names for the 'updates' object, error handling behavior, or return value structure that an agent would need to use the tool effectively.
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?
The input schema has 100% description coverage ('The skill ID to update', 'Properties to update'), establishing a baseline score of 3. The description mentions 'properties' which loosely aligns with the 'updates' parameter, but adds no additional semantic details, examples, or constraints beyond what the schema already provides.
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?
The description uses a clear verb ('Update') and identifies the target resource ('a skill's properties'), establishing the tool's function adequately. However, it lacks explicit differentiation from siblings like 'create_skill' or 'get_skill' that would help an agent understand this modifies existing resources versus creating new ones.
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?
The description provides no guidance on when to use this tool versus alternatives (e.g., 'create_skill' for new skills), nor does it mention prerequisites such as the skill needing to exist beforehand. There are no exclusions or conditional usage notes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full disclosure burden. While 'Get' implies read-only, the description does not explicitly confirm safety, disclose what specific map data is returned, or warn about potential performance implications of fetching 'all' maps.
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?
Extremely brief at five words. The description is front-loaded and efficient, though 'Get information' borders on restating the tool name. Appropriate length for a parameter-less tool, but trades specificity for brevity.
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?
Given zero input parameters but no output schema, the description should ideally specify what map attributes are returned (IDs, names, metadata?). Currently vague on return value structure. Adequate for tool selection but incomplete for invocation confidence.
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?
Input schema contains zero parameters. Per scoring rules, 0 params warrants a baseline score of 4. The description does not need to compensate for missing schema documentation.
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 clear verb (Get) and resource (information about all maps), distinguishing itself from sibling 'get_map' (singular) by specifying 'all maps'. However, 'information' remains somewhat vague about the specific data returned.
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?
Provides no guidance on when to use this versus sibling 'get_map' (which likely retrieves a single map) or versus 'search_map_events'. No prerequisites or exclusion criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. While 'Get' implies a read-only operation, the description fails to mention the return format, potential payload size concerns when retrieving 'all' actors, or whether the operation is safe/destructive.
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?
The description is a single, efficiently structured sentence of seven words with no redundant or wasted text. The key information (action, scope, resource, domain) is front-loaded.
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 a zero-parameter retrieval tool, the description is minimally adequate for selection purposes. However, given the lack of output schema and annotations, the absence of any description regarding what data fields constitute an 'actor' or the return structure leaves a noticeable gap.
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?
The tool has zero parameters and the schema coverage is 100% vacuously. Per the rubric, this establishes a baseline score of 4, as there are no parameter semantics to describe beyond what the empty schema already communicates.
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?
The description uses a specific verb 'Get' and resource 'actors' with clear scope 'all' and domain context 'RPG Maker MZ/MV project'. However, it does not explicitly differentiate from siblings like 'get_actor' (singular) or 'search_actors' (filtered) in the text itself, relying solely on naming conventions.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention that 'get_actor' retrieves a single actor, 'search_actors' allows filtering, or when to prefer this unfiltered retrieval over those options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full disclosure burden. It only states 'Get' implying read-only, but doesn't disclose return format, pagination behavior, or whether this includes all skill subtypes (buff/damage/healing/state) suggested by sibling tools. No mention of potential size/performance implications of unfiltered retrieval.
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?
Single sentence, six words, front-loaded with verb. Appropriate length for a zero-parameter list operation with no waste or redundancy.
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?
No output schema and no annotations increases burden on description. While 'Get all skills' covers basic intent, gaps remain: no distinction from sibling query tools, no indication of return structure, and ambiguity about whether 'skills' encompasses all subtypes (buff/damage/healing/state skills) shown in sibling tool names.
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?
Zero parameters exist, so baseline score applies per rubric. Schema coverage is 100% (empty object), requiring no additional parameter description in the description text.
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?
The description uses specific verb 'Get' and resource 'skills' and implies scope with 'all'. However, it doesn't explicitly distinguish from sibling 'get_skill' (singular lookup) or 'search_skills' (filtered queries), which would help clarify exact usage boundaries.
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?
No guidance provided on when to use this vs. 'get_skill' (single lookup) or 'search_skills' (filtered search). No mention of performance implications when retrieving all skills vs. using specific lookup alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. While 'Get' implies read-only behavior, the description fails to disclose return format, pagination behavior, or potential performance implications of retrieving 'all' weapons.
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?
Single sentence of six words with no redundant information. Purpose is front-loaded and immediately clear despite brevity.
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?
Adequate for a simple parameter-less getter, but lacks description of return structure despite absence of output schema. Should indicate what weapon properties are returned (e.g., name, damage, icon).
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?
Input schema contains zero parameters. Per scoring rules, zero-parameter tools receive a baseline score of 4 as there are no parameters requiring semantic clarification.
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 specific verb 'Get' and resource 'weapons', distinguishing from siblings like get_items, get_armors, and get_skills. 'From the project' provides context but remains slightly vague about the domain (game development).
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?
Provides no guidance on when to use this tool versus alternatives like get_items (which may return weapons as a subset) or search functions. No prerequisites or exclusion criteria mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavioral disclosure burden. It only mentions that the search covers 'name or nickname' fields, but fails to disclose matching behavior (partial vs exact, case sensitivity), result limits, or return format. For a read operation with no safety annotations, this is insufficient behavioral context.
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?
The description is a single six-word sentence with zero waste. It is immediately front-loaded with the action (Search) and target (actors). Every word earns its place in conveying the core purpose.
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 a single-parameter search tool with 100% schema coverage and no output schema, the description provides the essential functional context (what fields are searched). However, it lacks guidance on when to use this versus get_actor or get_actors, leaving a gap in contextual completeness for the agent's decision-making.
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?
With 100% schema coverage, the baseline is 3. The description adds valuable semantic context by specifying that the searchTerm applies to 'name or nickname' fields, helping the agent understand what data the parameter searches against beyond the generic schema description.
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?
Uses specific verb (Search) + resource (actors) + scope (by name or nickname). The inclusion of 'nickname' distinguishes this from a strict ID-based lookup (get_actor) and clarifies the searchable fields, though it does not explicitly contrast with get_actors or sibling search tools.
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?
Provides no guidance on when to use this tool versus alternatives like get_actor (likely ID-based) or get_actors (likely list all). No prerequisites, exclusions, or explicit alternative recommendations are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It indicates the tool searches across both name and description fields, but omits critical behavioral details: matching logic (substring vs. exact), case sensitivity, result limits, return format, and whether results include full objects or just IDs.
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?
The description is optimally concise at four words, front-loaded with the action verb 'Search', and contains no redundancy. Every word contributes essential information about the tool's function.
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 a single-parameter search tool without output schema, the description covers the basic purpose but leaves gaps. It should clarify the relationship with get_skills and indicate what the search returns (IDs, objects, or references) given the lack of output schema documentation.
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 the schema has 100% coverage with 'Search term', the description adds valuable semantic context that the term is matched against both name AND description fields. This clarifies the search scope beyond what the parameter description alone provides.
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?
The description clearly states the verb (Search), resource (skills), and scope (by name or description). It implicitly distinguishes from sibling get_skills by specifying the text-based search mechanism, though it doesn't explicitly name the alternative tool.
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?
The description provides no guidance on when to use this tool versus alternatives like get_skills (likely for ID-based retrieval) or search_actors/search_items. No prerequisites, exclusions, or decision criteria are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adequately states that the tool returns the new map ID and map data, but lacks details on side effects, error conditions (e.g., invalid dimension limits), or whether the creation is idempotent.
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?
The description consists of two efficient sentences with zero waste. The first states the action and inputs, the second states the return values—appropriately front-loaded and sized.
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?
While the description compensates for the missing output schema by stating what is returned, it fails to note that all 10 parameters are optional (0 required), which is critical context for an agent deciding whether to supply values. Given the rich schema, this omission keeps it from being fully complete.
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?
With 100% schema coverage, the baseline is 3. The description adds semantic value by grouping the 10 parameters into 'dimensions and properties,' providing conceptual organization beyond the raw schema definitions.
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?
The description uses a specific verb ('Create') and resource ('map') and mentions key attributes ('dimensions and properties'). However, it does not explicitly distinguish from the sibling tool 'create_map_event' which creates entities on maps rather than the map container itself.
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?
No guidance is provided on when to use this tool versus alternatives like 'paint_map' (which modifies existing maps) or 'get_map' (for reading). There is no mention of prerequisites, such as requiring a valid tilesetId to be available.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It correctly establishes the broad scope ('all armors') implying no filtering capability, but fails to disclose return format, pagination behavior, or performance implications of retrieving unbounded collections.
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?
Single sentence with no redundancy. Every word earns its place by stating operation, resource, and scope. Front-loaded and appropriately sized for tool complexity.
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?
Minimal but viable for a zero-parameter read operation. Lacks return value documentation (no output schema exists to compensate), and does not clarify armor categorization relative to items/weapons siblings. Adequate for invocation but leaves operational context gaps.
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?
Zero parameters present; description baseline is 4. The phrase 'Get all' appropriately reinforces the schema's lack of filter parameters, confirming no user input is expected for scoping.
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?
Clear verb (Get), resource (armors), and scope (all, from the project). However, lacks explicit differentiation from siblings like get_items or get_weapons which may represent overlapping categories in game data.
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?
No guidance provided on when to use this versus search/filter alternatives (e.g., if a user wants specific armors) or prerequisites. The description states what it does but not when to prefer it over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. 'Get' implies a read-only operation, but the description does not explicitly confirm safety, idempotency, or what format the switch names are returned in (array, object, comma-separated string). It meets the minimum viable threshold but lacks rich behavioral context.
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?
The description is extremely efficient at 5 words, front-loaded with the action and target resource. Every word earns its place with no redundancy or filler content.
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?
Given the tool's simplicity (zero parameters) and lack of output schema, the description adequately conveys the basic operation but fails to specify the return structure (e.g., 'returns an array of switch name strings'). For a retrieval tool without output schema documentation, this gap leaves the agent uncertain about result parsing.
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?
The input schema contains zero parameters, which per evaluation rules establishes a baseline score of 4. There are no parameters requiring semantic clarification beyond what the schema (empty object) already provides.
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?
The description states a clear verb ('Get') and resource ('game switch names'), effectively distinguishing this from sibling 'set_switch_name' via the get/set contrast and from 'get_variables' by specifying 'switch' rather than 'variable'. However, it stops short of explicitly contrasting with siblings or clarifying scope (e.g., 'all' implies no filtering, which is useful but could be explicit).
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?
The description provides no guidance on when to use this tool versus alternatives like 'set_switch_name' or 'get_variables', nor does it mention prerequisites (e.g., needing to know switch names before setting them). The agent must infer usage from the naming contrast alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It adds valuable behavioral context by specifying 'names' (indicating it returns identifiers rather than values or objects) and 'all' (indicating no filtering). However, it omits return format, pagination behavior, and error conditions.
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?
The description is a single, four-word sentence that is appropriately front-loaded with the action. For a zero-parameter getter tool, this length is optimal with no wasted words.
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?
Given the low complexity (no parameters, simple read operation) and lack of output schema, the description is minimally viable. It adequately explains the operation but should ideally describe the return structure (e.g., array vs object) since no output schema is available to document it.
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?
The input schema contains zero parameters. According to the scoring rubric, this establishes a baseline of 4. The description appropriately does not invent parameter semantics where none exist.
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?
The description clearly states the verb ('Get') and resource ('game variable names') with scope ('all'). However, 'Get' is slightly less specific than 'List' or 'Retrieve', and while the resource distinguishes it from siblings like get_switches, it doesn't explicitly clarify the relationship to set_variable_name.
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?
The description provides no guidance on when to use this tool versus alternatives such as get_switches or set_variable_name. It lacks prerequisites (e.g., whether a game must be loaded first) and exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses write operation ('Reads/writes map data') and atomicity/performance trait ('only once regardless of operation count'). Without annotations, description carries full burden but omits error handling, partial failure behavior, permission requirements, and return value details expected for mutation tools.
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 with zero waste: defines operation, states use cases, explains performance characteristic. Appropriately sized and front-loaded for the complexity level.
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?
Adequate for the tool's purpose but gaps remain: no output schema exists yet description omits return behavior, success indicators, or error handling for the complex nested input structure. Complex mutation tools warrant more behavioral disclosure.
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%, establishing baseline 3. Description adds domain context ('fill rectangles or draw outlines') bridging to the 'type' enum values, but does not supplement parameter syntax, validation constraints, or tileId value semantics beyond the schema's documentation.
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?
Clear specific verb ('Paint') + resource ('tiles on a map') + method ('batch operations'). Explicitly distinguishes from siblings like create_map (makes new maps) or update_map_event (modifies events) by focusing on tile painting operations.
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 clear use cases ('terrain, roads, walls, decorations') and efficiency guidance ('in one call'). Lacks explicit 'when not to use' guidance or comparison to individual tile update alternatives, though batch efficiency implies appropriate usage patterns.
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:

[![RPG-MakerMV-MCP MCP server](https://glama.ai/mcp/servers/garuh143/RPG-MakerMV-MCP/badges/card.svg)](https://glama.ai/mcp/servers/garuh143/RPG-MakerMV-MCP)

Score Badge

Copy to your README.md:

[![RPG-MakerMV-MCP MCP server](https://glama.ai/mcp/servers/garuh143/RPG-MakerMV-MCP/badges/score.svg)](https://glama.ai/mcp/servers/garuh143/RPG-MakerMV-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/garuh143/RPG-MakerMV-MCP'

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