Skip to main content
Glama
EL4CTEO

Roblox Studio MCP

by EL4CTEO
OverviewSchemaRelated ServersScoreDiscussions
Local

Modify instances

modify
Destructive

Batch-apply properties, attributes, and tags to multiple Roblox instances as one undoable, all-or-nothing step. Invalid values revert the entire batch, preventing partial edits.

Instructions

Sets properties, attributes and tags on existing instances, as one undoable step.

Each entry takes a list of paths, so one entry can apply the same change to many instances — anchoring 200 parts is one entry, not 200. Combine with find to build the path list.

The batch is all-or-nothing: if any value is rejected the recording is cancelled and every instance reverts, rather than leaving the place half-changed.

Values use the same notation the Properties panel shows — see the properties field. To change a script's code use script_edit.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
targetsYesChanges to apply together as one undoable step.
studioIdNoTarget Studio; omit for the active one.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed3 schema fields changedv0.3.5
    • addedInput schema / properties / targets / items / properties / attributes / additionalProperties / anyOf
      Added value: +[
+  {
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "properties": {
+      "type": {
+        "description": "Roblox type to store the attribute as. Needed for anything but a plain string, number or boolean — a bare string stays a string.",
+        "enum": [
+          "string",
+          "boolean",
+          "number",
+          "BrickColor",
+          "CFrame",
+          "Color3",
+          "ColorSequence",
+          "Font",
+          "NumberRange",
+          "NumberSequence",
+          "Rect",
+          "UDim",
+          "UDim2",
+          "Vector2",
+          "Vector3"
+        ],
+        "type": "string"
+      },
+      "value": {
+        "description": "The value, written as the Properties panel shows it: \"0, 5, 0\".",
+        "type": [
+          "string",
+          "number",
+          "boolean"
+        ]
+      }
+    },
+    "required": [
+      "type",
+      "value"
+    ],
+    "type": "object"
+  }
+]
    • removedInput schema / properties / targets / items / properties / attributes / additionalProperties / type
      Removed value: -[
-  "string",
-  "number",
-  "boolean"
-]
    • changedInput schema / properties / targets / items / properties / attributes / description
      Previous value: -"Attributes to set, as name → value. An empty string removes one."New value: +"Attributes to set, as name → value. A bare string, number or boolean is stored as-is; for any other type pass { type, value }, e.g. { type: \"Vector3\", value: \"0, 5, 0\" }. An empty string removes an attribute."
  2. Changed4 schema fields changedv0.2.9
    • removedInput schema / properties / targets / items / properties / attributes / additionalProperties / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  }
-]
    • addedInput schema / properties / targets / items / properties / attributes / additionalProperties / type
      Added value: +[
+  "string",
+  "number",
+  "boolean"
+]
    • removedInput schema / properties / targets / items / properties / properties / additionalProperties / anyOf
      Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  }
-]
    • addedInput schema / properties / targets / items / properties / properties / additionalProperties / type
      Added value: +[
+  "string",
+  "number",
+  "boolean"
+]
  3. First observedv0.1.8

TDQS

A4.6/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint, readOnlyHint), the description discloses important behavior: the batch is one undoable step, it is all-or-nothing, rejected values cancel the recording and revert every instance, and one entry can apply the same change to many instances. This gives agents an accurate model of side effects and failure semantics.

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?

Four short paragraphs, each with a distinct job: core purpose, batch path behavior, atomicity, and notation/alternative tool. The main capability is front-loaded and every sentence earns its place.

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

Completeness4/5

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

The description covers the essential operational context: batch semantics, failure atomicity, value notation, and the script_edit alternative. There is no output schema, but for a mutation tool the absence of a return-value description is acceptable. Slightly more could be said about success/error responses or prerequisites, but the definition is strong overall.

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 value by explaining that values use the same notation as the Properties panel, that one entry can apply a change to many paths, and that attribute values may need a { type, value } wrapper. These clarifications augment the schema rather than repeat it.

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: 'Sets properties, attributes and tags on existing instances.' It clearly distinguishes itself from siblings like create, delete, and move, and later explicitly distinguishes itself from script_edit. No ambiguity remains about what the tool operates on.

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?

The description gives clear guidance: use it to set properties/attributes/tags on existing instances, combine with find to build path lists, and use script_edit instead for changing a script's code. It doesn't enumerate when to prefer create/delete/move, but the scope is clear enough for an agent to route correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/EL4CTEO/rbx-studio-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server