Skip to main content
Glama
okenjioxx

Roblox Executor MCP Server

by okenjioxx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Set a property on a live Instance

set-instance-property
Destructive

Writes a property on a live Roblox Instance resolved from Luau, returning old and new values for auditing. Use it to change WalkSpeed, Visible, Transparency, or Value while debugging.

Instructions

WRITES LIVE GAME STATE. Resolve a Luau expression to an Instance and assign one of its properties, returning both the OLD and NEW value so the change is auditable. Common uses while debugging: toggle a GUI's Visible, bump a character's Humanoid WalkSpeed/JumpPower, set a part's Transparency/Anchored/CanCollide, or write an IntValue/StringValue's Value. For non-primitive property types (Vector3, CFrame, Color3, UDim2, Enum, Instance references) use value.kind='raw' and pass a Luau expression. The read of the old value and the write are each pcall-guarded. WARNING: this mutates the running game on the client — the change takes effect immediately and may replicate. Returns { Path, Property, OldValue, NewValue, ok } or { error }. Signature: { instancePath: string, propertyName: string, value: { kind: "string" | "number" | "boolean" | "nil" | "raw", value: string | number | boolean? }, threadContext: number? }. Phase: act; cost=medium; idempotency=idempotent-write. Requires: active-client, resolved-target, explicit-mutation-approval. Produces: operation-receipt. Verify with: get-instance-properties. Safety: MUTATING; writes live game/client state. On failure: inspect tool-schema for exact fields, defaults, constraints, and an invocation example.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
valueYesThe new value to write, expressed as a typed argument.
instancePathYesLuau expression resolving to the Instance to modify, e.g. 'game.Players.LocalPlayer.Character.Humanoid', 'game.Workspace.Part', or 'game:GetService("StarterGui")'. Evaluated as `return <instancePath>`.
propertyNameYesThe exact property name to write, e.g. 'WalkSpeed', 'Visible', 'Transparency', 'Anchored', 'Value', 'Position', 'BrickColor'. Case-sensitive.
threadContextNoOptional Roblox thread identity for this call; omit it to use the server default.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv2.0.0-spies.2

TDQS

A3.6/5.0
Behavior1/5

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

The description embeds 'idempotency=idempotent-write' while the annotations declare idempotentHint=false, directly contradicting the structured safety metadata an agent relies on to decide whether repeated calls are safe. This is an Annotation Contradiction, so per the rubric the score collapses to 1 despite the otherwise useful disclosure that reads/writes are pcall-guarded, that the mutation replicates, and that old/new values are returned.

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

Conciseness3/5

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

The critical safety warning is front-loaded, which is good, but the body then mixes return format, signature, use cases, and a trailing metadata block (Phase/cost/idempotency/Requires/Produces/Verify/Safety) that adds bulk and repeats information already in the schema. Information-rich but not tight.

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?

With no output schema, the description helpfully specifies the return shape ({ Path, Property, OldValue, NewValue, ok } or { error }) and states prerequisites and a failure-recovery path via tool-schema. Coverage is strong; only the self-contradictory idempotency claim undercuts it.

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 already 100%, so the baseline is 3, but the description adds practical property-value color not present in the schema ('toggle a GUI's Visible', 'bump WalkSpeed/JumpPower', 'set Transparency/Anchored/CanCollide') that helps the agent choose valid property/value combinations. The raw-expression guidance largely restates the schema, keeping it below 5.

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 ('assign one of its properties' on an Instance) plus the exact scope ('WRITES LIVE GAME STATE'), which cleanly separates it from read-oriented siblings like get-instance-properties and watch-instance-property. The mechanism (resolve a Luau expression to an Instance, then write) is spelled out, so an agent understands what it does before opening the schema.

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?

Gives explicit debugging use cases, tells the agent to use value.kind='raw' for non-primitive types, and routes verification to get-instance-properties. It does not, however, say when to prefer this over adjacent mutators such as set-attribute, set-properties-bulk, or write-path-value, so the when-not/alternative coverage is incomplete.

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