Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/Chrrxs/robloxstudio-mcp/llms.txt

Use this file to discover all available pages before exploring further.

Roblox Studio MCP provides two complementary systems for moving game content in and out of a Studio session. The SerializationService round-trip (export_rbxm / import_rbxm) serializes live DataModel instances into binary .rbxm files and restores them with full fidelity — including scripts, attributes, tags, and nested hierarchies. The build library system (export_build, create_build, generate_build, import_build, import_scene) works with a compact token-efficient JSON format optimized for AI generation and bulk procedural construction. Both systems support the edit DataModel for normal authoring and the server DataModel for capturing or restoring live playtest state.

SerializationService round-trip

export_rbxm

Serialize one or more instances from the DataModel into a .rbxm binary file on disk. Internally uses SerializationService:SerializeInstancesAsync, which requires engine version 668 or later and PluginSecurity context. All specified paths must resolve to valid, creatable, non-service instances — the tool throws immediately if any path resolves to nil, a top-level service (e.g. game.Workspace itself), or a class that is not creatable.
instance_paths
array
required
Array of canonical DataModel paths to serialize, e.g. ["game.Workspace.TestRig", "game.ServerStorage.Templates.NPC"]. All paths are serialized into a single .rbxm file.
output_path
string
required
Absolute filesystem path where the .rbxm file should be written, e.g. /home/user/exports/TestRig.rbxm.
target
string
Which DataModel to read from. "edit" (default) reads the authoring DataModel. "server" serializes live runtime state during an active playtest, capturing the instance tree exactly as it exists on the server at that moment.
instance_id
string
Which connected Studio place to target. Required when multiple places are connected; omit when only one is connected. Use get_connected_instances to list available IDs.
Passing a service root such as game.Workspace or game.ServerScriptService as an element of instance_paths will throw an error. Serialize children of services, not the services themselves.

import_rbxm

Deserialize a .rbxm file and parent the resulting instances under a target DataModel path. Uses SerializationService:DeserializeInstancesAsync (engine v668+, PluginSecurity). Parenting is all-or-nothing: if any single deserialized instance fails to parent, all already-parented siblings are immediately un-parented and the call errors, leaving the DataModel unchanged. When targeting "edit", the entire import is wrapped in a single ChangeHistoryService waypoint — one Ctrl+Z in Studio reverses the whole import.
source
object
required
Exactly one of the following source variants:
  • { "path": "..." } — Read the .rbxm from an absolute local filesystem path.
  • { "url": "..." } — Fetch the file over HTTP or HTTPS. The fetch is performed by the MCP server process, not by Studio, and is capped at 50 MiB. Only http:// and https:// schemes are accepted.
  • { "base64": "..." } — Provide the raw .rbxm bytes inline as a base64-encoded string.
parent_path
string
required
Canonical DataModel path of the instance under which all deserialized instances will be parented, e.g. "game.ServerStorage.Imported".
target
string
Which DataModel to import into. "edit" (default) imports into the authoring DataModel with undo support. "server" parents into the live play-server DataModel during an active playtest.
instance_id
string
Which connected Studio place to target. Required when multiple places are connected; omit when only one is connected.
Roundtrip workflow example — patch a rig during a live playtest:
-- Step 1: export the live server rig to disk
export_rbxm({
  instance_paths = { "game.Workspace.TestRig" },
  output_path    = "/tmp/TestRig.rbxm",
  target         = "server"
})

-- Step 2: (modify TestRig.rbxm externally or via another tool)

-- Step 3: re-import the modified rig under ServerStorage
import_rbxm({
  source      = { path = "/tmp/TestRig.rbxm" },
  parent_path = "game.ServerStorage",
  target      = "server"
})
This captures the exact runtime state of the rig, lets you inspect or modify it offline, and replaces it without interrupting the playtest. The target="server" flag on both calls ensures you are working against the live server DataModel throughout.

Build library system

export_build

Export a Model or Folder from Studio into the compact build-library JSON format. Positions are normalized relative to the bounding-box center; colors and materials are deduplicated into a short-key palette. The file is automatically saved to build-library/{style}/{id}.json on disk.
instancePath
string
required
Canonical DataModel path to the Model or Folder to export, e.g. game.Workspace.MedievalCottage.
outputId
string
Build ID for the output file, e.g. "medieval/cottage_01". Defaults to {style}/{instance_name}.
style
string
Style category for organization. One of: medieval, modern, nature, scifi, misc. Defaults to misc.
instance_id
string
Which connected Studio place to target. Required when multiple places are connected; omit when only one is connected.

import_build

