Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Run Luau in Studio

execute_luau
Destructive

Runs Luau in Roblox Studio to access data, perform calculations, or call engine APIs that dedicated tools don't cover, returning printed or returned results.

Instructions

Runs Luau in Studio's plugin context and returns whatever it printed, returned, or threw.

This is the escape hatch. Reach for it only when no dedicated tool fits — create, modify, delete, move, script_edit and find validate their input, type values from the live API dump, and wrap writes in an undo recording. Code run here does none of that, so a typo becomes a runtime error instead of a suggestion, and changes it makes may not be undoable as one step.

Good uses: reading something no tool exposes, a one-off calculation over many instances, or calling an engine API the tools do not cover.

Output printed while it runs is captured and returned, so print is a reasonable way to get values out. return works too, including returning a table — it comes back as a structure, not a summary. There is no timeout: an infinite loop will hang Studio until it is force-quit.

Against a running playtest server, Studio disables loadstring, so the code is compiled through a ModuleScript instead and runs at script identity — plugin-only APIs are unavailable there. When that happens it is stated in the result rather than left to be inferred from a failure.

Do not use require to read live state out of a running game. This runs in the plugin's own Luau VM with its own module cache, so require here returns a second, freshly-initialised copy of the ModuleScript — its counters and caches read as empty while the real one is running fine, and a zero is indistinguishable from a genuine zero. Read live state off the DataModel instead (instances, attributes, properties), or have the game print it and read that with console. The result warns when a call could have hit this.

target="live" runs the script on Roblox's servers against the PUBLISHED place instead, with no Studio involved. That is how you read or repair production: a real player's data store entry, what the live game actually holds, a migration over saved data. Everything the script prints comes back in logs.

BE CAREFUL WITH IT. The Studio path has an undo stack and a place nobody is playing. This one touches live data and live players, and nothing here can put any of it back — so it needs confirm: true and you should read before you write. Roblox queues it as a task, so expect seconds, not milliseconds, and a state of COMPLETE or FAILED rather than a bare value.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sourceYesLuau to run. In an editor session this has plugin permissions, so `game`, `workspace` and plugin-only APIs are all reachable.
targetNo'studio' runs in the connected Studio, with plugin permissions. 'live' runs on Roblox's servers against the published place — production, with no undo.studio
confirmNoRequired for target="live". This runs against the game people are playing and nothing here can undo it.
placeIdNolive only: which place. Omit to use `cloud place`.
studioIdNoTarget Studio; omit for the active one.
universeIdNolive only: which game. Omit to use `cloud universe`.
timeoutSecondsNolive only: how long the script may run. Defaults to 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv0.6.8
    • addedInput schema / properties / confirm
      Added value: +{
+  "description": "Required for target=\"live\". This runs against the game people are playing and nothing here can undo it.",
+  "type": "boolean"
+}
    • addedInput schema / properties / placeId
      Added value: +{
+  "description": "live only: which place. Omit to use `cloud place`.",
+  "type": "string"
+}
    • addedInput schema / properties / target
      Added value: +{
+  "default": "studio",
+  "description": "'studio' runs in the connected Studio, with plugin permissions. 'live' runs on Roblox's servers against the published place — production, with no undo.",
+  "enum": [
+    "studio",
+    "live"
+  ],
+  "type": "string"
+}
    • addedInput schema / properties / timeoutSeconds
      Added value: +{
+  "description": "live only: how long the script may run. Defaults to 30.",
+  "maximum": 300,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / universeId
      Added value: +{
+  "description": "live only: which game. Omit to use `cloud universe`.",
+  "type": "string"
+}
  2. First observedv0.1.8

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the destructiveHint and openWorldHint annotations by disclosing that there is no timeout, infinite loops can hang Studio, changes may not be undoable as one step, live mode touches production with no undo, and playtest servers run code through a ModuleScript with plugin-only APIs unavailable. It also exposes the require module-cache pitfall explicitly.

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

Conciseness5/5

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

The description is long, but every sentence earns its place for a high-risk, 7-parameter escape-hatch tool. Core behavior and return semantics are front-loaded, then safety, playtest, require, and live-mode caveats are organized into logical sections with no meaningful fluff.

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?

For a tool with no output schema and serious destructive potential, the description covers return values, output capture, timeout behavior, live-vs-studio differences, production safety, async execution, and known VM pitfalls. It provides everything an agent needs to decide whether and how to invoke the tool 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?

The schema already documents all 7 parameters at 100% coverage, including live-only constraints and the confirm requirement, so the baseline is 3. The description adds meaningful operational semantics beyond the schema: source runs with plugin permissions, print/return are the output channels, studio scripts have no timeout, and live execution is queued asynchronously and returns a state.

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?

States a specific verb and resource: 'Runs Luau in Studio's plugin context and returns whatever it printed, returned, or threw.' It also positions itself as the escape hatch when no dedicated sibling tool fits, clearly differentiating it from tools like create, modify, delete, move, script_edit, and find.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly instructs to reach for it only when no dedicated tool fits and names the sibling tools that validate input, type values, and wrap writes in undo recording. It gives concrete good uses and also warns against using require to read live game state, leaving little to inference.

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