Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

Sync scripts with files on disk

sync
Destructive

Mirror Roblox Studio scripts to disk for editing with your own tools, then push changes back in one call. Keep both sides updated continuously.

Instructions

Mirrors the place's scripts into a folder on disk, so you can work on code with your own file tools -- read a window, search, edit in place, diff -- and then send it back to Studio in one call. Studio stays where the game runs: use playtest, screenshot, console and input to check the result.

Layout mirrors the instance tree, Rojo-style: ServerScriptService/Main.server.luau is a Script, .client.luau a LocalScript, .luau a ModuleScript, and a script with scripts inside is a folder holding init.server.luau (or init.client.luau, init.luau). New files become new scripts, and a file moved or renamed moves the script itself, keeping its identity.

Ops: status shows what would change without changing anything. sync goes both ways, pull only Studio -> disk, push only disk -> Studio. watch keeps them in step until stop: edit files and Studio follows within a second, and edits in Studio land on disk.

Nothing is overwritten blind. The last sync is remembered per file, so a file changed on both sides is a conflict, reported and left alone -- settle it, or pass prefer. Deleting a file deletes the script (one Ctrl+Z in Studio); a script deleted in Studio moves its file to .rbx-sync/trash. Nothing is deleted on a first sync.

UI and other instance trees: export writes one as a build file (e.g. StarterGui/Shop.build.json, the same fields create takes, only non-default properties). Edit it, then build -- or any sync -- rebuilds the tree in one undo step, keeping the scripts inside it. Build files are two-way too: a tree edited in Studio is written back to its file, and edits on both sides are a conflict rather than one silently undoing the other.

Conflicts leave Studio's version in .rbx-sync/conflicts/. Merge into the file (or fix Studio) and sync again: whichever side changed since the conflict wins. While watch runs, new conflicts and errors are appended to your next tool reply.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
opYes'status': dry run. 'sync': both ways. 'pull': Studio -> disk. 'push': disk -> Studio. 'watch'/'stop': continuous two-way sync. 'export': instance trees -> build files. 'build': build files -> instance trees.
dirNoSync folder, relative to the working directory. Default "studio".
filesNobuild: build files to apply, relative to the folder. Default: those changed since last built.
pathsNoexport: instances to write as build files, e.g. ["StarterGui.Shop"].
rootsNoStudio paths to sync, e.g. ["ServerScriptService", "ReplicatedStorage.Shared"]. Default: every service scripts are authored in. Remembered for the folder once given.
preferNoSettle conflicts in favour of one side instead of reporting them.
rebindNoLet a folder synced with one place follow a different place. Almost never what you want.
studioIdNoTarget Studio; omit for the active one.
confirmDeletesNoAllow a run that deletes most of what the folder tracks. Check `status` first.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.8.6

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already flag destructive=true, non-idempotent, openWorld; the description goes well beyond that by disclosing exact destruction semantics ('deleting a file deletes the script, one Ctrl+Z in Studio'), trash/conflict locations ('.rbx-sync/trash', '.rbx-sync/conflicts/'), the first-sync no-delete guarantee, and the conflict-wins resolution rule. This is unusually rich behavioral disclosure for a mutation tool.

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 purpose is front-loaded and paragraphs are organized by concern (mirror, layout, ops, safety, build files, conflicts). It is long — roughly 350 words — and the trailing conflict-resolution paragraph could be folded into the earlier safety paragraph, but for an 8-op tool the length is largely earned.

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?

With 9 parameters, 8 enum ops, no output schema, and destructive/open-world behavior, this tool has substantial complexity, and the description covers layout mapping, per-op semantics, deletion safety, conflict handling, and the export/build round trip. Nothing an agent must know before invoking it appears missing.

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 100%, so the per-parameter baseline is 3, but the narrative adds meaning the enum text does not: it explains what `watch` does over time, how `prefer` interacts with conflicts, and the consequence of `rebind` ('almost never what you want'). It stops short of documenting `dir`/`studioId`/`files`/`paths` beyond what the schema already states.

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 states a concrete verb and resource ('mirrors the place's scripts into a folder on disk') and frames the whole workflow (edit locally, send back to Studio in one call). It is immediately distinguishable from siblings like script_read, script_edit, and modify, whose scope is single-script rather than folder-tree mirroring.

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 explains which op to reach for (`status` before destructive runs, `sync`/`pull`/`push` directionality, `watch` until `stop`) and routes verification work to siblings ('use playtest, screenshot, console and input to check the result'). It stops short of saying when NOT to use this tool versus in-place editing tools like script_edit, so it is clear context rather than full alternative routing.

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