Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@RPG Maker MZ MCP Server create a fire sword that deals 20 fire damage and costs 150 gold"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A powerful Model Context Protocol (MCP) server that allows AI agents (like Claude, Gemini, or Copilot) to directly manipulate RPG Maker MZ projects.
With this tool, you can ask your AI to "Create a fire sword", "Make a potion that regenerates mana", or "Generate a new map", and it will modify the game files directly!
Create, Read, and Update almost any database asset:
Items: Create potions, keys, and hidden items. Support for HP/MP recovery and state application.
Weapons & Armors: Create equipment with stats, prices, and elemental effects.
Enemies: Define stats (HP/MP/ATK...), drops, and rewards (EXP/Gold).
States: Create status effects (e.g., Poison, Regen, Stun) with traits.
Actors & Classes: Create new heroes and classes with level curves and traits.
Skills: Define magic and special attacks.
Create Maps: Generate new map files (MapXXX.json) with metadata (size, tileset, BGM).
List Maps: See all maps in your project hierarchy.
Plugin Installer: Automatically creates .js files in js/plugins and registers them in plugins.js.
Resource Scanner: List available graphics (img/), audio (audio/), and DLC packages.
Atomic Writes: Uses a SafeWriter to prevent data corruption.
Editor Sync: Automatically updates System.json version ID, forcing the RPG Maker MZ editor to reload data and preventing conflicts.
Related MCP server: RPG Maker MZ MCP Server
Clone the repository:
git clone https://github.com/devmagary/MCP-Maker.git
cd MCP-MakerInstall dependencies:
npm installBuild the project:
npm run buildYou need to tell the MCP client where your RPG Maker MZ project and engine are located.
RPGMAKER_PROJECT_PATH: Full path to your game project (where game.rmmzproject is).
RPGMAKER_ENGINE_PATH: Full path to RPG Maker MZ installation (usually Steam folder).
Add to your settings or MCP config:
{
"mcpServers": {
"rpgmaker-mz": {
"command": "node",
"args": ["C:/path/to/MCP-Maker/dist/index.js"],
"env": {
"RPGMAKER_PROJECT_PATH": "C:/Users/You/Documents/RMMZ/MyGame",
"RPGMAKER_ENGINE_PATH": "C:/Program Files (x86)/Steam/steamapps/common/RPG Maker MZ"
}
}
}
}Edit %APPDATA%\Claude\claude_desktop_config.json:
{
"mcpServers": {
"rpgmaker-mz": {
"command": "node",
"args": ["C:\\path\\to\\MCP-Maker\\dist\\index.js"],
"env": {
"RPGMAKER_PROJECT_PATH": "C:\\Users\\You\\Documents\\RMMZ\\MyGame",
"RPGMAKER_ENGINE_PATH": "C:\\Program Files (x86)\\Steam\\steamapps\\common\\RPG Maker MZ"
}
}
}
}TypeScript: Strictly typed for robustness.
Zod: Runtime schema validation for all tool inputs.
MCP SDK: Official Model Context Protocol SDK.
Node.js: Runtime environment.
Feel free to open issues or submit PRs if you want to add more features (e.g., Event creation support)!
Created with ❤️ by DevMagary & Antigravity.
Create a new actor in the database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Actor name | |
| nickname | No | Actor nickname | |
| classId | No | Class ID | |
| initialLevel | No | Initial level | |
| maxLevel | No | Max level | |
| profile | No | Profile description | |
| characterName | No | Character sprite name | |
| characterIndex | No | Character sprite index | |
| faceName | No | Face image name | |
| faceIndex | No | Face image index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as side effects, error conditions, or whether the operation is destructive. It merely states the create action without additional context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence that immediately conveys the tool's purpose. It is appropriately front-loaded and contains no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters and no annotations or output schema, the description is insufficient. It lacks details about return values, error handling, constraints, or expected behavior, making it incomplete for a complex creation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the description does not need to add parameter details. However, it adds no extra meaning beyond the schema's basic descriptions, which are already present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and the resource (new actor), distinguishing it from sibling tools like update_actor or get_actors. It is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. It does not mention prerequisites, uniqueness constraints, or context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new armor in the database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Armor name | |
| description | Yes | Armor description | |
| price | Yes | Armor price | |
| atypeId | No | Armor type ID (1=General, 2=Magic, 3=Heavy, etc.) | |
| etypeId | No | Equip type ID (2=Shield, 3=Head, 4=Body, 5=Accessory) | |
| def | No | Defense (DEF) | |
| mdf | No | Magic Defense (MDF) | |
| agi | No | Agility (AGI) | |
| iconIndex | No | Icon index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states 'Create a new armor in the database', which implies an insert operation. It does not disclose side effects, return values, or authorization needs. For a mutation tool without annotations, this is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no redundant information. Every word earns its place, making it highly concise and efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, no output schema, and no annotations, the description falls short. It does not explain what the tool returns (e.g., the created armor object), nor does it cover behavioral constraints like validation rules beyond the schema. A create operation typically needs return value context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional parameter meaning beyond what the input schema already provides. Parameters like 'atypeId' and 'etypeId' have default explanations in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new armor in the database' clearly states the verb 'create' and the resource 'armor', making it distinct from sibling create tools like create_weapon or create_item. It directly answers 'what does this tool do?' with specificity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit usage guidelines or alternatives are provided. However, as a create tool, its usage is implied when the goal is to insert a new armor record. Lacks when-not clauses or comparisons to siblings like create_item.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new class in the database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Class name | |
| expBase | No | EXP Base (Curve) | |
| expAccel | No | EXP Acceleration (Curve) | |
| maxHp | No | Base Max HP at Level 1 | |
| maxMp | No | Base Max MP at Level 1 | |
| atk | No | Base ATK at Level 1 | |
| def | No | Base DEF at Level 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states a generic 'Create' operation without mentioning side effects, permission requirements, or behavior if the class already exists. This is insufficient for safe invocation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no unnecessary words. It efficiently communicates the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal and lacks information about return values or database constraints. While the parameters are self-explanatory, agents may need context on what the tool returns or how it interacts with the database.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All 7 parameters are described in the schema (100% coverage). The description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new class in the database' clearly specifies the verb 'Create' and the resource 'class'. Among sibling tools with 'create_' prefix, this distinguishes itself by target resource (class vs actor, armor, etc.), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 over alternatives, such as update_class, or any prerequisites. The description does not mention context, constraints, or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new enemy in the database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Enemy name | |
| maxHp | No | Max HP | |
| maxMp | No | Max MP | |
| atk | No | Attack (ATK) | |
| def | No | Defense (DEF) | |
| mat | No | Magic Attack (MAT) | |
| mdf | No | Magic Defense (MDF) | |
| agi | No | Agility (AGI) | |
| luk | No | Luck (LUK) | |
| exp | No | Experience reward | |
| gold | No | Gold reward | |
| battlerName | No | Battler image name | |
| battlerHue | No | Battler hue (0-360) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It only states 'create' without mentioning side effects, authentication needs, rate limits, or what happens on duplication.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence but lacks important detail. It is not tautological, but it is under-specified given the tool's complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 13 parameters and no output schema or annotations, the description provides no information about return values, error conditions, or constraints. It is incomplete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; all parameters are already well-documented in the input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Create a new enemy in the database' clearly states the action and resource. However, it does not differentiate from sibling tools like update_enemy or other create_* tools, though the name implies the resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as update_enemy or other create tools. There is no mention of prerequisites or ideal use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new item in the database with HP and/or MP recovery
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Item name | |
| description | Yes | Item description | |
| price | Yes | Item price | |
| type | No | Item type | regular |
| hpRecoveryPercent | No | HP recovery percentage (0-100) | |
| hpRecoveryFixed | No | HP recovery fixed amount | |
| mpRecoveryPercent | No | MP recovery percentage (0-100) | |
| mpRecoveryFixed | No | MP recovery fixed amount | |
| addStateId | No | State ID to add (e.g., for buffs/regen) | |
| iconIndex | No | Icon index from IconSet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It fails to disclose behavioral traits like irreversibility, duplicate handling, immediate database update, or any success/failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. It could be slightly more informative without losing conciseness, but it is not overly verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the high complexity (10 parameters, no output schema), the description is insufficient. It does not explain return values, error handling, or any constraints beyond creation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond what is already in the schema (e.g., 'HP and/or MP recovery' is captured by hpRecoveryPercent etc.).
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (item in database) and highlights a key feature (HP/MP recovery). However, it does not distinguish this from sibling create tools like create_skill or create_armor, which also create database entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as create_armor or create_skill. With many sibling create tools, explicit usage context would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new map in the project
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Map name (shown in editor) | |
| displayName | No | Display name (shown in game) | |
| width | No | Map width in tiles | |
| height | No | Map height in tiles | |
| tilesetId | No | Tileset ID to use | |
| scrollType | No | Scroll type: 0=NoLoop, 1=Vertical, 2=Horizontal, 3=Both | |
| encounterSteps | No | Average steps between encounters | |
| parentId | No | Parent map ID for hierarchy |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but it only states 'Create a new map'. It does not indicate consequences of duplicate names, required permissions, side effects, or response details. The minimal description leaves agents to infer from the name alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficiently conveys the core purpose. Every aspect of the description earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, no output schema), the description is incomplete. It does not explain return values, error conditions, or operational behavior beyond creation. The agent lacks critical context for effective invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The tool description adds no parameter-specific information beyond the schema. Each parameter is already well-documented in the input schema with descriptions, defaults, and constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create a new map in the project', which specifies the action and resource. It distinguishes the tool from siblings like get_maps (read) and update_map (modify). However, it does not provide any additional context about the map's role or project scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description offers no guidance on when to use this tool versus alternatives. It does not mention that update_map should be used for modifications, or that get_maps should be used for retrieval. No usage context or exclusions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new skill in the database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Skill name | |
| description | Yes | Skill description | |
| mpCost | No | MP cost | |
| tpCost | No | TP cost | |
| iconIndex | No | Icon index | |
| scope | No | Skill scope | |
| damageType | No | Damage type | |
| damageFormula | No | Damage formula | a.atk * 4 - b.def * 2 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states 'Create a new skill' without mentioning side effects, authentication needs, failure modes, or constraints. This is insufficient for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, front-loaded and concise. However, given the tool's complexity, slightly more detail could be useful without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high schema coverage, the description lacks completeness regarding return values, error handling, and overall behavioral context. A creation tool with 8 parameters and no output schema needs more contextual information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description does not add any additional meaning beyond the schema's parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Create' and the resource 'skill', distinguishing it from sibling create_* tools. It is specific and not a tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 update_skill or other creation tools. No prerequisites, limitations, or context are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new state (status effect) in the database
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | State name | |
| iconIndex | No | Icon index | |
| restriction | No | Restriction: 0=None, 1=Attack Enemy, 2=Attack Anyone, 3=Attack Ally, 4=Cannot Move | |
| priority | No | Priority (0-100) | |
| minTurns | No | Minimum turns | |
| maxTurns | No | Maximum turns | |
| autoRemovalTiming | No | Auto removal: 0=None, 1=Action End, 2=Turn End | |
| chanceByDamage | No | Chance to remove by damage % | |
| removeAtBattleEnd | No | Remove at battle end | |
| regenerateMpRate | No | MP Regeneration Rate % (negative for damage) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'in the database' but lacks details on side effects, permissions, or constraints like maximum states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence that is concise and front-loaded. Every word serves the purpose. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 10 parameters, no output schema, and no annotations, the description is incomplete. It does not mention return value, error states, or typical usage patterns.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the baseline is 3. The description adds no additional meaning beyond the schema; it does not explain parameter roles or combinations.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'create', the resource 'state', and clarifies 'status effect' in parentheses. It distinguishes from sibling tools like create_actor or create_skill.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like update_state. The description does not mention prerequisites, context, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new weapon in the database with attack power and optional element
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Weapon name | |
| description | Yes | Weapon description | |
| price | Yes | Weapon price | |
| wtypeId | No | Weapon type ID (1=Dagger, 2=Sword, 3=Flail, etc.) | |
| attack | No | Attack power (ATK bonus) | |
| elementId | No | Element ID (1=Physical, 2=Fire, 3=Ice, 4=Thunder, etc.) | |
| iconIndex | No | Icon index from IconSet | |
| animationId | No | Attack animation ID |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only states the operation is a creation, but does not mention return value, error cases, side effects, or any constraints. The agent has no information on whether creation is idempotent, what happens on duplicate name, etc.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with no superfluous words. It immediately states the tool's purpose and key attributes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description lacks context for a tool with 8 parameters and no output schema. It does not mention that it returns the created weapon, what the defaults are, or any behavior upon success/failure. The tool's complexity demands more explanatory context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description mentions two parameters ('attack power' and 'optional element') but does not add any additional semantics beyond what is already in the schema descriptions. No clarification of defaults, relationships, or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (create) and resource (weapon) with specific attributes (attack power, optional element). It distinguishes from sibling create tools for other entities and from update_weapon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No usage guidelines provided. The description does not indicate when to use this tool over alternative create tools or update_weapon. No context about prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all actors from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description implies a read-only operation but does not disclose pagination, return fields, or constraints. For a simple list-all tool with no parameters, it is minimally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, front-loaded, no extraneous information. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter, no-output-schema tool, the description is adequate. However, it lacks mention of any limitations or behavioral nuances. Given simplicity, it's nearly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so schema coverage is 100% vacuously. The description adds no parameter details, which is acceptable since there are none. Baseline for zero parameters is 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all actors from the database', specifying the verb and resource. It distinguishes from siblings which are for other resources or create/update operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like create_actor or update_actor. No context on filtering or limitations provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all armors from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as performance, filtering, pagination, or output structure. The agent has no insight into side effects or resource usage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence, front-loading the purpose. However, it could be slightly more informative without losing conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple GET-all tool with no parameters, the description is adequate but lacks details about return format, limits, or edge cases. With no output schema, the agent might not know what data it receives.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, and schema description coverage is 100%. The description adds no extra meaning, but nothing is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves all armors from the database, distinguishing it from sibling tools like get_actors or get_weapons.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_items or get_weapons. No mention of exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all classes from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description implies a safe read operation, but with no annotations, it does not disclose potential side effects, data volume, or limitations. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence with no wasted words. Concise and direct.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple no-parameter, no-output-schema tool, the description provides enough context to understand its purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist, so description adds no param information. Baseline 4 for 0 parameters, but description does not add value beyond schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states verb 'get' and resource 'all classes from the database'. It differentiates from sibling tools like create_class and update_class by indicating a read operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as get_database_info or other get_* tools. Description lacks context on appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available core script versions
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not mention any behavioral traits such as authentication requirements, rate limits, or side effects. As a read-only operation, the description should at least confirm non-destructive behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (4 words) and front-loaded. Every word is necessary and contributes to understanding the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Without an output schema, the description should explain the return value structure. It only states 'list available core script versions' without specifying the format or what a version entry contains. Incomplete for a tool with no output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, and the schema coverage is 100%. Per rule, with 0 parameters, baseline score is 4. The description does not need to add parameter info.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists available core script versions. However, it does not differentiate from sibling list tools like get_actors or get_armors, leaving ambiguity about what 'core script versions' specifically refers to.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description provides no context about typical use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a summary of all database contents (actors, classes, items, skills, weapons, armors counts)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the burden of behavioral disclosure. The description only states what the tool does, not how it behaves (e.g., read-only, performance, side effects). No contradictions, but insufficient transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that efficiently conveys the tool's purpose. No redundant or unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While simple, the tool has no output schema and no annotations. The description provides the key information (summary with counts), but lacks details on the output format or additional context that could aid an agent. Adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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%. The description does not need to add parameter semantics. Baseline 4 is appropriate as the schema is complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it returns a summary of database contents with specific entity counts (actors, classes, etc.). It unambiguously identifies the tool's purpose and differentiates it from sibling tools that target individual entities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for overview before detailed operations, but provides no explicit when-to-use or when-not-to-use guidance. No alternatives are mentioned, though sibling tools exist for specific entities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current maximum limits for all databases
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description solely states it 'gets' limits, but fails to disclose any behavioral traits like authentication, rate limits, or error behavior. For a simple read tool, the minimal transparency leaves the agent uninformed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence of 7 words with no unnecessary information. It earns its place by efficiently conveying the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema) and a straightforward read operation, the description is complete enough for basic use. However, it lacks details about the return value or structure, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the input schema is empty with 100% coverage. According to the rubric, a baseline of 4 applies when there are no parameters, and the description does not need to add parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'get' and the resource 'current maximum limits for all databases', making the tool's purpose unambiguous. It distinguishes itself from siblings like 'set_database_limit' and 'get_database_info' by specifying a different action and resource scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives such as 'get_database_info' or 'set_database_limit'. The agent receives no context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all enemies from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the action without disclosing behavioral traits like pagination, sorting, or side effects. The tool is likely read-only, but this is 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no filler words, directly states the purpose. Optimal length for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, the description could hint at the structure of returned enemies. For a simple tool, it is minimally adequate but lacks detail on what constitutes an 'enemy' or any filtering capabilities.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, so schema coverage is 100%. The description does not need to add parameter information, and the baseline for 0 parameters is 4. No additional details are required.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (Get) and resource (all enemies from the database). It distinguishes from sibling get tools by specifying the resource, but lacks context about the application domain (e.g., RPG Maker).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like get_actors or get_armors. The description is minimal and does not provide any usage context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available character generator parts
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It implies a read-only operation but does not disclose any behavioral traits such as authentication requirements, side effects, or performance characteristics. Minimal but non-contradictory.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded and efficiently communicates the tool's purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description should clarify return value details. It does not specify whether the output is a list of names, IDs, or other data. For a simple list operation, this omission is moderate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no parameters, and schema description coverage is 100% empty. Per guidelines, zero parameters yields a baseline of 4. The description adds no parameter information, but none is needed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'List available character generator parts' clearly specifies the verb (List) and resource (character generator parts). Among siblings with many get_* tools, this distinguishes itself by naming a specific resource not covered by other tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool or when to prefer alternatives. For a simple list tool with no parameters, the lack of context is acceptable but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all installed plugins with their registration status
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action without disclosing behavioral traits like side effects, authorization needs, or rate limits. It does not explain what 'registration status' entails or confirm that it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words. Every word provides value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and outputs a simple list of installed plugins with registration status, the description is sufficiently complete. An output schema or more detail on the return format would be beneficial but is not critical for this simple tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters with 100% coverage, so the description needs to add nothing. The baseline for zero parameters is 4, and the description meets that without redundancy.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all installed plugins with their registration status', specifying the verb and resource. It distinguishes easily from sibling tools like install_plugin, create_actor, etc., which are write operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly indicates usage (to retrieve all installed plugins) but provides no explicit guidance on when not to use it, alternatives, or context relative to siblings like scan_dlc_packages.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all items from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states it 'gets all items'. It does not disclose if the operation is read-only, if there are side effects, pagination behavior, or performance implications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It effectively communicates the core purpose without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters and no output schema, the description provides the basic purpose. However, it lacks details about the return format, authorization needs, or any limitations, which could be useful for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the input schema is fully covered. The description adds no parameter-level information, but no additional meaning is needed beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 'items', indicating a read operation. However, it does not differentiate 'items' from other resources like actors or armors, which are also retrieved via similar sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_actors or get_weapons. There is no mention of prerequisites, filters, or scenarios where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all maps from the project
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'Get all maps from the project' without disclosing read-only nature, potential side effects, or other behavioral traits. The lack of explicit safety information is a gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is concise and front-loaded. It states the purpose without extra words, earning its place. Slightly more structure could be beneficial, but it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters and no output schema, the description is minimal. It tells what the tool does but does not describe the return format or any pagination/limitations. For a simple list tool, this is adequate but could be more complete regarding output expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description does not need to add parameter meaning. Baseline for 0-parameter tools is 4, and the description adequately indicates what the tool does without param details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Get all maps from the project', which is a specific verb+resource. Among siblings, there are other 'get_*' tools for different entities, so it clearly distinguishes what this tool retrieves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for listing all maps, but does not provide explicit when-to-use or when-not-to-use guidance. There is no mention of alternatives like get_sample_maps, though context suggests they exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available sample maps from the engine
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the action ('List available sample maps') without disclosing behavioral traits such as read-only nature, performance implications, or side effects. The description adds no behavioral context beyond the purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that is front-loaded and contains no unnecessary words. It is appropriately sized for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and no output schema, the description is minimal. It does not explain what constitutes a 'sample map' or what the output format is. While functional, it leaves room for ambiguity about the tool's purpose and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, making schema coverage 100%. The description is simple and adequate; no additional parameter details are needed. Baseline score of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('available sample maps'), clearly indicating what the tool does. It is distinct from sibling tools like get_maps (lists user maps) and create_map (creates maps).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives like get_maps. The description does not specify whether sample maps are different from regular maps or how they relate to other listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all skills from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as read-only nature (implied), potential pagination, database limits, or performance impact. Minimal transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, highly concise. Could mention if return structure is simple or list, but overall efficient for a straightforward tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema or annotations. For a simple list tool, description is adequate but lacks details on return format, ordering, or filtering possibilities. Completeness is acceptable but not enhanced.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters, schema coverage 100%. Description adds context by specifying 'all skills', confirming full retrieval. Baseline for 0 params is met and slightly enhanced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description states 'Get all skills from the database' with clear verb and resource. Distinguishes from sibling get_* tools (e.g., get_actors, get_weapons) by targeting skills specifically.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this vs. other tools like create_skill or update_skill. Implied usage is for reading skills, but lacks explicit context or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all states from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It only states 'get all states' without disclosing any behavioral traits such as read-only nature, authentication needs, rate limits, or response format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no wasted words. It is front-loaded with the action and resource, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, no output schema, and no annotations, the description is adequate but lacks completeness. It does not specify the format of the returned states (e.g., IDs or full objects), which would help an agent use the output correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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% (empty). The description adds no param-specific meaning, which is acceptable for a parameterless tool. Baseline 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get all states from the database', specifying the verb (get), resource (states), and scope (all). It differentiates from sibling tools like create_state and update_state, as well as other get_* tools for different resources.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. The purpose implies it's for reading all states, but there is no mention of exclusions or alternative tools for filtered queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all weapons from the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It states it's a read operation but does not mention pagination, cost, or any side effects, which is inadequate for a tool with no output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no unnecessary words, making it highly concise and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too minimal. It fails to mention return format, potential limitations, or any context about the 'all weapons' scope.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the description has nothing to add. Baseline for 0 parameters is 4, and the description does not need to explain absent parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Get all weapons from the database' clearly states the action (get) and the resource (all weapons), distinguishing it from sibling tools like create_weapon or update_weapon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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_actors or get_items, nor are any exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Install a new plugin and register it in plugins.js
| Name | Required | Description | Default |
|---|---|---|---|
| filename | Yes | Plugin filename without .js extension | |
| code | Yes | Plugin JavaScript code | |
| description | Yes | Plugin description | |
| author | Yes | Plugin author |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'install and register'. It omits critical behavioral traits such as whether it overwrites existing plugins, requires validation, or has irreversible side effects. This is insufficient for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one short sentence, which is concise but under-specified. It provides the minimal purpose but lacks necessary details, making it less than optimally helpful.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 4 required parameters and no output schema or annotations, the description should explain expected behavior, errors, or return values. It does not, leaving the tool's full context incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The tool description adds no additional meaning beyond what the schema already provides, so baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action 'Install a new plugin' and the side effect 'register it in plugins.js'. It uses a specific verb+resource, and given the sibling tools list includes no other plugin installation tool, it effectively distinguishes itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 vs alternatives, nor are there any prerequisites or exclusions mentioned. The description simply states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all DLC packages in the engine folder
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states 'list', implying read-only. No details on side effects, cost, or return format are provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One simple sentence, front-loaded, no extra words. Perfectly concise for the tool's simplicity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no parameters, the description is adequate but could mention return type (e.g., array of package names). 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.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameters exist; schema coverage is 100%. Description adds nothing beyond schema, but baseline is 4 for zero-param tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (list), resource (DLC packages), and location (engine folder). It is specific and distinguishes from similar tools like 'scan_resources'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs. alternatives (e.g., scan_resources). No exclusions or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Scan available resources from project and/or engine
| Name | Required | Description | Default |
|---|---|---|---|
| category | Yes | Resource category to scan | |
| source | No | Source to scan | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description only says 'scan' without disclosing side effects, return format, or safety. Insufficient for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no unnecessary words, front-loaded with essential action and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Missing output schema; description does not hint at return type or structure. For a simple tool, it is moderately complete but lacks output context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already explains parameters. Description adds 'from project and/or engine' but does not significantly augment schema meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it scans available resources, with specific sources (project and/or engine). It distinguishes from sibling tools like scan_dlc_packages.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for discovering resources but lacks explicit when-to-use, when-not-to-use, or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set the maximum limit for a database (expands or shrinks the array)
| Name | Required | Description | Default |
|---|---|---|---|
| database | Yes | Database to resize | |
| limit | Yes | New maximum limit |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden but only says 'expands or shrinks the array,' which is thin. It does not disclose permissions, side effects, or what happens on failure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, precise sentence with no unnecessary words, and the key information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is adequate for this simple tool but could be improved by mentioning that the database must exist and that the limit is subject to schema constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with clear parameter descriptions. The description adds 'expands or shrinks the array' but does not significantly enhance understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('set'), the resource ('maximum limit for a database'), and provides additional context ('expands or shrinks the array'), distinguishing it from read-only siblings like get_database_limits.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for resizing a database but does not explicitly state when to use it versus alternatives or provide any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing actor's properties
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Actor ID to update | |
| name | No | ||
| nickname | No | ||
| classId | No | ||
| initialLevel | No | ||
| maxLevel | No | ||
| profile | No | ||
| characterName | No | ||
| faceName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description merely says 'Update,' which implies modification, but lacks details on behavioral traits (e.g., whether partial updates are allowed, what happens to missing fields, or if the operation is irreversible).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise, but it is too brief to be informative. It does not front-load critical details about the tool's functionality.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema and only a minimal description, the tool lacks completeness. For a 9-parameter update tool, the description should provide context on update behavior, parameter constraints, or expected outcomes.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 11% (only the 'id' parameter has a description). The tool description adds no additional meaning beyond the schema, failing to explain the purpose of the other 8 parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Update an existing actor's properties,' using a specific verb and resource. It distinguishes itself from sibling tools like create_actor and get_actors by implying modification of an existing entity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives (e.g., create_actor for new actors). The description does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing armor's properties
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Armor ID to update | |
| name | No | ||
| description | No | ||
| price | No | ||
| def | No | ||
| mdf | No | ||
| iconIndex | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only says 'update', offering no details on mutation behavior, partial vs full overwrite, permissions, or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence, which is concise but overly minimal for a tool with 7 parameters and no output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (7 params, no output schema, no annotations), the description lacks information on return values, error handling, and update behavior, making it incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 14% (only 'id' has a description). The description adds no parameter meaning beyond the schema, failing to compensate for low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and the resource 'existing armor's properties', distinguishing it from sibling creation tools like create_armor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 (e.g., create_armor, update_other entities), nor any prerequisites or 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.
Update an existing class's name
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Class ID to update | |
| name | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must carry the full burden. It only says 'update', but fails to disclose side effects, potential errors (e.g., if id is invalid), permissions, or atomicity. Essential behavioral traits are missing.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, short sentence with no unnecessary words. It is front-loaded and direct, but could benefit from slightly more detail without compromising conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
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 should explain return behavior and error conditions. It does not, leaving significant gaps for an agent to use it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50%; the id parameter is described, but name is not. The description adds meaning by indicating that name is the field being updated, partially compensating. However, no format or constraints for name are provided.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (update) and resource (class) and specifies the field being updated (name). It distinguishes from sibling tools like create_class and get_classes, but does not elaborate on any additional aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives (e.g., when updating a class vs. creating one). No mention of prerequisites or context, leaving the agent to infer usage without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing enemy's properties
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Enemy ID to update | |
| name | No | ||
| maxHp | No | ||
| atk | No | ||
| exp | No | ||
| gold | No | ||
| battlerName | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like side effects or permissions, but it only states 'update' with no further context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise but lacks structure and fails to prioritize key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no output schema, and many siblings, the description is insufficient; it omits return values, error handling, and usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 14% of parameters have schema descriptions, and the tool's description adds no meaning to parameters like maxHp, atk, or exp beyond their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool updates an existing enemy's properties, but it does not differentiate from sibling tools like update_actor or update_weapon.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 such as create_enemy or get_enemies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing item in the database
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Item ID to update | |
| name | No | ||
| description | No | ||
| price | No | ||
| iconIndex | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states 'update' without detailing side effects, permissions, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence. While brief, it is not verbose, but some additional detail could be added without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 5 parameters, no output schema, and no annotations, the description is too minimal to be complete. It lacks information on return values, restrictions, and parameter interactions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (only 'id' is described). The tool description does not add any parameter information to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'update' and the resource 'item', distinguishing it from sibling tools like create_item or update_actor.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives such as create_item or other update tools. The description lacks usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing map's properties
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Map ID to update | |
| displayName | No | ||
| tilesetId | No | ||
| encounterSteps | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description bears full burden. It indicates mutation but lacks details on permissions, side effects, error handling, or what happens on invalid IDs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundancy, efficient in length.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema and low parameter descriptions, the description provides minimal context. It doesn't address return values, error handling, or update behavior, leaving significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With only 25% schema description coverage, the description adds no meaning beyond the schema. It does not explain the non-id parameters or their constraints, failing to compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool updates an existing map's properties, with a specific verb and resource. It distinguishes from sibling create and get tools, though it doesn't detail which properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like create_map or get_maps. The description implies modification of existing maps but doesn't state prerequisites or exclude other use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing state's properties
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | State ID to update | |
| name | No | ||
| iconIndex | No | ||
| minTurns | No | ||
| maxTurns | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only says 'Update' implying mutation, but fails to mention if the operation is idempotent, requires permissions, or error handling for non-existent states.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no wasted words. However, it may be too brief to convey essential information, balancing conciseness with clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no annotations, the description is too incomplete. It does not explain return values, error conditions, or the effect of each parameter, leaving significant gaps for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 20% (id has a description). The description does not add meaning to the other parameters (name, iconIndex, minTurns, maxTurns) beyond what the schema provides, which is minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that this tool updates an existing state's properties. It distinguishes from get_states (read) and create_state (create) tools. However, it does not specify which properties can be updated beyond the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 create_state or other update tools. There is no mention of prerequisites, context, or trade-offs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update an existing weapon's properties
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Weapon ID to update | |
| name | No | ||
| description | No | ||
| price | No | ||
| attack | No | ||
| iconIndex | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the full burden. It only states 'update' without disclosing side effects, return values, validation, or partial update behavior, leaving significant behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise (one sentence), which is efficient, but it lacks structure and detail. While not verbose, the conciseness comes at the cost of completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity (6 parameters, no output schema, no annotations), the description is severely incomplete. It does not explain return values, error handling, allowed field updates, or any contextual constraints beyond the ID requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is only 17% (only 'id' is described), and the description does not elaborate on the remaining parameters (name, description, price, attack, iconIndex). The description adds no meaning beyond the schema, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it updates an existing weapon's properties, using a specific verb and resource. It distinguishes itself from sibling tools like create_weapon or get_weapons, though it does not specify which properties can be updated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor any preconditions or exclusions. The agent is left to infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v1.0.0create_actorcreate_armorcreate_classcreate_enemycreate_itemcreate_mapcreate_skillcreate_statecreate_weaponget_actorsget_armorsget_classesget_core_script_versionsget_database_infoget_database_limitsget_enemiesget_generator_partsget_installed_pluginsget_itemsget_mapsget_sample_mapsget_skillsget_statesget_weaponsinstall_pluginscan_dlc_packagesscan_resourcesset_database_limitupdate_actorupdate_armorupdate_classupdate_enemyupdate_itemupdate_mapupdate_stateupdate_weaponEach tool targets a distinct entity or operation (e.g., actor, armor, map) with clear verb prefixes. There is no ambiguity between tools, even those with similar patterns like get_actors and get_database_info.
All tool names follow a consistent verb_noun snake_case pattern (create_actor, get_actors, update_actor, set_database_limit). The naming style is uniform and predictable.
36 tools is reasonable for a game development server covering multiple database entities and utilities. While slightly on the higher side, it remains well-scoped and each tool serves a clear purpose.
The tool set covers create, read, and update for most entities, but lacks delete operations entirely. Additionally, update_skill is missing, leaving a notable gap in the skill lifecycle management.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Give your AI agents the tools to build, manage, and run automation workflows.
Create and manage AI agents that collaborate and solve problems through natural language interacti…
Generate game-ready 3D models, textures, and audio from natural language, over MCP.
AgentPMT is the AI agent marketplace that turns any MCP-compatible AI assistant into an autonomous employee. Connect once and your agents gain access to a growing ecosystem of tools, workflows, and skills spanning communication, data analytics, development, file management, search, and more. AgentPMT dynamically discovers and orchestrates tools from across the MCP ecosystem, so your agents can independently find the right tool for any task without manual configuration.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/devmagary/MCP-Maker'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
