Roblox Studio MCP

Overview Schema Source Related Servers Discussions Admin

Operate the live game

universe

Destructive

Manage a live Roblox experience: restart published servers, message live servers, ban players, inspect servers and logs, and manage products or passes.

Instructions

Acts on the PUBLISHED experience and the people in it — not on the place open in Studio.

restart rolls live servers onto the version you just published. Publishing on its own changes nothing for anyone already playing: they stay on their server, running the old code, until it empties. This is the step people forget. By default it bleeds off over 10 minutes — matchmaking stops and players finish what they are doing — rather than shutting servers down under them, which is what Roblox's own default does.

message publishes to MessagingService, reaching every live server at once. Only servers with a SubscribeAsync listener on that exact topic receive it, and nothing reports whether anything was listening, so success here does not mean delivery.

ban and unban set a player's game-join restriction. A ban with no durationSeconds is PERMANENT. displayReason is shown to the player; privateReason is for your records. Scope it to one place with placeId, or leave that out to cover the whole experience. bans lists who is currently restricted.

user looks up a user id — the name-to-id step most other calls need. inventory reports what someone owns: passes, badges, assets.

servers lists the place's live servers — players, uptime, frame rate, memory, version — and logs reads one server's errors and warnings by its jobId, with stack traces and structured-log context. That is where a player's bug report actually happened; Studio only shows your own test. Roblox keeps warnings and errors only, and they arrive about three minutes after they are written.

products lists the game's developer products and game passes with their ids and prices — the ids a purchase script needs. sell creates one, or changes one given itemId. Creating checks the name first, so a retried create cannot leave two "100 Coins" products.

Everything here needs an Open Cloud key and a universe id. The user sets both once with cloud in the Studio panel.

Input Schema

TableJSON Schema

Name	Required	Description
`op`	Yes	'restart' rolls servers onto the new version, 'message' publishes to MessagingService, 'ban'/'unban'/'bans' manage player access, 'user' and 'inventory' look someone up, 'servers' and 'logs' read live servers, 'products' and 'sell' manage products and passes.
`kind`	No	products/sell: 'product' is a developer product (bought again and again: currency, boosts), 'pass' a game pass (bought once: VIP, perks). products lists both when omitted; sell needs it.
`name`	No	sell only: the item's name. Required to create.
`image`	No	sell only: path to a local .png/.jpg/.bmp/.tga icon.
`jobId`	No	logs only: the server, as listed by `servers`.
`limit`	No	bans/inventory/servers/logs: how many rows to return.
`price`	No	sell only: price in Robux.
`topic`	No	message only: the MessagingService topic.
`filter`	No	inventory: an Open Cloud filter, e.g. `gamePassIds=123` or `assetIds=456`, to ask about specific items rather than listing everything. servers: a CEL filter over the server fields, e.g. `occupancy > 0`.
`itemId`	No	sell only: the product or pass to change. Omit to create a new one.
`search`	No	logs only: case-insensitive text to find in the message, stack trace or context.
`userId`	No	ban/unban/user/inventory: the player's user id.
`confirm`	No	Required for restart, message, ban, unban and sell. Each of these is visible to players the moment it runs and none can be undone from here.
`forSale`	No	sell only: whether players can buy it. Say it explicitly when creating.
`message`	No	message only: the payload, as a string.
`placeId`	No	ban/unban: restrict to this place only, instead of the whole experience. restart: only restart this place's servers. servers/logs: which place, defaulting to `cloud place`.
`severity`	No	logs only: just this level. Omit for both.
`universeId`	No	Which game. Omit to use the one set with `cloud universe <id>`.
`description`	No	sell only: the item's description.
`displayReason`	No	ban only: shown to the player when they are turned away.
`privateReason`	No	ban only: your own record. The player never sees it.
`bleedOffMinutes`	No	restart only: minutes to let existing servers drain. 0 shuts them down immediately, moving players mid-game. Defaults to 10.
`durationSeconds`	No	ban only: how long, in seconds. OMIT THIS AND THE BAN IS PERMANENT — say so to the user before you do it.
`excludeAltAccounts`	No	ban only: if true, the ban applies to this account alone rather than to alts Roblox links to it. Defaults to false.

Schema Changelog

Changes observed during successful MCP inspections.

Changed16 schema fields changedv0.8.6Sep 30, 2026

changedInput schema / properties / confirm / description

Previous value: -"Required for restart, message, ban and unban. Each of these is visible to players the moment it runs and none can be undone from here."New value: +"Required for restart, message, ban, unban and sell. Each of these is visible to players the moment it runs and none can be undone from here."

addedInput schema / properties / description

Added value: +{
+  "description": "sell only: the item's description.",
+  "type": "string"
+}

changedInput schema / properties / filter / description

Previous value: -"inventory only: an Open Cloud filter, e.g. `gamePassIds=123` or `assetIds=456`, to ask about specific items rather than listing everything."New value: +"inventory: an Open Cloud filter, e.g. `gamePassIds=123` or `assetIds=456`, to ask about specific items rather than listing everything. servers: a CEL filter over the server fields, e.g. `occupancy > 0`."

