Studio Live
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| STUDIO_LIVE_HOME | No | The bridge home directory used for persisted controllers, Open Cloud key files and other state. | ~/.studio-live |
| STUDIO_LIVE_PORT | No | The bridge listens on 127.0.0.1:47800 (STUDIO_LIVE_PORT overrides; Studio connects to the literal 127.0.0.1). | 47800 |
| ANTHROPIC_API_KEY | No | Anthropic API credential so the look tool can call the Claude API directly (~2 s per look). | |
| ANTHROPIC_AUTH_TOKEN | No | Anthropic API credential (alternative to ANTHROPIC_API_KEY) so the look tool can call the Claude API directly. | |
| ROBLOX_OPEN_CLOUD_KEY | No | Roblox Open Cloud API key for the open place, read per call by the cloud tool (alternative: <STUDIO_LIVE_HOME>/opencloud.json / .key). | |
| STUDIO_LIVE_STUDIO_EXE | No | Path to a RobloxStudioBeta.exe, used by 'studio-live twin' to skip the version scan. | |
| STUDIO_LIVE_GEOMETRY_POLICY | No | Set to 'reject' (STUDIO_LIVE_GEOMETRY_POLICY=reject) to roll back edit-DM runs that add overlapping or nested parts with geometry_violation. | |
| STUDIO_LIVE_VISION_PROVIDER | No | Chooses the vision provider for the look tool: auto | api | claude-cli (default auto: the API when a credential resolves, else the Claude CLI). | auto |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| runA | Run a Luau program in Roblox Studio against the resident |
| observeA | Read-only view of Studio. what:
|
| playtestA | Control the live playtest and the in-engine runtime. Keep ONE playtest alive; a restart costs ~3 s and loses play-DM state.
|
| inputA | Human-like input in a play client through the real input pipeline (dm 'client' = lowest-numbered client, or 'client:N'). actions run in order:
|
| eventsA | Backfill from the bridge's event journal (ring of 10,000 per session). Returns events with seq > since, oldest first → {cursor, events[], dropped, truncated, latest_seq, hub_dropped}. cursor is the seq of the last event actually returned: pass it as the next since. truncated means more events wait after cursor; dropped > 0 means the ring evicted events you never saw. kinds filters by event type: log, error, assert, milestone, custom, playtest, peer, selection, job, controller, change (default all); levels filters log events (print|info|warn|error). timeout_ms > 0 long-polls: returns as soon as a matching event arrives, or empty when the timeout (≤ 50000) elapses. This is the portable fallback to push. Prefer Monitor on ws://127.0.0.1:/events: batched frames ≤ 4 KB carrying seq and dropped; default kinds error, assert, milestone, custom, playtest, peer, controller, job plus warn/error logs (?kinds=…&levels=… per socket). After any dropped > 0 or seq gap on the socket, call events with since = the last seq you saw. |
| skillsA | Luau program library on disk (/skills/.luau with a |
| jobA | Track long operations that returned {job_id, status:'running'}. status {job_id} → {status: running|done|error, op, dm, elapsed_ms, progress, notes, hub_connected, result?, error?}. wait {job_id, wait_ms ≤ 50000} blocks until the job finishes or the wait elapses, then returns the same snapshot. list → {jobs:[…]} running first, then recent ones (find an id you lost). cancel {job_id} asks Studio to stop the program at its next S.yield()/slice boundary and rolls back an edit-DM recording; the job then finishes with error.code 'cancelled'. Jobs survive a Studio reconnect (hub_connected false while it is away) and end at their deadline. Finished jobs expire 10 minutes after completion. |
| cloudA | Roblox Open Cloud for the place open in Studio. IDs default to the connected session (universe = game.GameId, place = game.PlaceId, creator = the place owner); pass universe_id / place_id / id / creator only to override. Needs an API key: env ROBLOX_OPEN_CLOUD_KEY or /opencloud.json {"key":"…"}, re-read every call and never returned. A 403 names the exact Creator Hub permission to add — or call info what:"key" first: it probes the key and reports allowed | denied | unknown per action. action (ops in parens; arg help is on each field):
|
| lookA | Look at the Roblox Studio window through a vision model and get a short TEXT answer instead of an image — the screenshot never enters your context (a 768 px frame is ≈ 500 image tokens on the sidecar, a few hundred characters back to you).
One-shot: {question, max_width? (768), region? {x,y,w,h} window px, model?} → {answer, model, provider, captured_ms, model_ms, usage, frame_path}. Ask concrete visual questions: 'is there a red error in the Output panel? quote it', 'where is the Play button (region or px)?', 'is the character standing on the platform or falling?'. The model sees only the screenshot and answers 'not visible' when it cannot tell.
Watch: {watch: {question, interval_s (5, min 2; 15 on claude-cli), max_frames (60), stop_when? (substring, or /regex/i), diff_only? (true)}} → {watch_id}. Frames are analysed in the background, one model call at a time; each answer arrives as a Monitor event {type:'vision', watch_id, frame, answer, changed, provider}. With diff_only, frames whose bytes differ < 2% from the last analysed frame are skipped (no model call, no event). The watch ends on max_frames, when the answer matches stop_when, on {stop: watch_id | 'all'}, or after 3 consecutive failures; the last event has done:true and reason. {list: true} shows running watches with counts and the last answer.
Prefer observe tree|props|find|player for state — they are exact and free. look is for what only pixels can tell: rendering, layout, UI text, visual glitches, what a playtest looks like. Works with an Anthropic API key (ANTHROPIC_API_KEY / |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 9 tools
Each tool has a distinct primary job—observe for structured reads, look for vision QA, run for scripted execution, playtest for session lifecycle, input for synthetic control, events for journal backfill, skills for reusable programs, job for async tracking, cloud for Open Cloud. A couple of near-overlaps remain (observe status/logs versus playtest status and the events journal), but descriptions generally call out when to use each.
All tool names are lowercase single words in a consistent shorthand style (observe, look, run, playtest, input, events, skills, job, cloud). No casing or separator conventions are mixed, making the naming predictable.
Nine top-level tools is well-scoped for a Studio automation server; each tool covers a necessary capability, and the broad observe modes are bundled under one read tool rather than fragmented into many MCP tools. Nothing feels redundant at the top level.
The surface covers the full loop: inspect (observe), visually verify (look), mutate and script (run), control playtests (playtest), send input (input), consume events (events), persist reusable programs (skills), manage long jobs (job), and access Open Cloud (cloud). The run tool's S API also provides an escape hatch for anything not explicitly modeled, so there are no obvious dead ends.