Skip to main content
Glama
gurmyd

Studio Live

by gurmyd
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Run Luau in Studio

run
Destructive

Execute Luau programs in Roblox Studio against the resident S API, building, querying, and verifying in one call and returning a JSON-safe summary.

Instructions

Run a Luau program in Roblox Studio against the resident S API. Ship whole programs, not micro-calls: build, query and verify in one call and return one JSON-safe summary. Globals: S, ARGS (= args), print/warn (captured), game, workspace, task. dm 'edit' (default): ONE ChangeHistory recording — one undo step, rolled back on error/timeout. 'server' | 'client' | 'client:N': inside the live playtest, ephemeral (lost on stop, not undoable). code or code_file (absolute path the bridge reads). Never heredoc Luau: \n in a string becomes a real newline → syntax_error "Malformed string". S: get, ensure(path,class,props), find{root,name,class,tag,attr,max}, tree, props, new, set (unwritable props → result.unwritable), batchSet, clone, destroy (undoable), part, model, grid, placeOn(part,target,{align,gap}) sets a part on top of target, fits(cframe,size) → ok, blockers, overlaps(parts), script.get(path,{from,to})/set/patch/restart/create, emit, log, yield() (in long loops), wait, raycast, distance, remaining(). Geometry is enforced: parts intersecting parts (touching faces are fine) and BaseParts parented under BaseParts (use Models/Folders) are reported. geometry_policy warn (default) → result.geometry {overlaps[{a,b,depth}], nested[{path,parent}], checked, totals} + warnings; reject → rolled back, error geometry_violation with the report; off. Fix before moving on. Result: {value, output[], duration_ms, changes{added,removed,paths}, undo: committed|cancelled|unavailable|n/a, ephemeral, dm, warnings?, detached?, unwritable?, geometry?}. response_format 'detailed' adds 12-component CFrames. Errors: {error:{code: luau_error|syntax_error|timeout|no_peer|cancelled|busy|geometry_violation|…, message, stack, output}}. Still running after wait_ms (default 25000)? {job_id, status:'running'} — the program keeps running; use job. Edit-DM writes queue FIFO. dry_run (edit only) rolls back; a raw :Destroy() is neither rolled back nor undoable (use S.destroy). Several Studios connected: pass session.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
dmNoTarget DataModel: 'edit' (default) | 'server' | 'client' (lowest-numbered) | 'client:N'
argsNoAvailable to the program as ARGS
codeNoLuau program. Globals: S (resident API), ARGS, print/warn (captured), game, workspace, task. A top-level `return` is captured.
dry_runNoedit DM only: run, then roll back
sessionNoStudio session GUID or unique prefix (default: the active hub; required for writes when several Studios are connected)
wait_msNoWait this long for completion before returning a {job_id,status:"running"} handle (default 25000)
code_fileNoInstead of code: absolute path of a file holding the Luau (read by the bridge; UTF-8, BOM ok, ≤ 4 MB). No shell/JSON escaping touches it
timeout_msNoExecutor deadline in ms (default 30000)
undo_labelNoChangeHistory waypoint name (edit DM)
geometry_policyNowarn (default; env STUDIO_LIVE_GEOMETRY_POLICY): overlapping/nested parts → result.geometry + warnings; reject: such a run is rolled back (error geometry_violation); off: no check. Play DMs check only when set
response_formatNodetailed: full 12-component CFrames ('c') in the returned value (default concise)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations carry only destructiveHint=true and no readOnly/idempotent flags, so the description must carry the behavioral burden—and it does. It discloses rollback semantics per dm mode ('ONE ChangeHistory recording… rolled back on error/timeout'), ephemerality of play DMs, geometry enforcement with policy outcomes, the running-job escape hatch, and the FIFO queue. None of this contradicts the annotations; it substantially extends them.

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?

It is long, but the tool is complex and the density is justified. The text is organized into scannable blocks (dm modes, code input, S API, geometry, results/errors, long-running) and front-loads the core contract before enumerating API details. Every section earns its place, even if a future pass could trim the S-method listing.

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

Completeness5/5

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

Given 11 params, no output schema, and a mutation-heavy tool, the description is unusually complete: it defines the success result shape, error envelope with codes, geometry report structure, long-running job handle, and undo/dry-run caveats. It even covers edge cases like a raw `:Destroy()` not being rolled back. Nothing essential is missing for an agent to call it correctly.

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 coverage is 100%, so the baseline is 3; the description adds real value on top by explaining `code_file`'s bypass of shell/JSON escaping, `geometry_policy` outcomes in the result, `response_format`'s effect on CFrames, `dry_run` rollback limits, and `session` requirements. Slight gap: `args`/`timeout_ms` rely on the schema alone, but that is acceptable at full coverage.

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 opens with a specific verb and resource: 'Run a Luau program in Roblox Studio against the resident S API.' It goes beyond the name by defining the execution model ('Ship whole programs, not micro-calls') and enumerating provided globals, distinguishing it from siblings like playtest, observe, and job.

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 explicit direction on when to use the tool: 'Ship whole programs, not micro-calls' and 'build, query and verify in one call,' and it points to the sibling `job` for long-running programs ('use `job`'). It also flags what not to do ('Never heredoc Luau') and when `session` is required. It doesn't contrast every sibling explicitly, but the context is clear enough for selection.

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