Skip to main content
Glama

scene_add_image

Destructive

Adds a picture, colored panel, or frame to a saved scene screen by image ID, colour, opacity, position, and size, letting visuals communicate when custom text is unavailable.

Instructions

Put an image (图片) on the screen, in a copy of a save: a plain rectangle in a colour (image 100001, the default: a panel behind bars, a coloured mark, a frame for the corner of the screen) or one of the pictures of the platform by its id. This is how a screen says something without words, which matters on an account of 奇匠 level 1, where custom text does not show. colour is "#rrggbb" (it tints a picture; white leaves it as it is), opacity 0 to 1 (0.5 with black is the dark panel the official samples put behind their controls). position is [x, y] from the screen centre on a 1600 x 900 canvas (y up), size [width, height]. image_catalog shows every picture of the platform with its id (about 1600, in fifteen categories): choose there. knownImages of scene_list_interface names 22 of them in words (plain discs, an arrow, a question mark, a sword and shield, fruit, gift boxes, round birds, a rank letter). Controls are drawn in the order they were added, so add the panel before what lies on it. A graph takes an image off the screen and puts it back with f.modifyUiControlStatusWithinTheInterfaceLayout(player, controlId, UIControlGroupStatus.Off or .On) (a row of discs as lives: examples/images/images_lives.json, seen in play); hidden true starts it off the screen. Verified in play on 2026-10-13 on an account of 奇匠 level 1 (examples/images): panel, pictures and coloured rectangles all show.

Input Schema

NameRequiredDescriptionDefault
nameYes
sizeNo
imageNo
colourNo#ffffff
hiddenNo
mapPathNo
opacityNo
positionNo
outputNameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior5/5

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

Beyond the annotations, the description discloses important behavior: insertion into a copy of a save, drawing order, hidden controls starting off-screen, and graph-based toggling via modifyUiControlStatusWithinTheInterfaceLayout. It also notes play verification and the level-1 text limitation, which materially helps an agent understand consequences.

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

Conciseness3/5

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

The description is front-loaded with a clear purpose, but the single dense paragraph is overlong and packed with parenthetical examples and verification notes. Much of it is useful, yet it could be structured and trimmed for faster agent parsing.

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 complex 9-parameter UI mutation tool with no output schema, the description covers purpose, visual parameters, related selection tools, and behavioral caveats well. It is not fully complete because name, mapPath, and outputName are not explained and return behavior is not addressed.

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

Parameters3/5

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

Schema description coverage is 0%, so the description must carry parameter meaning. It explains image, colour, opacity, position, size, and hidden well, but omits the required name parameter and the optional mapPath and outputName parameters, leaving important semantics undocumented.

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 description states a specific verb and resource: putting an image on the screen in a save copy, including default rectangle and platform-picture variants. It distinguishes the tool from text-based UI and points to scene_list_interface and image_catalog for related choices.

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 gives clear usage context, including the key case where custom text is unavailable and this tool supplies visual meaning instead. It also tells the agent to choose images via image_catalog or knownImages from scene_list_interface, though it does not explicitly name when not to use this tool or contrast it directly with scene_add_text_box.

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