Skip to main content
Glama

scene_add_unit_status

Destructive

Defines a temporary unit status effect—outline, see-through, speed, invincibility, rooting, or stat boosts—with optional duration and returns a statusId to apply or remove it in a copied save.

Instructions

Define a unit status (单位状态) in a copy of a save: an effect that a graph puts on an entity and takes off again. outline draws a coloured edge around the entity, the platform's usual way to say "you can interact with this" or to mark a team, and it needs no text; seeThrough shows the entity through walls in a colour; maxHealth raises maximum health by a number per stack. Colours: green or white (or a colour code of the editor as a number; only those two are mapped). The status lasts until it is removed. Returns statusId for f.addUnitStatus / f.removeUnitStatus. Writes a new .gil in the workspace; the official save is not touched. Verified in play on 2026-10-10: a green outline on an object and a white one on a character, put on with f.addUnitStatus(character that walked in, target, statusId, 1n, dictionary) and taken off with f.removeUnitStatus (the applier, the first argument, is the character, as in the official sample). More effects, which may be combined in one status: speedPercent (movement speed of a character or a creature, a whole percentage up to +40, which is as far as the editor goes; negative slows), invincible true (takes no damage and does not hear attacks), superJump [horizontal, vertical] (the multipliers of a character's jump: [1.5, 2] jumps half again as far and twice as high), rooted true (the player's character cannot be moved with the keys: a stun, a trap). These are what pickups and hazards are made of: a boot that speeds up for some seconds, a star that makes invincible, tar that slows, a snare that holds. seconds makes the status end by itself after that long (left out it stays until a graph removes it). The effect ids were read from a status configured by hand in the editor on 2026-10-13. Verified in play that day (examples/hazards): after a pickup of speedPercent 40 the player covered 9.4 m in the next 1.2 s (5.2 m/s without), one of rooted with seconds 2 held the player on the spot for two seconds with the movement key down; with invincible on, an attack of 2000 that had taken a thousand health a moment before took none; with superJump [1, 2.5] a jump on the spot rose three metres (hazards_test2.json).

Input Schema

NameRequiredDescriptionDefault
nameYes
rootedNo
mapPathNo
outlineNo
secondsNo
maxHealthNo
superJumpNo
invincibleNo
outputNameNo
seeThroughNo
stackLimitNo
speedPercentNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial context beyond the annotations: it writes a new .gil in the workspace while leaving the official save untouched, the status lasts until removed unless seconds is set, and it returns statusId for use with add/removeUnitStatus. Play-verified numbers (9.4 m in 1.2 s at speedPercent 40, two-second root, 2000 damage absorbed) give the agent concrete behavioural expectations the annotations cannot convey.

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

Conciseness3/5

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

Front-loaded with the core definition, which is good, but the body sprawls into dated verification anecdotes and exact metrics that dilute the essential parameter guidance. It is informative but over-long for a tool description; several sentences could be compressed without loss.

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

Completeness4/5

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

For a 12-parameter mutating tool with no output schema, the description covers purpose, side effects, runtime return value, effect semantics and duration behaviour thoroughly. The gaps are the three unmention ed structural parameters (mapPath, outputName, stackLimit), which an agent must infer from the schema alone.

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 0%, so the description must carry the load, and it explains most parameters well: outline/seeThrough colour semantics and the unmapped-code caveat, maxHealth per-stack, speedPercent's +40 editor ceiling and negative slowdown, invincible, superJump [horizontal, vertical], rooted, and seconds. It leaves stackLimit, mapPath and outputName unexplained, so not a 5.

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 and resource ('Define a unit status (单位状态) in a copy of a save: an effect that a graph puts on an entity and takes off again'), immediately distinguishing it from listing tools like scene_list_unit_statuses. The conceptual framing of what a status is makes the resource unambiguous.

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

Usage Guidelines4/5

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

Gives clear usage context ('what pickups and hazards are made of: a boot that speeds up, a star that makes invincible, tar that slows, a snare that holds') and the runtime pairing (f.addUnitStatus / f.removeUnitStatus). It stops short of explicit when-not-to-use guidance or naming a sibling alternative, so it lands at 4 rather than 5.

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