Skip to main content
Glama
Redseb
by Redseb

create_enemy

Create a new enemy in Enemies.json, allocating the next unused ID and returning it with warnings. Validates skill and drop item references; omitted fields use editor defaults.

Instructions

Create a new enemy in data/Enemies.json. Only name is required; omitted fields use the editor's new-enemy defaults (100 HP, one Attack action, no drops). Allocates the next unused enemy id and returns { enemy, warnings? } (warn-by-default: a battlerName not found in img/enemies (img/sv_enemies for a side-view project) is flagged, never blocked). Throws if an actions[].skillId or a dropItems[].dataId (item/weapon/armor by kind) references a record that does not exist. NOTE: an enemy with no Hit Rate trait (xparam id 0: trait { code: 22, dataId: 0, value: 0.95 }) always misses physical actions — pass one in traits if the enemy should land basic attacks.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
expNoEXP granted when defeated
goldNoGold granted when defeated
nameYesEnemy name shown in battle and the database
noteNoNote field
dryRunNoPreview only: return a diff of what would change without writing to disk.
paramsNo8 base params: [maxHP, maxMP, atk, def, mat, mdf, agi, luk]
traitsNoTrait objects { code, dataId, value }
actionsNoAction patterns { skillId, conditionType, conditionParam1, conditionParam2, rating }
dropItemsNoDrop-item objects { kind, dataId, denominator }
battlerHueNoBattler hue rotation 0-360
battlerNameNoBattler graphic filename (img/enemies; img/sv_enemies when System.optSideView)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.4.0
    • changedInput schema / properties / battlerName / description
      Previous value: -"Battler graphic filename (img/enemies)"New value: +"Battler graphic filename (img/enemies; img/sv_enemies when System.optSideView)"
  2. First observedv1.2.0

TDQS

A4.4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: omitted-field defaults (100 HP, one Attack action, no drops), next-free-id allocation, return shape `{ enemy, warnings? }`, warn-vs-block behavior for battlerName, throw conditions for dangling skillId/dataId references, and the Hit Rate trait gotcha.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Dense but front-loaded: the core purpose and required-parameter note come first, then returns, then exception behavior, then the gameplay NOTE. Every sentence adds operational value, though the single long paragraph could be broken up for scanability.

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

Completeness5/5

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

For an 11-parameter mutation tool with no output schema and no annotations, the description compensates fully by explaining defaults, id assignment, return shape, and failure modes. Nothing an agent needs to call it correctly appears missing.

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

Parameters4/5

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

Schema coverage is already 100% (baseline 3), but the description adds real semantic value beyond the schema: default values for omitted fields, the cross-reference validation semantics of actions[].skillId and dropItems[].dataId (item/weapon/armor by kind), and the imperative to pass a Hit Rate trait in `traits`.

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

Purpose5/5

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

States a specific verb (Create) and resource (new enemy) plus the exact target file data/Enemies.json. It clearly distinguishes itself from the sibling update_enemy and other create_* tools by describing creation semantics with id allocation.

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

Usage Guidelines3/5

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

Usage is implied through defaults, validation rules, and a practical NOTE, but the description never explicitly states when to choose this over alternatives (e.g., update_enemy, batch_create) or any when-not conditions. Guidance is present but not routing-oriented.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools