Skip to main content
Glama

scene_add_progress_bar

Destructive

Adds an on-screen bar that tracks a player's integer variable — purse, health, countdown, or goal progress — showing percent, value, or ratio on a copy of the save, even on 奇匠 level 1 accounts.

Instructions

Put a bar on the player's screen that follows one of the player's custom variables, in a copy of a save: a purse, a countdown, the health of the thing to defend, progress towards a goal. It is the way to show a number to the player on an account whose 奇匠 level is 1, where text boxes show nothing in play (measured) but bars do, with the fill and a percentage, or with the number itself (shows "value"). variable is an integer custom variable of the player (made with start value min if the player template does not have it); min and max are the ends of the bar. position is [x, y] from the screen centre on a 1600 x 900 canvas with y up (top centre is about [0, 380], top left [-600, 380]); size is [width, height]. A graph moves the bar with f.setCustomVariable(player, variable, value, true). How it looks: shape "horizontal" (as it comes), "vertical" or "ring" (a circle that fills clockwise from the top: a cooldown, a charge); shows "percent" (as it comes), "value" (the number itself: 7 coins read as 7, on an account of 奇匠 level 1 too, since the bar writes it, not a text box), "ratio" or "nothing" (a clean bar); colour of the fill and backColour behind it ("#rrggbb", backOpacity 0.5 unless said), textColour, fontSize. hidden true leaves the bar off the screen until a graph switches it on with f.modifyUiControlStatusWithinTheInterfaceLayout(player, controlId, UIControlGroupStatus.On). The style fields were read from three bars restyled by hand in the editor on 2026-10-13 and seen in play that morning (examples/images/images_lives.json): a red bar reading 6.0, a blue ring filled to six tenths, an upright bar reading 6.0 / 10.0, and a picture that came on when the graph switched it on. Writes a new .gil in the workspace; the official save is not touched.

Input Schema

NameRequiredDescriptionDefault
maxYes
minNo
nameYes
sizeNo
shapeNo
showsNo
colourNo
hiddenNo
mapPathNo
fontSizeNo
positionNo
variableYes
backColourNo
outputNameNo
textColourNo
backOpacityNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Adds real context beyond the annotations: it clarifies that a new .gil is written to the workspace and the official save is not touched, which bounds the scary destructiveHint=true. It also discloses the hidden-until-switched-on lifecycle and names the runtime calls (f.setCustomVariable, f.modifyUiControlStatusWithinTheInterfaceLayout) needed to drive or reveal the bar. It does not say what happens if outputName collides with an existing file.

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

Conciseness3/5

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

The core purpose is front-loaded, which is good, but the body is a dense run-on with stacked parentheticals ('(measured)', '(shows "value")') and provenance trivia about bars restyled on 2026-10-13 and an examples/images file that adds little for an agent. It is informative but hard to scan, and the style guidance could be bulleted or trimmed.

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 16-parameter, no-output-schema tool, the description covers behaviour, coordinate conventions, enum semantics and side effects well enough to call it correctly. Gaps remain around name/outputName/mapPath and around what the call returns or where the .gil lands, which matter because outputName looks like it controls the artifact name.

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

Parameters4/5

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

With 0% schema description coverage across 16 parameters, the description carries the load well: it explains variable (integer custom variable, auto-created with start value min), min/max, the position coordinate system with concrete examples, size, all three shape values, all four shows values, colour/backColour/textColour/fontSize and the backOpacity 0.5 default. It leaves name, mapPath and outputName (the file-naming parameter) completely unexplained.

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?

The opening sentence gives a concrete verb and resource — 'Put a bar on the player's screen that follows one of the player's custom variables, in a copy of a save' — and lists concrete uses (purse, countdown, health of the thing to defend). It implicitly separates itself from scene_add_text_box by explaining that text boxes render nothing in play on level-1 accounts while bars do.

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?

It states a clear triggering condition: use this when you need to show a number to the player on an account whose 奇匠 level is 1, where text boxes show nothing. The alternative (text boxes) is named by contrast, though no explicit 'do not use when…' exclusion or reference to sibling tools like scene_add_text_box is given.

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