addedInput schema / properties / forSale

Added value: +{
+  "description": "sell only: whether players can buy it. Say it explicitly when creating.",
+  "type": "boolean"
+}

addedInput schema / properties / image

Added value: +{
+  "description": "sell only: path to a local .png/.jpg/.bmp/.tga icon.",
+  "type": "string"
+}

addedInput schema / properties / itemId

Added value: +{
+  "description": "sell only: the product or pass to change. Omit to create a new one.",
+  "type": "string"
+}

addedInput schema / properties / jobId

Added value: +{
+  "description": "logs only: the server, as listed by `servers`.",
+  "type": "string"
+}

addedInput schema / properties / kind

Added value: +{
+  "description": "products/sell: 'product' is a developer product (bought again and again: currency, boosts), 'pass' a game pass (bought once: VIP, perks). products lists both when omitted; sell needs it.",
+  "enum": [
+    "product",
+    "pass"
+  ],
+  "type": "string"
+}

changedInput schema / properties / limit / description

Previous value: -"bans/inventory: how many rows to return."New value: +"bans/inventory/servers/logs: how many rows to return."

addedInput schema / properties / name

Added value: +{
+  "description": "sell only: the item's name. Required to create.",
+  "type": "string"
+}

changedInput schema / properties / op / description

Previous value: -"'restart' rolls servers onto the new version, 'message' publishes to MessagingService, 'ban'/'unban'/'bans' manage player access, 'user' and 'inventory' look someone up."New value: +"'restart' rolls servers onto the new version, 'message' publishes to MessagingService, 'ban'/'unban'/'bans' manage player access, 'user' and 'inventory' look someone up, 'servers' and 'logs' read live servers, 'products' and 'sell' manage products and passes."

changedInput schema / properties / op / enum

Previous value: -[
-  "restart",
-  "message",
-  "ban",
-  "unban",
-  "bans",
-  "user",
-  "inventory"
-]New value: +[
+  "restart",
+  "message",
+  "ban",
+  "unban",
+  "bans",
+  "user",
+  "inventory",
+  "servers",
+  "logs",
+  "products",
+  "sell"
+]

changedInput schema / properties / placeId / description

Previous value: -"ban/unban: restrict to this place only, instead of the whole experience. restart: only restart this place's servers."New value: +"ban/unban: restrict to this place only, instead of the whole experience. restart: only restart this place's servers. servers/logs: which place, defaulting to `cloud place`."

addedInput schema / properties / price

Added value: +{
+  "description": "sell only: price in Robux.",
+  "maximum": 9007199254740991,
+  "minimum": 1,
+  "type": "integer"
+}

addedInput schema / properties / search

Added value: +{
+  "description": "logs only: case-insensitive text to find in the message, stack trace or context.",
+  "type": "string"
+}

addedInput schema / properties / severity

Added value: +{
+  "description": "logs only: just this level. Omit for both.",
+  "enum": [
+    "error",
+    "warning"
+  ],
+  "type": "string"
+}

Addedv0.6.8Sep 15, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Annotations already declare destructiveHint=true and openWorldHint=true, yet the description still adds substantial non-obvious behavior: default 10-minute bleed-off vs. Roblox's hard shutdown, MessagingService topic matching with no delivery feedback, relative server versioning semantics, permanent-ban risk when durationSeconds is omitted, ~3-minute log latency and warnings/errors-only retention, and create-time name checking that prevents duplicate products. It also correctly labels confirm as required for the irreversible ops rather than contradicting the destructive hint.

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?

Long but fully earned: one paragraph per op group, backticked op names, front-loaded with the single most important distinction (live vs. Studio), and no repetition of schema text. Every sentence carries either a behavioral or routing fact.

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 an 11-op, 24-parameter tool with no output schema, the description covers return shape where it matters (servers lists players/uptime/frame rate/memory/version; logs carries stack traces and structured context; products lists ids and prices), plus the auth/setup requirement. Nothing an agent needs to call it correctly is 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 coverage is 100%, so the schema carries most parameter meaning and the baseline would be 3. The description still adds real semantics beyond it — placeId scoping ('scope it to one place... or leave that out to cover the whole experience'), the create-vs-change contract of itemId, and the confirm requirement for the externally visible ops — so it edges above baseline.

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?

Opens with a precise scope statement — 'Acts on the PUBLISHED experience and the people in it — not on the place open in Studio' — that immediately separates it from every studio-side sibling (execute_luau, playtest, viewport). Each of the 11 ops is then named with a concrete verb+resource, so an agent knows what this tool does without 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 Guidelines5/5

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

Explicitly says when to use restart (after publish, because publishing alone changes nothing for live players), when to prefer it over Roblox's harsh default, when message delivery is not guaranteed, when logs are the right source ('where a player's bug report actually happened; Studio only shows your own test'), and the prerequisite (Open Cloud key + universe id set via `cloud`). Alternatives and exclusions are named, not implied.

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

Deploy Server

Operate the live game

Instructions

Input Schema

Schema Changelog

TDQS

Other Tools