Skip to main content
Glama

manage_ui

Design, create, update, and check Roblox in-game UI components such as ScreenGui and Frame, with built-in accessibility validation.

Instructions

Create / update / verify Roblox in-game UI (ScreenGui / Frame / TextLabel / …). Always start a new UI task with the design_brief action — it accepts an omitted or partial brief, inspects Studio context, then returns a current-state summary, recommended mode/change scopes, candidate brief patches, and one user-facing confirmation or clarification question. design_brief may return asset recommendation candidates from existing UI images, user references, or conservative manage_assets.search results; do not use a recommended asset until the user accepts it. Do not dump enum lists at the user; map natural language to internal purpose/platform/tone values through recommendations, and only finalize identity-defining fields after the user accepts a recommendation or provides equivalent intent. Read MCP resource weppy://ui-studio/guide for the full guide; it is split into Floor (non-negotiable accessibility), Vocabulary (style menu — pick ONE family per dimension; do not blend everything), Direction (brief → choices), and Tree encoding (Roblox property JSON shapes). Floor essentials suggested by Design Check (check): (1) mobile touch target ≥ 44 px (2) text contrast ≥ 4.5:1 (3) prefer explicit TextSize over TextScaled (4) respect platform safe zones (5) warn on full-screen opaque roots for non-modal purposes. Style is brief-driven; reject the default AI look (uniform 8 px corners + generic blue + glass card + Gotham everywhere) — each game deserves its own visual identity.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
actionYesUI action. [PRO]: design_brief, create_tree, update, delete, preview, check. (M2+에서 propose_layout/apply_asset 추가 예정.)
contextIdNoOptional execution context identifier. Used to continue an existing context for mutating actions.
contextSummaryNoOptional structured execution context attached to this tool call.
replayMetadataNoOptional replay-ready metadata attached to this tool call.
briefNo완성 또는 부분 design_brief 구조체. Used by: design_brief (optional; partial allowed).
briefIdNodesign_brief 가 반환한 brief 식별자. Used by: create_tree, update, delete (optional).
treeNoUI 트리 선언형 JSON. 루트는 ScreenGui. 스키마: {className: string, name?: string, parent?: string, properties?: {...}, children?: Tree[]} parent 생략 시 StarterGui. className은 Roblox GUI 계열(ScreenGui/Frame/TextLabel/TextButton/ImageLabel/ImageButton/ScrollingFrame/TextBox/UIListLayout/UIGridLayout/UIPadding/UICorner/UIStroke/UIAspectRatioConstraint/UIGradient/UITextSizeConstraint/UISizeConstraint) 한정. In-game UI 기본 구조(HUD / button / toast / card / 대부분의 menu): ScreenGui > Frame(BackgroundTransparency=1) > 실제 UI 요소. ScreenGui 직속 풀스크린 불투명 Frame 은 modal 용도에만 사용한다. Property 값 인코딩: UDim2는 {xScale, xOffset, yScale, yOffset}, UDim은 {scale, offset}, Color3는 {r, g, b}, Vector2/Vector3는 {x,y}/{x,y,z}, Enum은 item name string을 사용한다.
targetPathNoPath to existing UI instance. Both `StarterGui.MyGui` and `game.StarterGui.MyGui` are accepted. Used by: update, delete (required).
changesNo부분 변경 스펙. {properties?: {...}, addChildren?: Tree[], removeChildren?: [string]} properties는 `Instance:SetPropertyValue` 호환 키·값 쌍. 값 인코딩은 tree 설명의 Property 값 인코딩을 따른다.
includeVisualAnalysisNoOpt-in only. Used by: check. When true, the server may read a saved preview snapshot PNG + visible GUI metadata and merge AI visual suggestions into check_results. Default false; no screenshot capture is triggered by check.
snapshotIdNoSaved manage_ui.preview snapshot_id to use for visual analysis. Used by: check when includeVisualAnalysis=true. If omitted, the latest compatible saved snapshot is used when available.
Behavior3/5

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

No annotations are provided, so the description must cover behavioral aspects. It discloses behaviors like asset recommendation acceptance and refers to a full guide, but lacks details on reversibility, permissions, or side effects of actions beyond design_brief.

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?

The description is front-loaded with a clear purpose and packs multiple guidelines. While lengthy, every sentence adds value, avoiding redundancy. It could be slightly more concise without losing information.

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

Completeness3/5

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

For a tool with 11 parameters and nested objects, the description explains the design_brief workflow in detail but leaves gaps for other actions (e.g., check output). No output schema, so more detail on results would improve completeness.

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?

Input schema has 100% description coverage, providing baseline 3. The description adds workflow context (e.g., 'Always start with design_brief') but does not significantly enhance parameter meaning beyond the schema's own descriptions.

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 clearly states 'Create / update / verify Roblox in-game UI (ScreenGui / Frame / TextLabel / …).' It specifies the verb and resource, and distinguishes itself from sibling tools like manage_assets or manage_scripts by focusing on UI elements.

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?

The description explicitly advises to 'Always start a new UI task with the `design_brief` action' and provides guidance on handling enums and references. It offers clear context but does not explicitly state when to avoid this tool in favor of siblings, though the sibling tools are distinct enough.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hope1026/roblox-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server