Import a build from the library into Roblox Studio, parenting the generated Model under a specified DataModel path. Accepts either a full build-data object or a library ID string that references a file already saved by export_build, create_build, or generate_build.
buildData
required
Either a complete build-data object (with palette, parts, etc.) or a library ID string such as "medieval/church_01". When using generate_build or create_build, always pass the ID string — it is more token-efficient and avoids re-serializing the full payload.
targetPath
string
required
Canonical DataModel path where the model will be created, e.g. "game.Workspace".
position
array
World-space offset [X, Y, Z] applied to the imported model’s origin.
instance_id
string
Which connected Studio place to target. Required when multiple places are connected; omit when only one is connected.

create_build

Create a new build from scratch by describing parts as compact arrays or objects and saving the result to the library. Parts are defined in a palette+parts structure: the palette maps short single-character keys to [BrickColor, Material] or [BrickColor, Material, MaterialVariantName] tuples, and parts is an array of either tuple arrays or property objects.
id
string
required
Build ID including style prefix, e.g. "medieval/torch_01" or "nature/bush_small".
style
string
required
Style category. One of: medieval, modern, nature, scifi, misc.
palette
object
required
Map of short keys to material tuples. Examples:
{
  "a": ["Dark stone grey", "Concrete"],
  "b": ["Brown", "Wood"],
  "c": ["Bright red", "SmoothPlastic", "MyCustomWood"]
}
parts
array
required
Array of parts. Each part may be:
  • Object format: { "position": [x,y,z], "size": [x,y,z], "rotation": [x,y,z], "paletteKey": "a", "shape": "Block", "transparency": 0 }
  • Tuple format: [posX, posY, posZ, sizeX, sizeY, sizeZ, rotX, rotY, rotZ, paletteKey, shape?, transparency?]
bounds
array
Optional bounding box [X, Y, Z]. Auto-computed from parts if omitted.

generate_build

Procedurally generate a build using a JavaScript code string that calls built-in geometry primitives. The code runs server-side and can reference high-level helpers (room, roof, stairs, column, arch, fence) and basic primitives (part, wall, floor, fill, beam), as well as repetition helpers (row, grid).
id
string
required
Build ID including style prefix, e.g. "medieval/church_01".
style
string
required
Style category. One of: medieval, modern, nature, scifi, misc.
palette
object
required
Map of short keys to [BrickColor, Material] or [BrickColor, Material, MaterialVariant] tuples. All keys referenced in code must be defined here.
code
string
required
JavaScript code using the generation primitives. See the tool description for the complete primitive reference. When modifying an existing build, always call get_build first to retrieve the original code, then make only targeted edits — do not rewrite the entire code from scratch.
seed
number
Optional seed for rng() calls, enabling deterministic output. Defaults to 42.
Use search_materials before authoring your palette if the place uses custom MaterialVariant instances — the third palette element references the variant by its exact name from MaterialService.

get_build

Retrieve a build from the local library by its ID. Returns metadata, the palette, and the generator code if the build was created with generate_build. Always call this before modifying an existing generated build — retrieve the code, apply only the targeted changes, and call generate_build with the modified code. Do not rewrite the whole build from scratch.
id
string
required
Build ID to look up, e.g. "medieval/church_01".

import_scene

Import a full scene layout — multiple library builds placed at specified world positions and rotations in a single call. Useful for populating entire maps or level prototypes from a declarative placement description. Each model is resolved from the library by key, then instantiated at its given position and rotation. Inline custom builds (defined directly in the scene data) are also supported.
sceneData
object
required
Scene layout object containing:
  • models — Map of short keys to library build IDs, e.g. { "A": "medieval/cottage_01", "B": "medieval/church_01" }.
  • place — Array of placement entries. Preferred object format: { "modelKey": "A", "position": [x, y, z], "rotation": [x, y, z] }. Legacy tuple format ["A", [x,y,z], [rx,ry,rz]] is also accepted.
  • custom (optional) — Array of inline build objects with n (name), o (origin), palette, and parts for builds not stored in the library.
targetPath
string
Canonical parent DataModel path for the entire scene. Defaults to game.Workspace.
instance_id
string
Which connected Studio place to target. Required when multiple places are connected; omit when only one is connected.
{
  "sceneData": {
    "models": {
      "C": "medieval/cottage_01",
      "T": "medieval/torch_01"
    },
    "place": [
      { "modelKey": "C", "position": [0, 0, 0] },
      { "modelKey": "C", "position": [20, 0, 0], "rotation": [0, 90, 0] },
      { "modelKey": "T", "position": [5, 0, 3] },
      { "modelKey": "T", "position": [15, 0, 3] }
    ]
  },
  "targetPath": "game.Workspace"
}

Build docs developers (and LLMs) love