Skip to main content
Glama

scene_add_client_ui

Destructive

Adds a client UI control tree to a copied save, with a screen-filling container, nested controls, a client script, and off-phone canvas warnings.

Instructions

Put a tree of client controls (客户端控件) on the screen, in a copy of a save: a container that fills the screen, with the controls given under it and the client script (scene_set_client_script, by name) on its root. A control is {name, kind, position, size, children}: kind "image" (a picture: give image, an id from image_catalog, and colour and opacity here, or let the script give it one with control:SetImage(Enum.ImageSource.StaticReference, id) and control.imageColor = Color(r, g, b, a); fill: {shape: horizontal | vertical | radial90 | radial180 | radial360, from, amount 0 to 1} shows a part of it, which is a bar or a cooldown ring with no script drawing it, feather softens its edge and invertMask shows the rest instead), "grid" (网格视窗: a scrolling list whose items are copies of a template, itemTemplate: its name; the script fills it), "reference" (模板引用控件: shows a template, template: its name), "presetButton" (预设按钮), "keyHint" (按键提示: the key of the device in use), "textWindow" (文本视窗: a text box that scrolls), "animation" and "fullscreenAnimation" (界面动效), "cursorArea" (an area that hears the mouse: area:AddCursorEventListener(Enum.CursorEventType.CursorClick, fn); the root needs showCursor = true for the cursor to be there), "container" (holds other controls in children, and moves them with it), "text" (a text box; shown on an account of 奇匠 level 2 and up, seen in play 2026-10-13, and nothing of it on level 1). position is [x, y] of the control's centre from the centre of what holds it, y up, in units of the canvas; size [width, height]. The canvas is 1600 x 900 on a computer, 1280 x 720 on a phone, 1920 x 1080 on a console: the same numbers are used on all of them unless devices says otherwise, so a control more than 640 to the side or 360 up or down is off a phone's screen; hang what belongs at an edge on that edge with anchor, or give devices {mobile: {position, size}, console, mobileGamepad} where the layout must differ. The answer names what would be off a phone as given (offPhoneCanvas: the control and by how much on which side). Beyond what is said here the controls are written the way the editor makes a new one: what each shows, and every change after, is the script's to make (SetAnchoredPosition, SetSizeDelta, SetVisible, SetActive). A control takes more than this when wanted (the schema lists it): scale, rotation, pivot and anchors; active false and visible false for a start out of sight; a script of its own, and values of its own for that script's public variables (script: {name, values: {variable: value}}; a variable of type controlId takes the name of a control); navigation {left, right, up, down} saying which control the stick of a gamepad goes to (by name, or "none"); text {content, fontSize, colour, align...} on a text box (scrollable and scrollbar on a text window); grid {columns or rows, itemSize, spacing, padding}; states {normal, hover, pressed, disabled} naming the children a preset button shows (give hover as well as normal, or the button shows nothing under the cursor); key for a key hint; effect for an interface effect; and on the interface itself showCursor, blockKeys, blockCursor, hidden (out of sight, its scripts not started, until a graph switches it on by containerId), scripts (several on the root). A script finds a control by its name, so the names of one holder must differ. Controls are drawn in the order given, later ones over earlier ones, and over the whole of the ordinary interface when they cover it. Client controls are destroyed and made anew when the player is teleported or reconnects: a script must be able to draw its state again from the custom variables. Writes a new .gil in the workspace. Byte for byte the official sample 客户端脚本 when given what that sample holds, and every kind and every setting byte for byte what the editor writes for it; seen in play on 2026-10-13 (examples clientui, clientgame, clientlist, clientmenu, clientcheck, clientvars), text and the text window on 2026-10-13 on an account of 奇匠 level 2 (example clienttext; level 1 shows no custom text), all but what only another device shows (devices, navigation: this was played on a computer with mouse and keyboard; editor_preview_interface shows the other canvases).

Input Schema

NameRequiredDescriptionDefault
nameYes
hiddenNo
scriptNo
mapPathNo
replaceNo
scriptsNo
controlsNo
blockKeysNo
outputNameNo
showCursorNo
blockCursorNo
isolateNavigationNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already flag destructiveHint=true and readOnlyHint=false, and the description adds real value beyond that: it states the tool 'Writes a new .gil in the workspace' and that client controls are destroyed and recreated on teleport/reconnect, which a script must be able to redraw. It omits what the `replace` flag does to existing UI, which is the main residual gap for a destructive write.

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 action is front-loaded, but the body is a single wall of run-on text with heavily nested parentheses that is hard to parse and well past what an agent needs in one pass. Nearly every clause carries information, yet structure and scannability suffer badly.

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 very complex, no-output-schema tool, this covers the model (canvas sizes, positioning units, control tree, per-device overrides) and even describes the returned offPhoneCanvas field. Only the effects of `replace`/`outputName` and a few device-preview behaviors are left implicit.

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 description coverage is 0% across 12 top-level params and a deep nested control schema, so the description carries the whole burden — and it explains a great deal: kind semantics, position/size coordinate system, anchor, devices overrides, script/values, states, text, grid, fill, feather, showCursor, blockKeys, blockCursor, hidden. It leaves several schema-only fields (mapPath, replace, outputName, isolateNavigation, sound, padKey, below, mask, focusable) unexplained, so not a 5.

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

Purpose4/5

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

Opens with a concrete verb and resource: 'Put a tree of client controls on the screen, in a copy of a save,' and enumerates every control kind it can build. An agent knows exactly what the tool produces. It does not, however, distinguish itself from narrow siblings like scene_add_text_box, scene_add_button, or scene_add_progress_bar, which apparently build single controls.

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?

It references related tools by name (scene_set_client_script, image_catalog, editor_preview_interface) and explains that controls behave as the editor's defaults unless overridden, which is useful context. But it never says when to prefer scene_add_client_ui over the single-control sibling tools, nor any prerequisite/exclusion, so the routing guidance is only implied.

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